At the moment, I have a wordpress-based site at http://sub.mydomain.com, running for 2 years already.
Now I decided to setup another wordpress site, to be used separately from http://sub.mydomain.com, at http://www.mydomain.com.
My question is would the new setup causes any damage to the site in sub domain? If yes, Could you guide me how to avoid it?
No, they should exist in seperate space on the server's file system so it should be fine. Seperate databases, seperate urls, etc.
edit:
our dev server has dev1.oursite.com, dev2.oursite.com etc on it. Multiple subdomains running wordpress, magento, and drupal with no problems.
markratledge is correct you can install it to the same database with a different prefix, but there is no real benefit to doing so unless your host has limited the number of databases you can have, or you only want one DB to backup. But either method is fine, no conflicts.
You can use the same database, but use a different database table prefix to not overwrite the subdomain's tables. I.e., wpsub_options, etc.
See http://codex.wordpress.org/Installing_Multiple_Blogs
Related
We have created a duplicate of our website on a new server as part of a migration. We have a wordpress blog that is part of our website.
The docroot of the wordpress site is set as an alias in our main site. The result is that to access the site home page, the following url is used: https://www.rephunter.net/blog/.
The new environment is not available to the public at this time, and is only accessible within our VPN. When the above link to the blog is followed, instead of the expected home page of our blog, we get the page at https://www.rephunter.net/blog/wp-admin/install.php, which wants to install a new site.
The configuration in the new environment is supposedly an exact copy of our production site from some time back. The permissions on the main files is the same.
What is it that is causing the attempted blog access to be redirected to the installation script?
EDIT:
The responses so far have not really absorbed the intent of the previous information. We are not migrating in the normal sense. Rather we are testing in a new virtual environment that will eventually lead to a more normal migration.
We have an exact duplicate of our original wordpress and database environment that is running in a virtual environment with an updated protocol stack that is only accessible if you are on the VPN for that environment. As far as we can tell, there is no difference in the configuration.
For example, the parameters in wp-config.php are exactly the same as in the original installation. When php runs, it sees the same environment, with host names and everything identical. It would not work otherwise.
Yet if there really were no difference, it would just run. But since WP is trying to install a new database, there is something different that we are missing.
To further illustrate this: supposed you took an image backup of the wordpress installation and the database, and put it in a different VM, and set up the DNS and everything as it needs to be--the new environment looks no different than the old one. All databases, wp-config settings, etc, are the same. So our main website and database functions very similarly.
As I mentioned above, the difference in the protocol stack should be considered. The old system is on PHP 5.6.27--the new one is on 7.3.4. So that could be causing some difference, which maybe somebody might recognize. Wordpress is 5.2.2 and should be compatible with both PHP levels.
We believe there is some relatively simple parameter setting that we are missing. For example, as in the first answer that $table_prefix is set wrongly. But that is not it in this case.
WordPress redirects you to that installation screen because the database it's connecting to is working (meaning, the username and password are correct), but the data it's expecting to be there isn't. Therefore, it assumes it's a new / empty database and prompts you to install WordPress.
I've seen this happen in two scenarios:
The database really is empty, and thus WP needs to install the standard tables and info
The table prefix in your wp-config.php file is incorrect for an existing database
Look at your wp-config.php file in the root directory of WordPress, and look for a line similar to this:
$table_prefix = 'wp_';
Then, open up the database (phpMyAdmin or some other interface to browse what the database structure actually is) and confirm that the table prefixes (the first few characters of the table names) actually match what's set above.
Hopefully this gives you something to go on! Let us know what you find
Migrating Wordpress websites can be quite tricky. I've worked as a WP developer for a number of years and always struggled with manually migrating websites.
There are a number of factors to consider:
WP stores a lot of installation specific information within the database. So you can't do a database dump and upload the export into a new database.
Changing the website url within the wp_options table in the databased there are still other references to the original url scattered throughout the db.
You could try a find and replace all using an editor that supports this sort of functionality (vscode, sublime, atom) but things always end up breaking and your doing tons of "find & replace" actions.
I have always relied on a 3rd party tool Backup Buddy as it simplifies the entire backup and migration process and offers the peace of mind of having easily deployable backups for your website.
Backup Buddy allows you to export your website as a zip and then you can move the zip to any server you want and the plugin provides an installer script (php) to guide you through the migration of your wp site to any host and database of your choosing.
Note: I am not in any way affiliated with iThemes or Backup buddy, and I do not stand to benefit in anyway if you decide to use the plugin. This is only advice on a tool that I have found helpful, reliable, have had success with, and currently actively use on a number of websites that I maintain.
WordPress display installation page because you have not update your wp-config.php file after migrating server so please follow below steps in future when you migrate your website.
Please follow this steps when you migrate your WordPress website from one server to another server.
Back up your website files/database
Export wordpress database.
Create database on your new host server.
Edit the wp-config.php File and edit this details.
Add new database name
Add new database username
Add new database user Password
Add new host as per your hosting provider or (localhost is default)
Import your database to new server.
upload the WordPress files to your new host
defining new domain URL & Search/Replace old domain URL
I am re-designing a website that already exists on network solutions. I would like to keep the same domain for the new site but I am going to use wordpress through network solutions.
How would I install Wordpress without interrupting the current site?
Then once the new website is done, I would need to replace it with the existing site without interrupting the file structure to keep all images and links I've coded into the "staging" instance?
What people usually do in this case is create a subdomain where the development version of the site will live (eg. https://staging.example.com or https://dev.example.com) so both sites can coexist without affecting one another.
Another approach would be to create a folder in the main domain (eg. https://www.example.com/staging/ or https://www.example.com/dev/) and do all the work there. Personally I don't use this approach, I prefer the one mentioned above the best as it keeps both sites completely separated.
A WordPress-based website has been developed on an Amazon AWS AMI instance. Let's refer to that site as http://example.com. For the purpose of testing changes to the site, from the Amazon AWS EC2 control panel, I stopped the running instance, created an image of it, and then launched a new instance using that image. I created a DNS record for clone.example.com and pointed that to the cloned instance.
Once the clone instance launched, I did the following:
Created a new LetsEncrypt certificate for clone.example.com and updated /etc/httpd/conf.d/ssl.conf accordingly.
Using mySql Workbench, downloaded a copy of the database and removed the schema
Edited the database file, changing all instances of http{s}://example.com to http{s}://clone.example.com
Uploaded the database into a new schema with the same name
Searched all files in /var/www/html for the string example.com but did not find it anyplace that matters
I was then able to access the cloned site, the security certificate worked, but the site is different from the original. By different, certain colors, layouts, etc., are not the same.
The WordPress site in questions used a variety of plugins, including:
BuddyPress and several affiliated plugins
BP Portfolio
Gravity Forms
WooCommerse and several affiliated plugins
Can you please suggest what I can try to get the cloned site to behave like the original? Thanks!
I dug in and figure this out the hard way - I changed each instance of https://example.com to https://clone.example.com until I found the one that broke the site.
The problem was in the table wp_options (not surprising) and the entry that caused the problems was social_portfolio_options. This is a case of laziness on the developers' part - instead of doing the right thing, i.e., creating a table to store the options; they used a long string with each part being delimited by its length. Thus, changing the URL caused the string parsing to break.
I remembered facing a similar issue relating to CSS while cloning a wordpress site months ago. However, this wasn't done on AWS but on another hosting provider. What happened was that the page-id on my cloned site was new and different from the one used previously. The issue was resolved after updating onto the existing styles.css with the new page-id.
This is not an answer. I wanted to leave it as a comment but lacked the reputation.
I have a used domain access module (Drupal 7) for creating a website. My requirement is, there will be one main site and many sub websites in the same domain. all the sub websites will access the same database and the source code of main website. All this websites will be in a VPS hosting. One Main website and all other sub websites are sub-domains, created. For Example:
enter code here example.com -- Main website.
one.example.com -- sub website.
two.example.com -- sub website.
three.example.com -- sub website.
Now, the scenario is, the database and the source are in example.com. Can I have a sub-website as another domain like apple.com, orange.com -- sub-websites
Is this possible? and in which server I have to place my database and code.
Do you need to share content between the various sites? If so, you'll probably want to use Drupal's Domain Access module (as you've tagged this question). However, if these are all going to be distinct sites that do not have to share content (except maybe through Aggregation or Feeds) - you can avoid that module.
I'm pretty sure the approach you want to take is documented here: https://drupal.org/node/2622 - basically, you use one database, but each site uses its own table prefix to distinguish it from the other sites.
As far as running multiple sites from one Drupal root, you can use the built-in multisite support: https://drupal.org/documentation/install/multi-site . I don't think you will need drupal domain access at all in this case.
I have a live site built in Wordpress at www.site.com/name1.
The client wants a new theme. I've heavily modified the current theme with custom code and will need to do so with the new theme, all without interrupting the live site, so this wont be as simple as moving the site from one theme to another. Therefore I think I need to create a duplicate of the site at www.site.com/name2 because the content will all be the same. Doing this will give me a place to work on the redesign.
What is the best way to go about doing this? Should I have both use the same DB or not? When I get ready to go live should i simple redirect the domain to /name2 or move everything at /name2 to /name1?
Any help is appreciated.
Thanks,
Chris
If you want the same Data you can use the same DB but there is somes Options Tables dans Meta tables in the Wordpress DB, then if you change parameters on one site it will affect the other.
If you just recode the Theme without touching anything in the configuration you can use the same DB to test your theme with valid datas, but if you think you'll have to change paramaters i would prefer duplicate the Production DB to a Test DB to secure the production Website.
When you go live you'll just have to move your theme to the production website and copy your Option and Meta Tables.
If you're at a point where you're having clients, you should definitely develop locally. This will free you from the trouble of mistakingly messing up the production site.
Install Apache, MySQL and PHP on your own machine.
Copy database and files from production.
Change anything you'd like without exposing it to the Internet.
Upload your new, tailor-suited theme to production when it's ready to go live.