I am having a website redesigned. The designers plan to use Wordpress as the CMS and want a development copy to work with. Thing is, I now have Wordpress installed to run a blog (only) on a subdirectory of my current site.
Soooo...question is: Can I create a subdomain, install Wordpress on there, point it at a separate (new) schema on MySQL and have them use that for the development work? I know I can physically do this, but will anything about running the the WP install scripts on the subdomain screw up the existing production install on the main domain?
The install itself should not create any problems. Personally, I always develop WP sites in their own subdomain, allowing me to do away with the wordpress/ subdirectory.
The most significant hurdle will come when you are ready to move the development site to a new domain and/or place in the directory hierarchy. Although the theme files and their associated CSS, JS, etc., files should be using relative-path references, the database itself may contain hundreds of fully qualified URLs that reference the development domain and/or directory.
There are a number of WordPress plugins that address this problems. The one I am most familiar with is BackupBuddy from ithemes.com. (I'm not a shill, just a satisfied customer.) BB is useful both for performing scheduled backups (full or database-only), but it is also very useful during development and during deployment. There is an included script, importbuddy.php, than can not only take a .zip of a full backup and restore the site, it can also move the site from one directory and/or domain to another.
Note: BackupBuddy is not free, but it is released under GPLv2. You are paying for the support necessary to keep it tracking changes in the WP ecosystem. If you are doing any serious WP work then it is money well-spent. You might suggest this to your designers.
Yes you can do it. It doesn't matter. You can install your new blogs to any directory or subdomain (actually they're directories, too). Also you can use new MySQL databases for them, or you can use same database for your all WP installations (by editing wp-config.php manually), thereby you'll have same content for your all WP blogs.
Technically, yes you can do it.
However, if you have a live domain with public people using it, you are best not developing on either the same domain or server, because:
Mistakes happen. You can break the database or other code.
While you develop, you can affect performance of the server.
Develop on a local machine, or a completely different server, and when you are happy with it, push the code live onto the production server.
if you are planning to make a test copy of the current install on a subdomain which includes separate source code and database the answer is NO it will not affect your current installation.
Related
Goal: We have a Magento installation which contains a lot of sensitive data. We're looking to host a Wordpress installation.
Problem: Since we're installing third-party modules on Wordpress, we don't want any security issues in Wordpress to be able to compromise Magento.
I've spoken to a couple of my friends, and also had a think back to how it's been implemented in the past, but I wanted another opinion.
Since the wordpress directory will reside inside of the magento directory, would it be sufficient to chown the files inside of wordpress to a new user ("user-wp"), and then to chroot the user-wp user to the wordpress directory? Magento would then still have access to all of the Wordpress files, but not vice-versa.
Any other suggestions on how to go about implementing this would be more than appreciated! Somebody also suggested configuring a separate vhost.
Using a subdomain like blog.site.com would probably be the easiest way to set this up. All you would have to do is add a new VHost for the WordPress installation.
I don't think Chrooting would provide much security. You may also run into WordPress Plugin issues with such a configuration.
The setup is tricky. You would have to go and modify the PHP-fpm process pool and users it runs with. Then assign one pool to Magento and another to WordPress. Additionally you will also want to serve static assets & uploads from the Webserver itself.
And when you change this config you have to retest your Magento install to make sure things you didn't break anything accidentally.
Too much hassle, just use the subdomain. :)
I have done a blog in mamp and would like to push into hostgator. Must i recreate everything in hostgator like Installing Wordpress on Hostgator. Is there any way i could just push my stuff straight into hostgator without redoing everything in hostgator. Need some suggestion.. Thanks..
It's quite easy to deploy a local version of Wordpress to a live server. First of all, you are right, I would not bother installing a clean copy of Wordpress on your server, you'd then have to totally rebuild the site.
What you need to do is;
FTP all your files from your local machine to the server.
Transfer the whole database from local phpmyadmin to a new database on the server
Change the database connection details in wp-config.php
Make any necessary changes to your default Wordpress .htaccess. What I mean here is that your MAMP site probably isn't in the root but your live site probably will be. If you have SEO permalinks set up then you would remove the Mamp subdirectory from the rewrite rule and the base in the .htaccess. Your host might also require you to add rules here (ie specifying which version of PHP to use etc). You could always install Wordpress using their installer to see if they add any special rules themselves.
All easy so far - now comes my tip. Moving Wordpress databases from your local development environment to live can be a massive pain because Wordpress (and lots of plugin/theme developers) use serialized arrays to store data. So if you do a find-and-replace on the database to replace your old url with the new one, you will disable lots of things like config settings and widgets (text widgets specifically, but there's loads of stuff you end up having to recreate).
Download this file;
http://interconnectit.com/124/search-and-replace-for-wordpress-databases/
and upload it to the server and access it directly in your browser. Run through the quick form and perform a serialized array-friendly find and replace on your database urls. Job done. Good luck.
While switching a WordPress site onto Git I looked for a .gitignore template. But I stumbled upon a reoccurring theme.
Fact: you don't want WordPress core files, or your server-specific configuration files etc., in your project's repository. You just don't. – Joe Bartlett
And the recommended GitHub .gitignore for WordPress excludes all wp-*.php files. Wordpress.gitignore.
Why is this recommended? Surely I’d want as many core files to be included as possible, otherwise I have to install WordPress on every server I deploy to.
If context helps, I’m deploying it to a load balanced network with two application servers and two database servers.
The only thing I keep in a repository is the theme, never any core WordPress files. In the readmes I keep track of what versions it works with.
It's probably not recommended to help discourage modifying the core files.
Another idea is to keep WordPress as a clean git repo with your themes as submodules, that way you can upgrade/rollback WordPress separate from your themes. This is also how I maintain sites that use frameworks.
This is recommended in order to keep only YOUR files into your repository. Then using a script (or something else) you can retrieve the WP sources.
we have a VPS for new site development, and were planning on using unique IP addresses for each new site/account so that while in development all links, URLs, etc. would be relative to the root (IP address) while in development and not need to change when going live (redirecting domain). But now our host won't allow us to purchase new IP addresses (according to worldwide shortage).
So now all new sites will be located at: http://shared.ip.add.ress/~cpanelaccount/. That means that while in development the sites are not using a root URL as we have been doing.
What is the best workflow while in development for relatively complex CMS solutions where we need to be able to confidently setup and test all links, SEF URLs, plugins, components, etc. without worrying about things getting messed up when the domain is switched (site goes live)?
Do we need to do some sort of global redirect in the .htaccess file?
Any modifications or strategies specific to Wordpress and/or Joomla installs?
THANKS!
I'd have to do an install of the latest WP to be sure, but at least with Joomla it is fairly irrelevant if you install in the root or a subdirectory. In the case of Joomla, there is only one change that needs to be made when moving from a subdirectory to the root. You'd need to change .htaccess to reflect the correct installation directory if you have enabled core SEF. Otherwise, there are no changes that need to be made at all. I am pretty sure WP is just as easy to move, but I'd have to look, it's been a while since I moved a WP site.
I've got Drupal working on a shared host, and I uploaded some modules from my home system successfully, but I've got the message that there is a security update for my version, and I should update immediately.
I'm not sure how I'm supposed to do that. It seems like the update is an entire new installation. I originally installed it using the hosting company's installer, Fantastico. Should I simply over-write the existing installation with the new files? Or ignore the message? I realize I shouldn't over-write the sites folder, or anything I've modified.
The instructions that come with the download seem to be for a major version upgrade, and are way too much trouble for frequent security updates. Searching Drupal's site shows many other methods, but no indication of anything official. And some were ridiculously error-prone, and not really useful.
I don't have shell access to the hosting site, although I can pay extra to get it if I really need to. Or, maybe I can clone the site on my local Linux system, do the update using a script, then upload the whole thing.
Does anyone have experience with this situation?
With only FTP access you should:
Download and extract the new Drupal version.
Delete the sites folder (in the downloaded Drupal), this is very important.
Put your site in maintainance mode.
Upload the content of the new Drupal (not the sites folder). This should give you a new version of all the Drupal core files, but leave the sites folder intact where you have your custom and contrib modules, your settings.php file and your uploaded files.
Run update.php as user 1.
Lastly put your site in online mode again.