Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Suggestions for site redesign workflow?
Experienced TXP user here, about to embark on a major site redesign, and I’m not sure what my workflow should be. In the past I’ve always just modified the live site, and when I’ve broken something I’d usually made a copy of the relevant form or template to go back to. Sometimes not. There has got to be a better way?
I should say that I’m going to be modifying not just CSS, but also forms, pages, etc., and maybe even going into PHPmyAdmin at some point to mass-edit certain old articles. Big revamp.
Obviously the full-on approach would be to set up a local development environment with an SQL server, git repository, and all. But that is a bit out of my comfort zone and even then I’m not sure I’d know how to merge all the changes back into the live site. So, is there a commonly accepted in-between approach I’m missing? What do y’all do when you’re playing around with new ideas?
Yes, I have tried turning it off and on.
Offline
Re: Suggestions for site redesign workflow?
Perhaps follow the methods I’m setting up here. Then either use rah_flat plugin or copy the various forms/pages manually into your live site.
Offline
Re: Suggestions for site redesign workflow?
Hi Alesh. A lot of people seem to be using rah_flat these days, which is the new cnk_versioning. That will, however, only allow you to track changes to Pages, Forms and Styles. Better than not tracking at all and wishing you had a backup!
Jukka also has rah_post_versions which is versioning for articles, and it’s really good. But it only works if you make edits inside Txp.
When using phpMyAdmin, as I’m sure you’re aware, regular backups of your DB before any major changes are a good idea. And download the .sql file. There’s also rss_admin_db_manager which allows backups to be taken from within Txp, but it can choke on odd collations.
If you do decide to do the whole git thing — and it really is worthwhile — you can even put your DB backup files under version control if you like. At least you’ll have an immutable copy in case you overwrite one by mistake.
I don’t mean to come off as condescending if you know all about versioning but I’ll go through a quick setup here just for the sake of anyone who finds this thread and who might think it’s a bit daunting.
If you can install git on your server, great. If not, once you have git installed locally with command line (because it allows much more flexibility, imo), if you back everything on your server up, install rah_flat, get it to create your template files, and download those files to your local machine, you can then do this from the git console:
cd _templates
git initto start tracking changes. Since you want to track all changes to this folder, you don’t need any .gitignore exclusions. You can then make a few changes to your files, upload them, test them on the server somewhere (a staging clone of your site, or if you want to keep everything local, on a LAMP environment) and when you’re happy with tinkering, issue these commands from the git console:
git add .
git commitThat adds any changed files to the staging area and commits them as a roll-backable stamp. In the editor that pops up, add a short log message to remind you of the changes you made, e.g.:
Made checkout responsive
Cart is now more streamlined due to updating the doohicky with crunjo whatnot.
Also took a lumphammer to the CSS, removing unnecessary rules.That’s it. The first line is deliberately kept short (usually under 50 characters). Everything else is optional and can be as brief or as descriptive as you like. If you bodge up later or decide you preferred the older iteration, you can just check some or all of these files out and upload them to restore everything.
If you download your DB as a .sql file, stuff it in the _templates folder and do the git add . / git commit dance again to include it, with a suitable log message.
Within reason, the more frequently you commit, the more options you have to roll back. You don’t need to mess about with branches and stuff just yet. Keep the differences between commit points fairly small: you’ll soon get a feel for what makes a good change set. Even if you just changed a couple of CSS rules to fix a particular visual glitch, get in the habit of committing afterwards once that bit’s “done”. That gives a nice documented flow to your development and allows plenty of opportunity to inspect the logs, find out what you did, when and why.
It becomes second nature pretty quickly and you’ll wonder how you ever did without it. Once your git-fu increases you can start getting fancy and doing branching to separate site features, but that’s for another day.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Suggestions for site redesign workflow?
If you’re going to do a big revamp that affects several forms and even the DB, I’d definitely suggest working on a copy, whether locally or a duplicate installation online.
Locally has the advantage that you can work faster and if you use rah_flat or cnk_versioning, you can work on forms, pages etc. as files in the editor of your choice and just save and refresh to see the changes (it’s easier than you think to get going but read the docs, especially with rah_flat, because it cleans out the forms and pages). MAMP/XAMPP etc. make it very easy to get a local webdev environment set up. With MAMP Pro (the paid version) you can set up a local test domain painlessly (e.g. dev.domainname.com which helps test any domain-dependent stuff you may have) and alter the PHP version etc. to (more or less) match the server constellation. It honestly doesn’t take long to get going.
If you’d rather not do that and have access to the site’s server, you could make yourself a test subdomain via the host’s control panel with it’s own directory and txp installation, and a second database for your experiments. When you’re happy, you can switch the domain settings in your host’s control panel to direct www. to your new site, replacing your test.domainname.com. Then you just need to update the txp settings to reflect the proper domain name and it’s immediately active.
(Tip: if you don’t restrict public access to that parallel subdomain, I usually use ied_if_domain and a variable (for example via adi_variable) that holds the proper domain name as a way of discouraging google and co from inadvertently logging duplicate sites: set meta robots to none if it’s not the public domain, switch off any analytics and use the variable with the proper domain name to construct your canonical urls so that if google does chance upon it, it logs the url you want it to use (in future). When you switch to the proper domain later, it all works again.)
Probably the biggest problem is if your main site is regularly updated while you experiment with your own site. At some point you need to sync the two. There’s no easy solution, unless you know you have kept things separate, e.g. the “textpattern” table with the articles is only edited on the live site, and your revamp has only affected txp_forms, txp_pages, txp_styles etc. Then you can probably swap out just parts of the database.
[EDIT: late again, and quite some duplication, but maybe useful all the same ]
TXP Builders – finely-crafted code, design and txp
Offline
#5 2015-06-06 00:14:20
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Suggestions for site redesign workflow?
In this scenario would have three copies of the website. One locally, where I can do all the hard development work of the redesign (and generally bugger around with impunity) – this local version would be a copy of the original live site.
The second copy is a staging version, located online (in a subdomain of my own site), which is available for the client to review. I use aam_if_host to ensure Google doesn’t crawl it (robots no index) and that stats aren’t generated.
The third copy is the live site.
There’s obviously no versioning going on here – it’s all a question of understanding which site is the master copy.
Tools used:
- rss_admin_db_mgr to make & restore DB backups
- FTP to transfer CSS, images, scripts, backups
- adi_prefs to adjust TXP preferences after restoring backups
If you can’t freeze changes on the original live site or there’re too many changes to have to reproduce them on the development site, then this system won’t work so well but I hope it gives you some ideas.
Offline
Re: Suggestions for site redesign workflow?
Thanks adi. aam_if_host I’d obviously missed and adi_prefs I’d forgotten about. Good to know there are other (probably better) ways of doing the same thing…
TXP Builders – finely-crafted code, design and txp
Offline
Re: Suggestions for site redesign workflow?
Very interresting post. Thanks for sharing your wokflow.
I think workflow categorie should exist in txptips.
Offline
Re: Suggestions for site redesign workflow?
sacripant wrote #291387:
Very interresting post. Thanks for sharing your wokflow.
I think workflow categorie should exist in txptips.
That’s easy enough to do as and when a tutorial/tip comes through to us.
Offline
Re: Suggestions for site redesign workflow?
Thanks Stef and everyone else. I am doing it: got Vagrant set up and textpattern running locally.
Somehow tho I am unable to get rah_flat working, and I don’t see explicit instructions anywhere. I’ve installed and activated the plugin and gotten {"success":true} when I access the activation URL, http://192.168.33.10/?rah_flat_key=********. I don’t see the template files anywhere tho. I’ve tried creating a ‘src’ folder with ‘forms’ ‘pages’ etc, but still nothing. What am I missing?
Yes, I have tried turning it off and on.
Offline
Re: Suggestions for site redesign workflow?
alesh, rah_flat doesn’t do the initial creation of files. You have to do it “manually”. Once you have the files created, rah_flat will look into the corresponding template folders and “suck” the files back to the database.
I’ve written a few simple python scripts to help with the initial creation of template files.
Offline
Re: Suggestions for site redesign workflow?
Hi Maniqui,
Tried the scripts, and I get a ImportError: No module named MySQLdb.
I’m running this on Scotch Box in Vagrant.
(I also get the following errors. Anything easy I should be doing here?
File directory path is not writable: /home/acch/artandculturecenter.org/files
Temporary directory path is not writable: /home/acch/artandculturecenter.org/textpattern/tmp ?
The following PHP functions (which may be necessary to run Textpattern) are disabled on your
server: pcntl_alarm, pcntl_fork, pcntl_waitpid, pcntl_wait, pcntl_wifexited, pcntl_wifstopped,
pcntl_wifsignaled, pcntl_wexitstatus, pcntl_wtermsig, pcntl_wstopsig, pcntl_signal,
pcntl_signal_dispatch, pcntl_get_last_error, pcntl_strerror, pcntl_sigprocmask, pcntl_sigwaitinfo,
pcntl_sigtimedwait, pcntl_exec, pcntl_getpriority, pcntl_setpriority, )
Yes, I have tried turning it off and on.
Offline
Re: Suggestions for site redesign workflow?
Sorry—I now have two threads going that have now started to substantially overlap. I will post here again when I have all this figured out for others to reference, meanwhile people are helping me get sorted here.
Yes, I have tried turning it off and on.
Offline