I am currently working with a team of developers trying to port our website to WordPress. On our local dev. server, we have complete ability to edit MYSQL schema. However, our parent company runs the MYSQL server on our production server, meaning we can't make script-based schema changes. Instead if we want to change anything in the MYSQL schema, we have to log the change, and mail it to them.
This makes upgrading WordPress tricky, since WordPress automatically generates and executes the SQL when it updates. We simply can't do this, and need a way to get SQL commands WordPress uses on our local server.
I agree with Pekka웃's comment, but if you really must do this I think the easiest way would be to use MySQL logging. Turn it on on your local machine, run your upgrade, and check the content of the file.
Depending on what version of MySQL you have, something like this should create a file to use as a base:
SET GLOBAL log_output = "FILE";
SET GLOBAL general_log_file = "D:/tmp/mysql.log";
SET GLOBAL general_log = 'ON';
I can't help think getting the parent company to run the upgrade would be much, much better though. Minor differences between dev and production could cause unexpected issues.
Related
We have a production site powered by Wordpress. In my experience, Wordpress updates tend to go pretty smoothly, but every now an then something goes wrong and so we always run the updates locally or on our dev site first to make sure nothing breaks.
My questions is this: Is it a good practice to commit those changes (from the upgrade) locally and then push the changes to production? ...effectively updating the production site? This seems to work, but I know that sometimes updates include modifications to the database. So my fear is that the update will modify my local DB, but NOT the production DB and then cause problems when the newer code runs (expecting the DB to have been modified).
Is this is valid concern?
Will well-written plugins account for this issue somehow?
Is there an entirely different and better way to do this?
UPDATE:
I think the purpose of this question was initially unclear. I know very well that I can run the update locally, test it, commit, then run the update in production, commit, then merge. That's what we currently do but it sucks and I'm not sure if it's even necessary. The point of this question is to figure that out, or learn a better way. For example, if someone knows something definitive about the nature of WP updates and how they handle DB modifications, it would pretty much answer this question.
If you are able to successfully execute the update in a test environment, you should be able to then execute the same update in your production environment. It might be a bit more work, but its going to give you the most information on whether or not an update will work.
If you are in a virtualzied environment, you should be able to copy your production virtual machine to test the upgrade.
Even though it takes a few minutes extra, always stick to best practices. Complete updates locally then push to the dev site. On occasion, a plugin will have a database change but not documented properly.
Best Practice:
Wait a day after the update then read the issue queue on the plugin . If other people had problems with the update, you will know ahead of time.
Backup the database
git status/git commit, making sure the branch is clean/make any needed commit
Complete all necessary updates
Clear all cache (twice)
Check to make sure all is running smoothly locally.
If there was a database change from the update Make a new database backup.
Push changes to the dev site
If there was a database change Restore database from #7
edit: Please make sure your local database and code is identical to the dev site before the backup.
I prefer a tool like WP Staging to create a test site with a few clicks. Than i update all plugins and if everything is fine, i do the same process on my production site. You find WP Staging on wordpress.org
Just make sure you save a copy of your work before doing anything. Also, always check what the update is, sometimes it's just a language add-on which you probably don't need.
Is it possible to version control a PHP + MySQL + Apache project? And could it keep track of the changes in the database, like for example if I added a new table, can I possibly commit that?
Thank you.
It is not normal to keep databases in version control. Some developers use a sqlite database for development so that it can be checked into version control, but this can lead to issues as sqlite syntax can be different from MySQL.
However, you can keep your database schema and migrations source control. Look at a projects such as mysql-php-migrations to get started.
There's a good tutorial on using PHP with Git at http://net.tutsplus.com/tutorials/other/easy-version-control-with-git/ - this should get you started.
Using Git for your PHP scripts is no problem, however tracking changes to the database is a little trickier. If you have SQL scripts that create the database structure then these can be version controlled with no problems. Otherwise you could use mysqldump to output the structure to an SQL script after any changes you make:
mysqldump -d -h localhost -u root -pmypassword mydatabase > dumpfile.sql
You could use git to track PHP scripts and SQL scripts that create the necessary database structure. Those SQL scripts could of course be version controlled and recreate the database schema at any given state.
Git is essentially SCM, which means Source Control. Tables in mysql are stored as binary files, so it isn't very good idea.
You can, however, store SQL queries which create these tables, allowing you to re-create them if you needed to.
As for php, it will be all good.
I recently released a really simple shell script that will help keep changes to a MySQL database under version control.
https://github.com/stevecomrie/mysql-version-control
I've just gotten my production site up and running. I have a lot more work to do, and I'm realizing the need now for a development server before pushing changing live onto the production site (with users) - obviously...
This thread (and a lot more on Stack) describe me:
Best/Better/Optimal way to setup a Staging/Development server
Anyhow... Reading these threads is outright confusing at times, with all of the thrown around terminology, and my smaller CentOS/Apache knowledge.
My goal is to:
Make some changes to files as needed.
Test the changes on the same server, to ensure settings are identical.
If all is ok, I can now save a version of this somewhere, perhaps locally is enough for now (Bazaar seems like a possibility?)
Finally, replace all of the changed files via SSH or SFTP or something...
My worries are:
Uploading changes while users are in the system.
How to upload the files that have changed, only.
I'd love somebody to either link to a great guide for what I'm thinking about (that leaves nothing to imagination I'd hope) - or some kind of suggestion/etc... I'm running in circles trying out different SVN's and progarms to manager them, etc...
I'm the only one developing, and just want a repeatable, trust-worthy solution that can work for me without making my life too miserable trying to get it set up (and keep it set up).
Thanks much.
If you have the ability to create a staging subdomain on the production server, here is how I would (and do) handle it:
Develop on your development machine, storing your code in a VCS. I use subversion, but you may find another you prefer. After making changes, you check in your code.
On your production server, you create a subdomain in an Apache VirtualHost which is identical to, but isolated from your production VirtualHost. Checkout your code from the VCS to the staging subdomain area. After making changes, you then run an update from your VCS, which pulls only changed files down. Staging and production share the same data set, or you may have a separate database for each.
The reason for using a subdomain instead of just a different directory is that it enables you to use the same DocumentRoot for both staging and production. It's also easy to identify where you are if you use something like staging.example.com.
When you're certain everything works as it's supposed to you can run a VCS update on the production side to bring the code up to date.
It is important to be sure that you have instructed Apache to forbid access to the VCS metadata directories (.svn, .git, whatever).
Addendum
To forbid access to .svn directories use a rewrite rule like:
RewriteEngine on
RewriteRule .*\.svn/.* - [F]
This will send a 403 on them. You could also redirect them to the homepage to make it less obvious they're even present.
In terms of worry #1, remember that even StackOverflow periodically goes down for maintenance when people are using it. Just provide a good mechanism for you to switch the site to maintenance mode (and back out) and you'll be fine.
Thank you everyone for the tips/hints/etc...
I've finally found the perfect solution for my needs, SpringLoops... http://www.springloops.com/v2/
It manages my SVN (which I use Tortoise SVN with) - and will actually deploy the changes onto my two sites: staging and production.
I highly recommend it, it's working wonderfully so far.
Thanks!
You need a version control system, like Subversion, Git or Mercurial.
When you change files, you commit those changes to a repository. This keeps track of all the changes you've made and lets you undo them if it turns out you did something stupid. It also lets you restore files you accidentally delete or lose.
On top of that, it makes deploying updates as simple as typing 'git update' or 'svn update' on the production server. Only the files that changed get transferred and put in place.
You will get this advice no matter how many times the question is re-asked. You need version control.
I was wondering how to start coding a script using php, and that script will be used on many websites.
so should I start first by creating the database ? and then start creating php files that will process data from the database ?
and should I start thinking of an install wizard for this script at first, or later when I finish the project I'll create one ?
I'm really confused on how to start a project, can you please give me some advice ?
and thanks everyone :D
should I start first by creating the database?
If you are going to use a database in your PHP script, then yes, you should install a database first. MySQL is a good start.
and then start creating php files that will process data from the database?
I would start on one server first, and create one PHP file called index.php that will do a database query. Then work your way to multiple PHP files from there.
and should I start thinking of an install wizard for this script at first, or later when I finish the project I'll create one.
Installing PHP files is 90% of the times as simple as just copying them onto your new server. I wouldn't worry about an install wizard just yet.
Another general tip because you are a beginner: install WAMPServer, it is a webserver/PHP server/MySQL Server in one that runs on your local computer. This is great for developing because you can just put your PHP files in C:\WAMP, edit them and directly see the result in your browser through http://localhost/. Then when you are happy you can upload to the server, or multiple servers. (Just by copying).
Most php software does not have, or need for that matter, what you would call an install wizzard.
I would suggest you to develop whichever way feels most natural to you.
Some people find it easier to start with the database design, while others prefer to write some code first and then expand the db schema further. There really is no right way to do it.
Starting a PHP project can be as easy as creating a text file and pumping out lines of code, however if you plan on creating a sizeable project, I would suggest a fully featured IDE.
Decide what dependencies your script has.
Decide which minimum version of PHP the script will be compatible with.
Work out a script which queries the users setup to detect whether these conditions are met or not. (eg does it rely on the mysql extension to be installed).
Detail how to meet each of the dependencies in case they are missing.
Explain which is the minimum version number supported, if your script detects it is below that version number.
Test it on your target Operating Systems.
Run a script which creates a database, test whether that was created. Provide detailed instructions on how to do this manually, and how to provide the correct privileges.
If necessary give them a config file which permits them to enter key information such as doc_root etc.
Conform to common wisdom such as short_tags = off else override these settings. Imagine the user is on shared hosting and is running on safe_mode = on.
Try and follow your own instructions and re-install it on your localhost, then on a live server - ideally on a variety of OSs too.
In the past, I've always edited all my sites live; wasn't too concerned about my 2 visitors seeing an error message.
However, there may come a day when I get more than 2 visitors. What would be the best approach to testing my changes and then making all the changes go live simultaneously?
Should I copy and paste ever single file into a sub-folder and edit these, then copy them back when I'm done? What if I have full URLs in my code (they'll break if I move them)? Maybe I can use some .htaccess hackery to get around this? What about database dummy test data? Should I dupe all my MySQL tables and reference those instead?
I'm using CakePHP for the particular project I'm concerned about, but I'm curious to know what approaches people are taking both with Cake (which may have tools to assist with this?), and without a framework.
I've been getting a lot of recommendations for SVN, which sounds great, but unfortunately my host doesn't support it :\
The best thing you can do is to create a staging environment in which you test your changes. The staging environment (ideally) is a complete, working duplicate of your production system. This will prevent you from experiencing many headaches and inadvertent production crashes.
If you are working on a small project the best thing to do is to recreate your remote site locally (including the database). Code all your changes there and then, once you are satisfied that you are finished, deploy the changes to your remote site in one go.
I would recommend putting your website code under full version control (git or subversion). Test and maintain your source in a separate, private sandbox server, and just check out the latest stable version at the production site whenever it's ready for release.
For database support, even for small projects I maintain separate development and production databases. You can version the SQL used to generate and maintain your schema and testing or bootstrapping data along with the rest of your site. Manage the database environment used by your site from an easily separated configuration file, and tell your version control solution to ignore it.
Absolute URLs are going to be a problem. If you can't avoid them, you could always store the hostname in the same configuration file and read it as needed... except within stylesheets and Javascript resources, of course. My second choice for that problem would be URL-rewriting magic or its equivalent in the development server, and my last choice would be just messing with the /etc/hosts file when I wanted to test features that depend on them.
I set up a development server on my laptop that duplicates my web server as closely as possible (server software and configuration, operating system, filesystem layout, installed software, etc.) That way I can write the code on my laptop and test it locally; once I've gotten things working there, I copy it to the server. Sometimes a few problems arise because of slight differences between the two computers, but those are always quickly resolved (and just in case they're not, I have my site in an SVN repository so I can always revert it).
On another website I used to maintain, I used a slightly different tactic: I designated a URL path within the site that would be a development version of the base site. That is, http://www.example.com/devweb would ordinarily mirror http://www.example.com, http://www.example.com/devweb/foo/bar.php would mirror http://www.example.com/foo/bar.php, etc. I created a folder devweb under the document root, but instead of copying all the files, I configured the server so that if a requested file didn't exist in the /devweb directory, it would look for it under the document root. That was a more fragile setup than having a separate development server, though.
I have a number of websites written in CakePHP. I develop and test on my local machine, using the database on my production server (I just have a MySQL login that works for my static IP address).
All code is checked into Subversion, and I then have a continuous integration server - Hudson:
https://hudson.dev.java.net/
This builds and deploys my project on the production machine. It just checks out the code in subversion for a specific project then runs a simple script to SSH/copy the files into the staging or production location on the server. You can either set this up to be a manual process (which I have currently) or you can set this up so that it deploys once code has been checked in. There's lots of other CI tools that can be setup to do this (have a look at Xinc as well).
http://code.google.com/p/xinc/
As for absolute URLs you can always setup something in your host file to resolve the site locally on your machine instead. It works for me, just don't forget to take it out afterwards : )
Hope that helps...
I have a version of config/database.php that uses the php server variable "SERVER NAME" to determine which system the app is running on. Then when I clone my git repo across my home system, development site (which shares the same specs as the live machine), and the live machine they all connect to their respective databases.
I pasted here, but I also believe its available on thebakery.
http://pastebin.com/f1a701145