Is there a good option for having more than one person developing a Wordpress application with a testing site.
The biggest hurdle that I have encountered are path issues when developing locally and integrating to a testing environment.
Does anyone have a good process for maintaining developer environment(s), keeping working content and links, and the code is maintained in source control?
To clarify, I would like to develop locally, and have a testing environment, and avoid path issues. I am open to other solutions, or ideas.
It comes down to three main concepts
Development environment should be as close to production as possible.
Use Source Control!
Automated Deployment Scripts Take out as much human error when deploying.
The development enviornment/process I prefer looks like this.
Dev/Local
SVN To Check Out Code Locally
Virtual Box running Ubuntu as a Solution for LAMP Environment or XAMPP
Deploy Scripts (Script Automation e.g. NAnt/Ant) For Staging / QA
Module Development
Theme Development
Etc
QA
Initial Content Setup / QA
After Initial Development Staging is Used Less
Production
Live Content Entry
Blogging Etc
As for path issues after initial content development path issues become less relevant, as most content is performed live. If a backup of production is used to create a dev site, SQL scripts and manually changes can be used as necessary. Also switching to using a Virtual Box solution helps ensure everything is in root. But the answer by FractalizeR does help.
May be I don't get the problem in a whole, but what is the problem of putting the whole source code of WordPress into version control, check it out to a single test server for tests?
If you have problems with site names, force your developers to check out to their machines and store it under www.yourwpdomain.local (mind the .local part). They can use DNS or simple hosts file to resolve .local domain address into 127.0.0.1. Apache setup is pretty straightforward.
The rule is Separation of Concerns. You should not place your compiled components like DLLs, EXEs, or data of a system in source control. Wordpress is included in this context for two reasons: 1. the site is stored in the database. 2. The database and the site had better be on a nightly backup schedule. Would you ever need to restore the db or WP from Git? Heck no! Additionally, any WP customization should be placed in child themes, that will be included in source control. The parent theme? NO WAY! Never customize the parent theme in WP. If you are making changes to your base Wordpress site and\or parent theme, then you are at risk of losing your customization when Wordpress or the theme is updated.
Related
Scenario:
My team manages multiple Joomla websites for our clients. While we manage the development/hosting of the sites, the clients do all of the content updates (creating articles, content, uploading images etc...)
We run these websites in the following standard configuration where we have
A development server
A staging server
A production server
The client makes all of the content updates to the production server (on a daily basis). The other two servers are used primarily for new development and testing.
We currently are using, BitBucket as our SVN for these websites (we are just starting out with this). Currently all files pertaining to the website are stored in the repo.
The Problem
Based on our current setup, if a developer makes changes to the dev environment, and that change set is then pushed to the production environment, we end up overwriting all of the content updates that our clients have made in the production environment.
My Question
How do we successfully utilize a source control system, and maintain the flexibility to allow our clients to continue to make updates directly on the production server, without forcing them to make content changes on dev, staging, and then production?
While you briefly described your workflow, there are some things to be considered. There is no general rule, but look into the following suggestions:
Put into version control JUST the extensions you have developed (template, components, plugins etc.). The customizations are anyway the only things you add to Joomla. Hopefully no core hacks. Alternatively if you really want to version the whole installation, you should at least ignore media folders that are changed by the clients / you. I see no need to put the whole Joomla site under version control.
I imagine your clients are not actually changing PHP scripts, just media files and database entries. You should only push to production code and / or database schema changes.
If you are relying on a commit - push to FTP feature, or manually pushing files, I would suggest looking into building a distributable version of your changes, in a form of a package that can be deployed via the Extension manager. Building packages can be done in one click with a tool like Phing. For example if you make some changes to the template, create a new template version, create the package and update first the staging server / testing server and if all goes well, the production.
Some things shouldn't be in version control.
In general, source code should be versioned and data should not. I'm not familiar with Joomla, but any kind of "uploaded content" directory should be in the ignore file for your version control system. That way you can deploy changes to the software without worrying about overwriting data.
Of course, your data should be backed up regularly, but that's not what revision control is for.
If you have
a staging server where you test the website changes (layout, new functionality, new css)
a production server where the user publishes new content
you need partial database updates along with file synchronization.
The database is pretty hard as the assets table may be affected both by configuration changes on the staging server and by new content on the production server; for this and any other shared tables, we address the issue by making sure the ids don't conflict right after the update leaving a sufficient gap.
Although - to quote most other answers - revision control is not for data nor for the database, it is indeed very nice, especially with pre and post-commit hooks to perform the required database actions; however, any scripting/publishing tools going from rsync-rdiff to phing to ant - maven will do
I am about to use WordPress as CMS with a lot of customization, but my question is, how should I sync development to production?
Assuming WordPress is not used, a typical development cycle is to develop the pages locally, and create the DB scripts. Then when everything is ready, it is posted to the site. And then again, more db and code changes, then only the changes are updated/applied, and so on.
Now, with WordPress, you get all the great features (one example is blogging, comments, almost ready CMS ...etc). However deployment is a pain! Ideally, I would rather keep my typical development cycle described above. Therefore I am going to be implementing WordPress locally (from wordpress.org) and then pushing the changes to my production server.
So, assuming that I create a new page in WordPress locally (I will never create pages on the server, all locally, I will find a way to disable wp-admin for the server), a number of files are created. This is not a problem so far. HOWEVER, if I want to add content to that newly created page, that content is saved to my local database. Even though that content is a database change, it is considered (from my point of view) a new change that should be pushed to server rather than add that content via the live server (because that content is considered static, it is not a blog post or a comment, it is a static page).
Now, that new page content is saved to the DB, and therefore, the DB will have changes done on my local machine that I should push to the server along with the files that I will FTP to the server.
My questions are:
Is this approach correct? If not, what do you suggest
What is the best way to find database diffs? What is a tool to use? Does MySQL Workbench provide something like that? I intend to use that tool to find diffs and then generate an update script for the DB. The reason for this question is I normally make the changes myself, and I know how to track them, but now, those DB changes are generated by WordPress and I need to reverse engineer them to find out which changes are made.
Assuming I got step 2 to work, is there anything in that script that should be modified? Such as server names? Does WordPress hard-code server names for example?
So to summarize and give you more information about my development environment, I use XAMPP for development on Windows 7, with PHP and MySQL setup. I also use Mercurial for source control. As mentioned above, I will use WordPress as part of the solution and I intend to use it to help me create a CMS solution. I will use it locally for page generation, and disable that feature for online (keeping online for blog posts and similar entries only). I am doing that so as to keep things in-sync. If I create a page locally, some data is saved to the DB. Now, how do I sync/upload?
Thanks.
OK, after further investigation, here is what I concluded.
All theme development should be version-controlled
All plugin development should be version-controlled
Content of pages and posts are not part of the development porcess, this is contect and should only be backed up.
This way, you do not need to worry about DB changes ...etc.
Hope this helps everyone.
You might use a Version Control System? What OS is the development on, e.g. Win or Linux? And what is the production OS? I use http://serverpress.com for my testing environment though there are others, WAMP, LAMP, etc.
I develop in PHP with NetBeans. The modifications are uploaded to a virtualized LAMP dev server on my machine directly by NetBeans.
I would like to branch some developments.
The problem is that only the trunk is sent to the server.
I use a classic structure:
{svnroot}/trunk
{svnroot}/branches
{svnroot}/tags
How can I test the branches without doing a crazy branch/trunk swap (with all the possible conflicts)?
Is there a solution with an htaccess configuration?
Should I use SVN differently?
Should I use NetBeans differently?
Most SVN setups have a few top-level directories
{svnroot}/trunk
{svnroot}/branches
{svnroot}/tags
If you lack the "branches" top-level directory, add it. Then use svn copy to copy in all the contents from "trunk".
If your web server pulls the code in such a manner that your "branches" directory gets pulled into the web server, that's a deployment issue concerning your web server, and whoever set that up needs to fix it.
Sometimes a person side-steps having a release plan by doing a svn checkout of the code directly into the web server. While that works for a very limited number of cases, it reduces your ability to handle future events without migrating to a more sophisticated release plan. If your environment tends to do something like this, you might be able to continue to follow your plan by selectively checking out only the sub-contents of "trunk", or you could migrate to a proper "build" of your release, which then goes through a "deployment plan".
If you lack the "trunk" directory, before attempting anything, you might have to create the "trunk" directory and move all of the current contents into it. This means that all development would need to checkout from the "trunk" subdirectory instead of the {svnroot} directory. This is done by extending your URL (adding "/trunk" to the end).
I hope this gets you thinking along the right paths.
You could checkout everything onto the web server, and use symbolic links (or junction points with Windows servers - see Junction.exe from www.sysinernals.com ) to switch between test/production environments. Or yes, you could use .htaccess to change where your web root points to. As others have said, it's usually a good idea to have separate test/production servers.
We are a small team developing PHP applications in a LAN. Both on Mac and PC.
Individual developers check out and edit source code to their own machine, on which Apache is running. Local testing is then done over localhost.
For the DB, the application connects to a common MySQL installation, on a dedicated machine in the LAN. This works quite well because we rarely make (destructive) changes to the DB schema. This means that all the individual applications running access the same test data.
But uploaded files remain a problem: they are only uploaded to the dev's local machine, although a reference to them is stored in the central DB. This means that the other team members may be shown a broken link for a user uploaded image, that physically only exists on one devs local machine.
The ideal solution would be to have the entire persistance layer on a central machine. Any ideas on how best to achieve this?
Map a network folder or use a service like dropbox or similar. A local db is nice to have though and doesn't take up too much resources.
Basically you want some sort of shared filesystem. There are lots of options: a samba share, an NFS-mounted directory, Dropbox (or a similar service), etc. I would suggest looking into the available options to see what suits your infrastructure best.
i have dealt with this once and what i did was to use our NAS as the storage of everything. we developed our website on the NAS itself over FTP. it was like cloud development, IDE only on our side, every file we edited, image uploaded and so on was on the NAS. the website itself was also running on the NAS (since the NAS has the ability to be a server and have mySQL)
the NAS was turned from a network storage - to an actual local server.
By how I understood your question, i assumed you only needed to share uploaded resource (like images) and not develop in the same app at once.
First I suggest that you DON'T develop on the production machine at all.
Now, here are 2 ways you can do it though:
Modular Development:
you develop independently. You don't touch each other's code. you develop features separately from each other. that way, you won't be stepping into each other's shoes. this also promotes "loose coupling" which in le man's terms, "when one feature breaks, the other's won't"
you should check out this video on how you can break down your development into "modules". This is in JS though, but the architecture can still apply.
Version Controlled Development
Break your development into 3 layers:
Production (aka Stable) is the code that is public. You don't develop or touch code here. You only publish the code only when it is tested thoroughly. Also, this is NOT the public server. this is just the public code. however, what lives here is the actual replica of the public site.
Testing (aka Beta) is where you test your developed code. This system is for testing purposes only. You don't touch the code here either. You are just here to find bugs on your own. It's your "Quality Assurance Layer". This layer is also where your codes merge (discussed later)
Development (aka Alpha) is where you touch your code. Here, you share your code, test it, break it, try new features as well as fix the bugs you found in Testing
as you can see, you don't break your systems due to overwriting, or broken links etc.
Now, your development strategy. Use a version system like GIT (distributed) or SVN(central) and create 3 branches according to the ones above. For this example, this uses a distributed approach (i prefer it)
Assign a "maintainer/ring master" in your group who consolidates your work and publishes it to testing. What this maintainer does is to collect your "finished" developed code and puts it into his testing branch. anyone can then clone his testing branch to your testing branch to test your code. Whatever bug they/you find, you refine in the development and submit it to him again. only after that feature is quality assured, then the maintainer can publish it to the stable where he clones it to the public server.
After all that's done and when you have moved on, you just clone the stable branch to your development branch and you start anew. Now you have a fresh canvas to play with.Overwriting is handled by the version control system, and the maintainer. you need not worry about that.
as for resources, you would not want to bog down your local development system with arriving resources from the public server. version control systems also have "ignore lists" to prevent you from cloning some resources. clone only what's necessary. if you are developing a weather widget, you only need images for weather widget. you don't need images from the other widgets (unless neccessary)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 12 months ago.
Improve this question
I work for a company that does sites for the pharma industry and we often need to get legal approval before we push any changes live. So, I'd like to migrate a lot of our work to a CMS environment, specifically wordpress but we need the ability to have a staging environment. Is it possible to instead of publishing a page have it publish to a staging environment that someone can browse as with a link as a site. So basically have 2 sites, one staging one live?
Generally speaking other "answers" here are correct, there are alternatives to WordPress that have better built-in support for staging environments and build migrations. However the suggested alternatives aren't exactly equal substitutes to the WordPress platform, so I think it's best to answer the question at hand instead.
WordPress does not natively support hosting the same site from two different hosts. The core relies on absolute URLs stored inside the database and are used in just about every aspect of the core logic. This results in a number of superfluous bugs like the 500 or so related to SSL access because they try to dynamically alter all http:// schemes to https:// on the fly.
As a result when you host on dev.example.com and migrate to staging.example.com and again to www.example.com you have to do very careful search & replace manipulations on the database export each time you switch hosts. And this causes additional problems when you find out that many popular WordPress plugins serialize the URL into values in the database. So when you search & replace dev.example.com with staging.example.com the serialized data which contained the character length of the original value no longer deserializes with the new longer format. Some core contributors believe the solution to this later problem is to only ever setup staging sites with the same number of characters as the production account...
In a similar vein they also suggest swapping host mappings and only ever using the production.com URL on all hosting environments. Depending on your particular use-case requirements this is probably not a valid solution if you need to provide access to off-site clients, tech-illiterate users (versus tech-literate users of course.)
But WordPress itself has a number of great features otherwise and is a very adaptive and powerful rapid development platform. As a result you can extend the core framework to do much of what you need from it. When I was presented with this situation, I had to develop a solution that was viable for all circumstances. Traditionally this problem is solved with root-relative URLs, they work in cross-hosting environments, and they don't suffer from scheme changes, port changes or subdomain swapping practices that are common with staging migrations.
With this plugin: http://wordpress.org/extend/plugins/root-relative-urls/
(biased? yes, I wrote this plugin.) you get root-relative URLs where it's important and dynamic hosts where root-relative URLs don't work (like rss feeds.) All that remains from migrating the site to different hosts is to move the wp-config.php file outside of the www root (one level up is supported natively by WordPress.) so you can maintain different copies on different servers. Or alternatively you can use basic if-statements to distinguish hosts by server name and define key WordPress constants based on the server. In the end your content, code & data will transition seamlessly.
As a note of concern, the referenced plugins require setting write access to the wp-config.php file, a very bad practice from a security perspective for production or publicly accessible servers. Perhaps you can comfortably implement this in a restricted staging environment but then you'd need to disable and remove the plugin in production transitions.
Long story short, yes you can host WordPress in multiple host environments. The long-touted solutions are very case-specific and option-restricted because of the core architecture. But the framework is flexible enough to overcome the core deficit. This core design decision will probably change at some point in the future given the amount of effort the core developers continually spend on overcoming the cascading issues. But there are also devout defenders of the absolute URL religion that will keep the practice in place for the time being. Maybe a different platform that supports server migrations natively (pick just about any of them because most do) would be a better option for you now.
It's possible: Take a look at this Github Gist to see an example on how to switch environments with your wp-config.php file. Furthermore, take a look at wordpress.stackexchange to see some other Qs about this that give you a more in-depth look at the stuff you should consider.
Greg,
An even better CMS with staging environment would be Silverstripe (silverstripe.org). This cms allows for you to browse an entire staging site.
I think that you can try to use some plugins.
For example (fast search on official wordpress plugin repo) wp-deploy or Dev and Staging Environment Plugin (maybe outdated).
Or as alternative you can try to use different wp-config.php files - one for production and one for dev environment and switch them by checking requested url.
If you need to use WP, and need to publish only one or several pages from staging to live site, why not implement kind of tag on pages that needed to be published (seen by live site visitors)? Simple tune up your templates to display tagged or not pages and you're done! Then you can use only one site and maintain both public-available and not-approved pages on the it.
You can as well maintain local copy of your site (stage) and have some script to upload it (at whole) to your hosting - easy to automate task. In such a case, you may want to consider render the whole site into HTML pages and upload (simple rsync) this HTMLs to hosting - the live site will be hard to break as no dynamic script will be there!
But maybe you really should not choose the WP? There are a lot of CMS that support write-approve-publish scheme.
You can create a WordPress Staging environment with just two click with the help of this plugin: https://de.wordpress.org/plugins/wp-staging/
Disclosure: I am the author of this plugin. So ask me anything about it.