Chris Tankersley's Blog

LonestarPHP 2014 Wrapup


In an attempt to actually remember to do this after conferences, I'm sitting in DFW waiting for my airplane, and there is an hour to kill before we board. Since this was my first LonestarPHP conference I wanted to make sure that I gave at least some sort of retrospective for the weekend.

I had the pleasure of giving my "Your Inner Sysadmin" talk at LonestarPHP 2014. Overall the talk went well and was well received by the people I talked to (by the way, if you attended my talk and haven't done so yet, please rate it on!). My talks are never the highlight of a conference though, there are usually way better things to go to.

First off, let me say that the organizers did an awesome job organizing and setting up this conference. Each slot was filled with great and interesting talks. The venue was perfect for the number of attendees and was in what I thought a great location. For quality of learning experience, I definately recommend PHP developers attend this conference.

As with every conference it also gave me a chance to catch up with old friends, as well as meet with new people. I had a great conversation with someone after my talk about deploying puppet and some ways of doing it. A big part of any conference for me is the hallway track, and LonestarPHP 2014 was no exception. I had many interesting conversations with people and picked up a few ideas for myself. I also got to finally meet @snipeyhead in person!

My only complaints, which are things the conference itself had no control over, was that the internet went out during the hackathon making it impossible to do any work since we couldn't download anything, and I didn't win the big giant red elephpant. I did another small red Chili, so that's at least something.

Overall my first experience at LonestarPHP was a great one. I will definitely look forward to attending next year.

Migrating from Octopress to Sculpin


A long time ago, I decided to ditch Wordpress. For what I was doing with my blog, which was mostly just having it sit there and not do much, Wordpress was just to heavy. I mean, sure, I had caching and all that turned on, but I constantly had to make sure it was kept up to date. I had to let it eat CPU cycles on my server while it rebuilt the cache and served pages. It was easy to post articles, but other than that there wasn't a benefit.

I decided that since I didn't do much, my site shouldn't either. Jekyll was the new hot kid on the block and the idea of a static site intrigued. me. It was 1995ish but since I didn't have to build the site it sounded like a good idea. I ended up going with Octopress which was built using Jekyll and some extra plugins to make blogging easier. I even found a script to take my Wordpress export and conver it over. Life was good.

Not great, but good. One thing that bugged me was that since Octopress was Ruby I had to start maintaining a ruby install wherever I wanted to build my site from. In theory this should work from anywhere but I never got it to work on Windows. I'm no stranger to running things from the command line so I just always blogged on my server. There were times where I did not blog because of it though.

PHP, as always, caught up with the trends and now there are a few different static site generators. Part of moving had to be making it easy to move. Wordpress to Octopress was decently easy as I had a script that helped me. Moving from Octopress had to be just as easy. I had come across Sculpin a few times before and decided that it looked easy enough.

A quick exchange with a few people like Chris Hartjes and Beau Simensen let me know that it might not be that easy. My blog wasn't complicated as it was just my blog posts and a few different static pages, so I went ahead with the conversion. And it worked!

Converting the Posts

Both Sculpin and Octopress use Markdown as a markup language so this was actually fairly easy. I copied everything from source/_posts/ in Octopress to source/_posts in Sculpin, and ran the following script:

# This script will need some small modifications if you run this on Linux, as
# the sed command on OSX is not the same as the GNU sed command


echo "Changing file extensions..."
cd source/_posts
for old in *.markdown;
    mv $old `basename $old .markdown`.md;

echo "Switching code block syntax..."
cd source/_posts
for old in *.md;
    sed -i '' -e "s/\`\`\`/~~~/g" $old

echo "\n\nHere are some files that will need their syntax fixed:"
echo '------------------------------------------------------'
egrep -nHr "~~~ (\w+)" source/_posts

This renamed the files from *.markdown to *.md, which Sculpin recommended, and then I converted the triple backtick to a triple tilde for preformatted text. I had some files that had a heading as well, so it told me which files had preformatted text with headers. I could have probably figured out a regex to fix it automatically, but meh, I'm lazy and two minutes of text editing was much more favorable than hours figuring out a regex pattern.

Implementing Disqus Comments

I couldn't find a way to do this via the config, so I just added the following blocks of code:

// Inside source/_views/default.html
<script type="text/javascript">
var disqus_shortname = 'mydisqusshortname';
var disqus_script = 'count.js';

(function () {
    var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
    dsq.src = 'http://' + disqus_shortname + '' + disqus_script;
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
// Inside source/_views/post.html
<script type="text/javascript">
var disqus_shortname = 'mydisqusshortname';
var disqus_script = 'embed.js';

(function () {
    var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
    dsq.src = 'http://' + disqus_shortname + '' + disqus_script;
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);

To get the comment count, Disqus looks for a URL that ends in #disqus_thread, so I just made a URL that points to the block post with that appended.

On the post page, I added the following to get the comment box to appear:

    <div id="disqus_thread" aria-live="polite">
        <noscript>Please enable JavaScript to view the <a href="">comments powered by Disqus.</a></noscript>

Disqus picked up the URLs once I was on the live site and all the comments flowed back into place.

Converting the Static Pages

This one was fairly easy since it was mostly just copy/pasting. In Octopress, static pages were designated by a folder inside source/, with an index.markdown file inside. It turned this into a pretty URL path. In Sculpin, this is done by having a file named what you want the path to be (for example, for the About page). I copied them over with new names and Sculpin built the static pages.

I then added the paths to the default.html layout so that it would appear in the navigation. Boom, done.

I did have some of my slides in a talks/ folder. I couldn't get Sculpin to directly see this, so I just manually moved it into place on the production server. Again, there might be a better way for this but it took all of 30 seconds to SFTP up to the box.


I haven't done anything with this yet, but I will be making a custom theme for Sculpin. My site is ugly but then again, I haven't tried to fix it at all and bare Bootstrap is ugly by itself. I'll fix that up over the next few weeks. Everything is in Twig so I'm familiar with how the template layer works.

Overall, Very Impressed

I tweeted Beau to let him know that everything went pretty smoothly, and I'll be talking to him at LonestarPHP as there are a few things I miss from Octopress. Since Sculpin is an open source project I plan on trying to make blogging with it a bit easier, but right now it's not really any worse than Octopress!

Licensing Is Hard, Let's Go Shopping


Licensing seems to be a popular topic in the PHP world lately. I think that's a good thing, since many PHP developers are open source developers, and open source is what helps not only PHP the language grow, but also the PHP ecosystem in general.

A big blowup has recently been happening in the Joomla space. I'm not a member of the Joomla community, nor do I really care to be, but that's not really the point. I've tried to piece together most of it, but the Joomla Framework is considering a change from the GPL (GNU Public License to the LGPL (Lesser GNU Public License). This has caused a major stir in the community, and many people are against it.

The big question is, why? Both licenses are approved Open Source Licenses, so it's not like the Joomla Framework is going to all of a sudden be closed sourced and walled off from the world. No one is going to lock up the code, it will stay Open Source (or Free).

The problem is what is Free at a philosophical level. Whose freedom are we talking about? How do we define freedom of software, and to what lengths to do go to define that freedom? As humans we're good at siloing things into specific requirements and in the software development world we've done that.

A Crash Course

When we talk about open source software, we're actually talking about two different camps and ideologies. One is "Copyleft," which boils down to the idea that software has inherent rights and wants to be free, much like you reading this want to be free. It doesn't want to be caged up, it wants to share itself with the world. Anything that you make with it shares those same rights, so that software must be free and open source as well. That sounds kind of fanciful, but that's the idea. This idea has spawned the GPL, one of the most popular Open Source licenses ever.

The other camp is "Permissive." The idea behind this camp is that code should be shared for the betterment of the community, but that the developer is the one that ultimately controls how the code is used. For example, if you purchase a car, Chevy can't tell you what to do with it. Likewise, a developer can release a blob of code into the wild but can't stop another developer from locking their version up (the original released version is still freely available). Licenses like BSD and MIT are examples of Permissive licensing.

To quickly distill this, "Copyleft" favors software over the developer, and "Permissive" favors the developer over the software.

Why does this matter?

Let's get back to the matter of Joomla Framework. Right now Joomla, and the Joomla Framework, are licensed under the GPL. The GPL is a "Copyleft" licensing scheme, which favors the idea that no one has the right to lock up the code into a proprietary system. If I make a CMS based on the Joomla Framework and distribute it, I'm not allowed to stop anyone from asking for the source code and modifying it. This helps encourage people to share back improvements.

I'm also stopping someone from asking the source code, modifying it (let's say changing the name to SuperAwesomeFramework) and then no longer offering the new source code. The GPL is a viral licensing so anything that is built with the Joomla Framework will also be GPL. From the perspective of the software this is great since it will continue to grow without fear that enhancements are locked up.

One of the issues with the GPL that many people (like myself) have is that anything that touches the GPL'd software must also be GPL. This is where the viral part comes in. Let's say I'm building an accounting software and want to use an XML library that is distributed as GPL. The GPL on the XML library says that anything I build with it must also be GPL, so the accounting software I build must also be GPL. The GPL spread from the XML library to my software, so my software must now be GPL. From a copyleft standpoint that is good, because now I can offer my software to the world and it will be free.

What some people want to do is switch to the LGPL, which removes that linking requirement. In the case of my accounting software, if I use an XML library that is LGPL I don't have to license my entire software as LGPL (though if I modify the XML library I will still be required to open source those changes).

By using the LGPL I'm not adding to the open source ecosystem, which is a major sticking point for many developers. I'm still required to offer the source and any modifications to the XML library, but not the accounting software. I've locked up the accounting software and taken away it's freedom. That's a big deal to some people, which is why many developers are against the Joomla Framework being LGPL.

Remember, the whole idea behind Copyleft licensing is that software wants to be free, so anything that takes away freedom from the software is a bad thing.

Why change the license?

This gets back to whom you are servicing - the software or the developer? The more permissive and less copyleft something is, the more it favors the developer. In the case of the Joomla Framework, switching to the LGPL makes sense because many developers and companies will not use GPL software to build their products, since they do not want their entire product/service/whatever to be be GPL'd, and therefore open source.

If the Joomla Framework switches to LGPL, the idea is that more people will use the framework without it affecting the contributions to the framework at large. Remember, modifications to the framework itself still need to be open sourced, so if I build something on the Joomla Framework and fix a bug with it's DB layer I still need to make that change available.

By staying GPL, the Joomla Framework limits who can use it, but it also forces code built on it to be open source and contribute to the community. That's not necessarily a bad thing, but if the Joomla Framework wants to service the developer above the code, then LGPL makes more sense. If the GPL makes someone not want to use the framework, why use the GPL?

Do What's Best for the Community

I don't have an answer for this debate. Well, I do, and it would be to switch to BSD licensing but that's because I'm not a fan of the viral nature of copyleft licensing, but that's not the point of his article. I think ultimately the Joomla Framework community first needs to answer who they are trying to serve - developers at large using their software or making sure that the rights of their software are upheld. That should be the first question that's answered, as that answer will dictate what license to use.

Determining what license you want to use is a personal choice, and a hard one.