I need a reference about staging on Drupal 7.
My requirements are:
Content Administrator can perform editing of content in STAGING instance
Can preview the changes without impacting the PROD server that visitor sees
Only when the admin says "DEPLOY/PUBLISH", the changes are pushed to PROD
Any suggestion about what module should I use? Thank you.
Why should this be a module at all?
Staging should be a different deployment with a separate database and url.
If you've crossed that option out because you haven't found a way to move across "build" information stored within the database, then look at the features module.
I'm not sure if there is a solution like that ready, you could try making something with the domain module where content administrators can publish only in staging domain and the admins can publish to all domains. http://drupal.org/project/domain
Edit: to elaborate further, admins could go to the node list and choose which nodes to publish into production, or edit the node and change the domain where that node is publishes.
Hope this helps.
If you just want to provide the ability to administrator to edit content without impacting live content, you can use the revisioning module : http://drupal.org/project/revisioning
No need for a separate staging server for that, it's the purpose of a cms after all.
Related
I want to set up a system where a developer can work on a separate server on a wordpress website.
My question is: If in the meantime changes are made to the live site (like plugin updates, new plugins, new posts, new comments, etc), how is one able to import a new feature (e.g. a new page) from the development server on the live site while making sure that previous changes on the live site don't get deleted?
I am looking to understand how this all works. In a sense, I would like to have some kind of version control system.
Thanks in advance :)
You can version control your own code using git. Basically we would init a new git repo and commit changes onto this repository. This can lie separately outside of the core files. i.e you only need to include the wp-content directory and ignore all the other core wordpress files.
Here is a good article on how to do a really good versioning system for a website.
http://toroid.org/git-website-howto
The posts and pages (basically content) in a wordpress site however lies in the database.Any changes made there will be permanent.
The only option is to keep taking regular backups of the content. You can do this by using an automated backup tool.
If you really want to version control your database, here is an article that helps:
https://blog.codinghorror.com/get-your-database-under-version-control/
This one is a tricky one. You cant host a single website on two servers. Just imagine a website having 2 hosted urls..!! No way.. You can never do that.
You better create a new user and give access to him. Look carefully in the settings and be a admin. You will have a chance to approve or reject what the second user changes.
Hope this helps.
I am in the process of creating a staging site for my woocommerce shop.
Wanting to protect access to it, I put it behind an HTTP Authorisation.
However, this means that PayPal IPN will not work.
This site is only for my testing usage. I do not want people creating accounts on it.
However, as it is supposed to be using exactly the same code base as production I cannot envisage disabling the signup code.
This is my dilemma.
What can be done to protect this site from unwanted access, still leaving it as a correct copy of production code ?
What I would do is to create a new site under another domain name or subdomain without making the DNS pointers. You would then need to set the pointer in you local hosts file. The site would then work like normal for you but without the entry in the host file you would not be able to access the website(at least not in a normal way without manipulating the requests). As you probably guessed, this is not super safe if you really don't want anyone else to access the staging site, but usually that is not a big deal. No one will end up there by misstake.
Secondly I would create a script sync the production environment to the staging environment. This can be done quite easily using WP-CLI (wp db export db-dump.sql + wp db import db-dump.sql + wp search-replace domain.com stage.domain.com).
I have the impression that there is no ideal solution to this question.
This is my solution - others may have better or alternative answers though.
I created a special sub-domain under a different domain.
I then installed all necessary code and setup the site as if it were a production site. Then I created my test accounts and disactivated all account sign-up links.
I have been able to setup paypal sandbox as well.
This gives me a staging site using the same code base as production where in I can test all changes and updates before applying them to production, without having the risk of using existing client data.
This meets my needs. I hope it may be useful for others.
I have developed a site using drupal. Now I moved from test server to live server. Now if I make changes to the test site its reflecting to live site too. I am surprised. Please could anyone tell that how should I fix above problem.
Ok, assuming you mean changes at the content level (like content types, menus, taxonomies, users, ..), then it probably means you're sharing the database between the two sites. You'll need to point the one of them to a copy of that database so you split the sites. This can be done by adjusting the sites/default/settings.php file typically.
Not sure if this is the right place to ask, sorry if its not. I build a lot of Wordpress sites. My problem is, the number of them is getting big and harder to update them all when new releases come out.
I have written an app that will download the latest Wordpress release, and manually ftp the new files to all the clients, but this takes forever... need a new way.
I wanted to restructure this while I can or start a new process at least. Whats the best way to manage multiple Wordpress sites and keep them all updated? Some people have said 1 DB and modded config, others I have seen said to keep all installs separate and use plugins to automatically upgrade, but I don't know whats best to do. Ideas? Thanks :)
If these were all sites you managed on your own server, I'd recommend using a Multisite installation rather than separate instances of WordPress. This way you only have one set of themes, one set of plug-ins, and one copy of WordPress to maintain.
If these sites are on different servers (i.e. you're maintaining sites for clients remotely), I'd recommend you look in to a beta account with WP Remote. This is a service specifically built to allow you to remotely monitor and update multiple WordPress installations. It might be the best solution for you because it allows you to use the one-click update rather than manually downloading/FTP-ing the new files.
You can use this free self hosted app http://infinitewp.com
No limitation in number of sites being managed. You can update WP/plugin/themes, do backups, one click login to your WordPress admin panel.
EAMann is right, especially with the new Multi Site features in Wordpress 3.0, there is no better way to manage multiple sites under one umbrella. Being a developer myself, I know the pain of having to login to all those different accounts!
The way to set it up is create a "master domain name" that you will log into. Place this in your WP Config:
define('WP_ALLOW_MULTISITE', true);
Then login to your admin panel, navigate to TOOLS>Network.
After you've set everything up, copy/paste what it tells you to your HTAccess and WP Config file.
The next step, especially if you are putting clients on this network, is they will want their own domain name, not AIBot.com/theirname right? Thats where Domain Mapping comes in:
http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/
Check that out and good luck!
What you need is www.managewp.com it can do all of that for you plus a ton of other excellent features.
I want to move a drupal site to another domain and am looking for best practices, gotchas, hint, tips, etc to make sure I get through it smoothly.
Links and comments are appreciated.
You might want to give a try to the Backup And Migrate module.
There is also this handbook page that gives instructions on how to backup your drupal site.
It took me 1-2 hours. I do not have a step-by-step guide (I wish I had written everything down), but it entails updating the configuration files, updating the database (some tables have domain references, but I don't recall which - it could be that this was just for my image references in the Gallery2 database), and doing a cursory search of the content for full domain references in anchor links.
I migrated a Drupal 6 site with about 40 plug-ins, including Gallery2 and Google Maps integration, and I did not run into any major road blocks.
If you (and the authors of the contrib modules you used) did a good job by not putting absolute URL's in the code, it should be dead easy (I do it routinely when migrating the development site to a live production one, for its launch).
Of course I assume that you are doing things sensibly, and for example are not migrating a site from an apache/mySQL server to a nginx/postgres one, maybe also adding the need to prefix your DB tables in the process.
If this is the case, then you simply have to copy your entire file tree and export/reimport your DB.
If you are migrating between two similar architectures then chances are you will only have to change a few things in the settings.php file. The file is well documented. The only two things that I normally have to change are:
DB user/pass
cookies domain
In the file there are also additional configuration options like the possibility to choose the base URL manually in case of problems.
Don't forget to flush the cache once you log in the new migrated site for the first time.
EDIT: Just came to my mind: if you use any, you will also have to update your developer keys to third party API's (for example if you use google maps or google analytics) as these are domain specific.
HTH!
Basically, what mac said (+1)
In addition, I often need to adjust the .htaccess files a bit concerning the rewrite rules. For smaller sites on shared hosting environments, I usually place the drupal installations in subfolders within the document root (e.g. to allow for staging, etc.), 'hiding' the subfolder via URL rewriting. So for every 'move' of a site, I need to fix those rules.
The biggest culprit for me are sites that use modules that have to store absolute URLs in order to do their job (e.g. securepages). For those you should disable them prior to moving the site, adjusting their settings before reenabling.
If you are not sure if some of the modules you use store absolute URLs, it might pay of to extract your database dump locally and search the resulting file for occurrences of 'http://', 'https://' and the likes, as well as for your 'old' domain name (you'll need to exclude the watchdog and cache tables for this).