bootstrapping wordpress

The other day I was thinking about how to easily setup a wordpress-site for development, staging as well as production and I found that there doesn’t seem to be an easy way „out-of-the-box“.

Why is that?

WordPress is famous for it’s „5 minute installer“ (which actually, after the 20th wordpress-site, takes you 2 minutes max). Upload the folder via FTP onto your server, open your webbrowser and add some basic informations and you’ve got a Blog up and running. Do some more customizations and you’ve got a decent website.

But it’s never been designed to take that site and move it to somewhere else to do some testing and then put everything back again to the live-site. Oh, but only put the configuration you changed back, not the actual data…

And that’s where it becomes tricky. The configuration resides in the same database as the content. And even though we just need the information what plugin shall be installed, we have to move the complete sourcecode of the plugin from A to B as there is no way otherwise. And to be honest, even moving the complete wordpress-core from A to B is somewhat overdone.

Dependency-Management

This can be circumvented by using DependencyManagement. the wordpress-core and all of the plugins and themes are dependencies of my website. And some examples already exist on the internet on how to setup a wordpress-site using composer. To enable that there’s even a proxy for all the plugins and themes in the wordpress-repository.

But it still misses some things.

Multiple identical setups

One thing was to allow easy installation on a development-system including a vagrant-setup while still enabling me to deploy everything easily on a different machine with a local database and webserver setup.

Version Control

Another thing is the possibility to store the setup in a VCS with a minimum amount of files. In my eyes it doesn’t make much sense to have the complete wordpress-core under version-control when a line like "wordpress" : "4.4.*" can be enough.

Automation

And it should also allow me to use the wordpress-repository to install plugins and themes as I’m used to. Update the dependencies via the webinterface or via an automated process.

An idea

Slowly an idea crept up in my mind.

And I’ve started creating it. A wordpress-bootstrap in combination with a WordPress-Composer bridge. It’s not finished yet, but I believe it’s a good way.

Now I can create a running wordpress-installation with some terminal-commands (as long as composer and vagrant are available) like this:

    composer create-project org_heigl/wordpress_bootstrap [my-wordpress-folder]
    # confirm the defaults with "Enter"
    cd [my-wordpress-folder]
    vagrant up

Now visit http://localhost:8080. You can log in using wpadmin and password (and you should change that!)

The setup already has a plugin installed that adds the plugins you activate in that installation to the composer.json-file and you can store the information of activated plugins and themes by adding that composer.json to your VCS and that’s it. No need to bloate your VCS with the complete plugin-code.

The whole thing is not yet finished! There’s a lot of stuff to do like handling Database-Transfers and stuff.

But it’s a start.

What do you think? Anything you think that should be included? Open an Issue or fork the project and create a Pull-Request.

Testing code with phpunit on travis-ci for PHP 5.5 and PHP7

I’ve recently added a pull-request to Zend\Ldap and realized that some of the tests were failing on PHP7. Reason was that Error-handling has changed in PHP7 and the used PHPUnit-version 4.x didn’t know how to handle that. So I needed a version of PHPUnit that understood that, which is PHPUnit 5.x. Sadly the minimum PHP-Version for that is PHP5.6 so now the tests in PHP5.5 where failing.

How to handle that as there’s no way to tell composer to install a certain package-version when a certain PHP-Version is found and a different package-version for another PHP-version (At least I’m not aware of one – if you know of one please let me know!)

So what to do? As the tests are executed on Travis-CI I decided to rewrite the compser.json-file when the tests are executed for PHP5.5.

And here’s how I did that:

For Zend\Ldap we have this snippet in our .travis.yml-file:

before_install:
  - if [[ ${TRAVIS_PHP_VERSION:0:3} == "5.5" ]]; then composer require --dev --no-update phpunit/phpunit ~4; fi

install:  
  - travis_retry composer install --no-interaction --ignore-platform-reqs

The interesting part is the before_install part which checks whether the first three characters of the PHP-Version are 5.5 and then requires PHPUnit version 4. The default in the composer.json is PHPUnit version 5 so as soon as Zend\Ldap drops support for PHP5.5 we don’t have to remember to change that file, it just phases out.

After that PHPUnit 4 is installed and the tests run smoothly in all currently supported PHP-Versions (Actually they currently don’t, but that’s a different story and has nothing to do with the different PHPUnit-versions 😉 )

Update
Thanks to Abdul Malik Ikhsan I’ve found out about another way to require a more recent version of PHPUnit.

Thanks!

A link to your Call for Papers

You have an upcoming conference for which you run a Call for Papers (CfP)? Then why not let everyone know by adding a link to where we can find more informations?

Something like the following could be parsed automatically and would allow easier finding of your CfP:

<link rel="cfp" href="[Link to your CfP-page]" data-closes="[ISO-Date of the end of the CfP]"/>

This could then look like this:

<link rel="cfp" href="https://example.com/cfp" data-closes="2015-12-24 12:00:00+02:00" />

That way websites displaying CfPs could fetch the information that there is a CfP from your main website and you would not need to provide extra informations about a CfP on a different place.

And while we’re at it: Your Event surely has a geographical location, so why not add that one via the following resource?

<link rel="venue" href="geo:[latitude],[longitude]"/>

It uses a geo-URI as specified in RFC5870 and can therefore also been read automatically to check for the venue of your event.

Alternatively you can include information about your event or the location using metadata as defined by schema.org. That way you can add even more informations about your event or the location than using a simple link. Thanks to Jurian Sluiman for reminding me!

Bulgaria PHP Conference

Currently I’m sitting at Sofia Airport digesting what happened the last few days.

A few months ago I submitted a talk to the CfP of a new PHP-Conference in Europe. I’ve had some contacts via Mail with Mihail as he’s the organizer of the PHP-Usergroup in Bulgaria and he also started this conference, so I though, why not apply.

I never dreamed that my talk would be selected, but it was. I was amazed. And then the organizing team invited us for a short sightseeing trip before the conference. Sure, why not?

And then the day of departure dawned. On my arrival in Sophia I was collected at the airport by Mihail himself and got a lift to the hotel. And the next morning a party of about 15 people set of to explore Bulgaria. It was an awesome time! Some of the people I already knew in person, others only via following them on twitter and there also where a bunch of people I didn’t know. But I got to know them. And it was like feeling at home. And the trip introduced me to a fascinating country which I surely will visit again in the near future.

And then there was the tutorial day. I skipped the tutorials and went for a walk around Sofia. Well, about an hours walk through „SouthPark“ before I came right to the city center. South Park is fascinating. YOu are in the middle of a 2.5 Million-People City and the only thing you hear are the Squirrels and the magpies. And sometimes you meet people. Absolutely amazing!

Finally the first day of the conference dawned. The organizing team did an absolutely marvelous job! Did I say they did a great job? You got that they did a fantastic job? It was a blast! They set the bar for conferences to a new level. And that was not me saying that, that were several people that have been around different conferences. Well organized, an eye to the little details an excellent venue and a really great bunch of people!

On the second day I gave my talk (on LDAP – if you’re interested in that, ping me) and even though most of the attendees were over listening to Adam Culp talking about refactoring on the other track there have been some people interested in the topic. And from the comments on joind.in I seem to not have made a complete fool of myself. Which is great as it has been the first time speaking at a conference for me! Thank you in believing in me Mihail!

There is space to optimize the talk and I will take that feedback serious (by the way, great and constructive feedback! Thank you!). I hope it wasn’t the last conference I am able talk.

And hanging around with all those people I until then only knew from twitter was amazing. I do definitely suffer from the „Fraud Police“ (as Amanda Palmer call it – also known as Impostor Syndrom) but it seems I actually am – and already was for some time – part of the large PHP-community. Therefore a big Thank You to all who welcomed me with open arms!

It really made me sad to leave so many new and old friends behind respectively see them spread into the world. But on the other hand that only means I can see them again on another Conference.

This Community is a PHPamily!

Moving php.ug to PHP7

The map of PHP-Usergroups on php.ug finally runs on PHP7!

But the transformation wasn’t as painless as I thought and would have expected. Therefore I want to share my experiences here.

First of all the provider that php.ug runs at already was compiling PHP7 when I thought about switching. That was cool and I can only recommend uberspace to anyone!

The first issue we encountered was the default path to the mysql-sock. By default it showed not to the actual socket-file so I had to alter the php.ini to point php to the right mysql-socket-file. That of course only applies for those that interact with mysql and do so on a socket and not via network. But that’s an issue for the hoster and they sorted it out fine after we found the issue together.

The second (and only other ) thing that caught me was the many new reserved words and libraries using those words (like String or Float) as class names. That had to cause havoc and I had to change some of the dependencies to use alpha-versions. Not really that good, but PHP7 isn’t finalized so I don’t see any way around it.

After those two issues where resolved (and some minor things I’ve created in my own dependencies) everything worked fine.

Thanks to everyone involved in creating PHP7 for an – after all – easy transition!