Staging or test site management
Create an ability for a Joomla install to manage both a live and staging site where changes can be tested on a staging site and then pushed to the live site when appropriate.
Why isn't Joomla doing this? So aggravating. !useful in most real world scenarios now.
This would be awesome. I am continuously changing and updating sites and this would help a lot when doing small changes and not having to continuously have a mirror site running.
This will certainly make some impact.
But when it comes to the users (authors) we are already saved with the version control.
development and staging sites I would just use a replicated version of the current live one.
Soon as development is finished, wrap your stuff in a new install package and test again starting from scratch in a new replica of your current. Done all that install in publish/production.
All it sort of needs is an "auto replicate my stuff" button with the abilty to select your dev or stg env. to make this all easy..
Certainly one of the most important and the most advanced ideas so far. If realized this will definitely launch Joomla to No1 CMS in the world.
I'm waiting with impatience
Mike Mayleben commented
This is a feature that is holding Joomla back from also being a major player at the Enterprise Level and keeping it in the lower ranks as Wordpress.
Scott Robins commented
Please Please introduce this. Even if you start off small ie dont have the ability to push updates from test to live.
1. Ability to have multiple test area's in the admin area and to be able to copy live and call it
2. Ability to copy DB or just point to live DB
Once this was done you could then look at pushing revisions from test to live and doing a diff compare of the 2 environments
As an aside, one of the enhancements to Joomla 3.2 is the
"Built-in Joomla! Extensions Finder as an onsite interface to the Joomla! Extensions "
This is a nice enhancement....BUT how on earth did this get priority over something like this proposed feature ? What genius / genius's decided this ?
No comments for 3 years? Holy mackeral... has this idea fallen completely off the devs' radar?
If Joomla want to seriously penetrate the Enterprise level such option will be of great value. I am specifically someone who needs such solution in my organisation as we use more than 20 joomla websites with several simultaneous collaborators in terms of content management and extension developers. Testing modules then moving those to a pre-production server then moving finally to the production site is a pain as we have to use rsync (for files) and DB replications techniques for this method to work.
Such solution would really help.
Keith Mountifield commented
Go away spammer!
Well honestly speaking thank you, I have recently been searching for information about Logo Design actually this topic for ages and yours is the best I have discovered so far.
Richard Pike commented
This a "have to have" if you want high quality websites. We have just added another piece to the puzzle by creating webseam. It takes your staging site and presents it to your clients. Webseam then let's clients edit web pages to give feedback to their developers. But they are not real edits instead they are captured and provided by the tool to the developers as a list of issues and bugs. Then when the page is fixed the client sees it like Word 'track changes' so they know what was fixed
Alberto Corona commented
This is a common feature in enterprise level CMS like CQ5 . It seems most comments here not agreeing with the need for this feature are missing the point that a CMS is not intended just for hard core developers/administrator. It should make it easy for content managers to make changes to their site, have them reviewed and then when approved promote them to production. This typically include tasks such as adding a new menu, editing an existing article, re-arranging existing modules. For these scenarios, I see no need for someone having to work trough scripts to merge changes from one site (staging) to a another (production). Why not just an option in the content element to be promoted to production...at the minimmun this is only a matter of having version support in all db data with at least two versions (staging and production).
For more complex changes such as completely removing a component and replace it by a new one, or making code changes to existing components, that I understand I may need more control and need a separate physical server to test, debug and fix. Then do the migration to production using scripts, git, svn...etc.
No you all got it wrong, this wouldn't be helpful but essential to any one that has more than one joomla site live on the internet.. It really upsets me that no-one needs this service.. How long do you think it takes me to update a few joomla website as per client specs.. I need to do it twice for every site each time (on dev and then finally live)
I don't care if it is a third party extension that costs $200 for owned license! At least wont have to struggle and waste countless hours configuring SVN and RSync to even consider something like this..
I even tried using JFusion and have a master/slave joomla addons configured..
Unfortunately, Jfusion's documentation and support is utterly useless..
this is something we've been requiring for years now sinse joomla 1.5
So for everyone that says WAMP/XAMPP or not required please go get some live website running and get a feel for doing updates regularly. Then we can talk again
AkeebaBackup does this already. The "hard" part is knowing what tables and files are immutable by end users. If anything I suggest a new Joomla table like #__immutable_tables that all extension devs and Joomla devs can store immutable table names in. Then any tool can look in that table and only transfer what is listed in it from a staging site to a live site.
I suppose a #__immutable_files would be good too.
The concept being simply if a user can mutate the data it cannot be sync'd. But if only the admin/backend can mutate the tables then it is safe to assume the admin is only making changes in the unreleased site.
http://www.ostraining.com/blog/joomla/creating-a-joomla-development-site/ apparently this does the trick to have a development site then push it out to the production site.
Fantasic Idea, as a noob to joomla I have learned the hard way what i can and cant do before it impacts my site. I think a test site that I can load and test extentions on etc. would have saved me so much time. A facility to take snapshots of the test site so you could rollback would be very handy too.
Web Design Hero commented
Full site replication is not staging. In a real site, you cannot simply overwrite your live site with a stag/dev site. Joomla has a few factors you need to consider - such as content is separate from design and that you need to manage content created on the backend and by authors/admins as well as content created by visitors - forums/comments. You need to merge individual tables in most cases and keep various things in sync. For the most part, in terms of content staging you can deal with a simple cut and paste, an automated script to push specific article from one db instance to another, or you a versioning extension which allows a preview version that can be activated on the frontend for a given user or GET parameter. As one other commented, these are not really Joomls things. If you are at the point in your development where you want a staging server, you should be able to handle these things under the web application.
Good idea, it will be nice to list and compare the changes (files, content, menus, components etc) and then choose what to push
Davide Bartolucci commented
Too bad I can't place votes, this would be a +3.
Steve Amerige commented
For most non-trivial websites, the ability to work on a staging website and then promote it to be the production website is essential. Right now, I do this by hand for most of my clients. The thing that is needed is for Joomla to provide a formal way for Extensions to EXPORT and IMPORT their content. This must be a first-class feature in the Joomla core because things like database names, hostnames, and other things change from the staging server to the production server. So, at a minimum, if the Joomla core provided export and import capabilities for extensions that the extension provider could write code to, this would help tremendously. If Joomla marked extensions as "Can Migrate" with some icon, this would encourage extension developers to provide the migration (export/import) functions. And, of course, the Joomla devs would have to provide the export and import functions for all of the Joomla core. This is why there are people whose job titles are Release Engineers. It's that important!