How to organise and synchronise production WordPress with local development environment

In the last year I’ve either deployed or inherited about 10 new WordPress installations and managing them became a mess that quickly ate too much of my time. It seems that quite a few of my friends have the same problem – so here’s a quick overview on how to approach it.

Everything I describe here can definitely work on OS X or Linux and probably on Windows as they’re all either PHP or Python based tools.

Keeping up with updates

Clients don’t update their plugins or WordPress itself and when they do they won’t read changes clearly enough to be able to judge if upgrade would break something. I use InfiniteWP for this. It’s a standalone PHP installation that connects to your WP’s via InfiniteWP Client plugin. It’s free, with some commercial add-ons. You can set it up to email you when there are new updates and support remote backups of your sites, which will be useful for later stages.

From security standpoint, it’s definitely not optional, but at the moment – not updating seems a greater risk.

infinitewp

Local development environment

For each client’s site, I would have a local copy running on my computer. Depending on your preferences you might be using something like MAMP of XAMPP that packages MySQL, PHP and Apache server together. One thing to watch out is that you’re running your local development under the same major version of PHP as it’s often source of bugs (as my local PHP would support newer syntax than the one on server).

For each site, I would have a local alias – http://sitename.local/ to ensure that I don’t accidentally change things on production.

For things I would develop, usually a theme and an extra plugin, I would store them in git to keep revision history and feature branches.

I have yet to find a good way to version plugins, so for now the tactic is to try to keep up with latest versions of plugin and use them as little as possible and only from developers that have release blogs and sane release tactics.

Synchronising production to local environment (manually)

Sometimes I don’t have shell access to server – in that case I would use either InfiniteWP to generate a database dump (from InifniteWP dashboard) or UpdraftPlus from within WordPress dashboard.

Locally, I would then use wp-cli to reset local database:
wp db reset
and import new database:
wp db import sitename_db.sql

wp-cli supports local path substitutions, but it’s usually not needed. What I would do is modify my local wp-config.php to have:

define('WP_HOME','http://sitename.local/');
define('WP_SITEURL','http://sitename.local/');

This allows me to use copy of production database, without WordPress redirecting my logins to production URL.

For contents of wp-content/uploads I usually don’t bother as I can easily fix things without seeing images in last few blog posts.

Synchronising production to local environment (automated)

For the sites where I have shell access and can install wp-cli on server, I have ansible scripts (more on that later) that run:
wp db dump
locally and then copy it to my dev environment where they import it using wp db reset and wp db import combination.

This means that I can sync production to my local environment in less than a minute, making it a no brainer to test and tweak things locally and not on production.

Applying changes to production

For themes and custom plugins for sites where I only have FTP access, I’m using git-ftp that allows me to push to FTP server using git ftp push. It keeps track of which revision is on server and updates only the difference. It does mean that you never change things on server directly, but have to go through committing to git first (which I consider a good thing).

For environments with shell access you can just ssh and then use git on the other side to pull in changes. It works, but it’s a couple of additional steps.

Lately, I’ve automating these tasks  with Ansible playbooks that allow me to have simple scripts like:

---
- hosts: server1
  sudo: no
  tasks:
    - name: update theme
      git: repo=git@server:themename.git dest=/home/username/sitename/wp-content/themes/themename

or to grab database dump

---
- hosts: server
  tasks:
    - name: wp db dump
      command: /home/username/.wp-cli/bin/wp db dump /home/username/tmp/sitename.sql chdir=/home/username/sitename
    - name: copy db to ~/dbdumps/
      local_action: command scp servername:tmp/sitename.sql /home/username/dbdumps/sitename.sql
      sudo: no

Which can then be easily extended or in a separate playbook file drop local database and import new copy. To run these playbooks you would just use ansible-playbook dbdump.yml and similar and it gives you a full report of what’s happening.

For bigger and more complex setups you would extend to support rollback and different revision models, but that’s beyond scope of my current WordPress projects.

Observations

Scripting these tasks always seemed as something not worth doing as they were just a couple shell commands or clicks away. But as number of projects grew it became annoying and much harder to remember specifics of each server setup, passwords, phpmyadmin location and similar.

With having things fully scripted, I can now get a request from client, sync whatever state of their WordPress is at the moment, automatically in just a minute, and see why theme broke on a specific article. It saves me crazy amount of time.

At the moment I’m trying to script anything that I see myself typing into shell more than 3 times and so far it was worth it every time as these scripts suddenly become reusable across different projects.

PSI Directive (Directive on the re-use of public sector information)

Today I had a chance to visit LAPSI 2.0 project conference (The European Thematic Network on Legal Aspects of Public Sector Information). Wikipedia has a good definition of the directive:

Directive 2003/98/EC on the re-use of public sector information, otherwise known as the PSI Directive[2][3] is an EU directive that encourages EU member states to make as much public sector information available for re-use as possible.

Speakers dealt mostly with EU level policy discussion either on specifics of the directive or issues in this area in member states specifically. What follows is a few of my notes that I hope will help me remember things from the event in 2 years time. I haven’t read the directive yet and since I’m not a lawyer my conclusions are probably wrong.

Getting the data

Historically speaking, Slovenia has had one of the most progressive Freedom of Information Act’s, coupled with very proactive Office of Information Commissioner. This meant that filing an FOIA request to PSB (public sector body) was often the most efficient way to get access to data that they gather or produce.

While this works fairly well for some parts, it still has its own limits. PSI solves that by further encouraging PSB’s to make data and information openly available. It further makes it harder to charge and limit access by requiring institutions to explain why access is limited, together with business and cost calculations.

I can’t find the source in published texts, but part of the discussion also revolved about this applying to Libraries and Cultural Works. This will present both a challenge for existing archives as well as opportunities for new ways to disseminate this content.

What’s the point?

Economy. There is a huge body of work and case studies that show that once you open up this data to greater public it provides exponential return on investment through new services and uses for it. The less limits, the more potential can be realised.

For me, it’s often hard to see use for a lot of the data that we find online or it would require distortional development investment to make it useful. On the other hand, most of this data and content was already paid using public money, so EU is betting that just opening everything will have huge economic impact.

When?

“Soon”. The way I understood is that we’ll see implementations into local EU member states sometime in 2015. But because of the direction and the work going in this area it should be possible to already use arguments and approaches within existing laws and individual agreements with institutions.

Additional Resources

 

 

Culture successfully raises funds from the EU

Today  Cultural Contact Point Slovenia based at SCCA-Ljubljana, Media Desk Slovenia, and Culture.si/Ljudmila Art and Science Laboratory released visualisations of last decade of successful fundraising data from EU programmes.

culture-eu-funding-interactive

kultura_klicaJ_TISK64x44_ENG_2013-10-15.indd

Process

This is first public release of such data in Slovenia and is result of 6 months of intensive work in data reconciliation, methodology and finally – visualisation.

I helped mostly in regards with data reconciliation and can speak about the tools we used. Basic tool was Google Spreadsheet and was used as a database that everyone could contribute to and it helped us sync the data together. It also allowed for basic pivot table based visualisations. It worked mostly ok and ability to write scripts for it also helped a lot. Finally the data was moved into Semantic media wiki and visualised using d3.js.

Lessons learned

  • Google Spreadsheets don’t scale. After you reach about 1000 rows with 30 columns, it becomes almost unusable slow.
  • This dataset is complex enough that it would benefit from automatic checks – automated reimporting into real database and basic reports – unique institution, basic pivot tables. This would help with encoding, whitespace issues that Spreadsheet doesn’t handle.
  • Google Spreadsheet got really good tools for pivot tables, but they’re a pain to manage if data ranges change. It can probably be further automated but I haven’t yet figured out how.

Notes on Open Data from OKCon 2013

It’s popular today to work in Open Data, Big Data or similar space. It feels just like the times of Web 2.0 mashups, but instead of simple Google Maps based tools we’re now creating powerful visualisations that often feel like an end by itself.

In a way, I expected OKCon, OpenKnowledge Foundation’s conference, to be about makers – people that build useful part of OpenData ecosystem and to provide in-depth case studies. Instead we’ve got a mix of representatives from government, large international NGOs, small NGOs and various developers and software providers. To me these worlds felt just too far apart.

Data Portals

Data portals are here and while we haven’t seen a large scale deployment from government in Slovenia, it’s likely that they we will have something in this regard in the next few years. Everyone else has already deployed their first version and more advanced (public) institutions are already on their second or third attempt. Just as with social media a few years ago, we’re now also seeing first case studies that show economical and political advantage of providing such sites.

Self hosted CKAN platform seems a popular tool for such efforts (or it just might be conference bias as it’s developed by OKFN).

Budgets and contracts

A lot of effort is expanded in area of representing budgets, tenders, company ownerships and similar. In this regard, Slovenia’s Supervizor looks like something that’s from far future compared to what other countries or projects achieved at the moment. We could contribute a lot back to the international community, if we can produce case studies on benefits (or lack of) of such system.

At the same time, building visualisations around local budgets is something that doesn’t feel productive anymore. I think we should just upload sanitised data to a portal like OpenSpending and focus our efforts on projects with more impact.

Maps

Just as with mashups, everyone loves geospatial representation. The more colours and points of interest, the better. The only problem is, that it’s often useless for people that actually need to use it. While not openly expressed during presentations, discussions during the break often revolved around how bloated and useless were these representations and that just having a good text/table based report would work so much better.

At some point, community will have to embrace modern product development methodology – stories, user testing, iterative development and similar.  Right now it feels like a lot of these tools are either too generic or sub-contracted and developed through water-fall model.

Having said that, I’ve seen great examples of how to do things right: landmatrix.org

Tools

While NGOs might be building things the old fashioned way, their developers certainly aren’t. Tools and platforms are openly licensed and published on GitHub and often tied into different continuous integration environments.

  •  https://github.com/ostap/comp – automatically exposes your local CSV, XML and similar files as JSON endpoint through standalone Go based server. Developed by mingle.io team.
  • Drake – for building workflows around data
  • Pandas – python based data analysis

 

Conclusion

Software development is already hard for teams of seasoned veterans that work on projects inside the tech industry. It’s almost impossibly hard for both large and small NGOs since there just isn’t enough talent available. Additionally, it seems that these organisations often don’t want to coordinate efforts (even basic sharing of data) with each other or even internally, making projects even less likely to succeed.

I think that  we’ll continue to see a lot of badly executed projects in this area until modern, tech-driven groups like OKFN and Sunlight Foundation manage to raise the bar.