Chris Tankersley's Blog

Drupal's Code Review is Incredibly Frustrating


Despite me doing a ton of Drupal development, I don't actually have much contributed to the Drupal module ecosystem. That seems like an oversight on my part, especially since I'm doing more and more talking about Drupal, and at php[world] will even be doing a tutorial class on modern Drupal development. I had a project that we worked on at The Brick Factory that was an excellent candidate for releasing to the masses. It is small module that allows site themers to customize their sharing icons. Nothing major, and a good first short.

I got the approval to release the code, and spent some time cleaning it up a bit to make it a bit more fit for release. I removed name spaces, made sure everything was documented, removed dead code, etc. A good spit shine. As I read more into the process for releasing code I ran into the need to get access to publish code. No big deal, since it was well documented. I pushed the code to my sandbox, wrote my project application ticket, and went from there.

Drupal has every developer go through a Code Review process to make sure they understand the Drupal coding style, how things work, and what is expected of them. The idea is to point developers in the right direction and release better code as a result. Once a developer has been approved they can release more projects without this, as they have gone through the process. The review process makes sure that modules don't get released using PHP 4 coding styles or have obvious security issues. It is a noble idea and purpose, especially in the PHP ecosystem where many people throw their projects up on Github without anyone looking at it.

That was two months ago. I'm still not approved, and have no idea when, or if, I ever will be.

The Journey

Right away I got a message from the PA robot, saying that my code had issues. Drupal has a specific code style and a documented Code Sniffer package that everything needs to conform to. That's fine, so I went through and cleaned it up. Most of it was indentation issues, or unclear requirements for the docblock. Nothing that was offputting so it was quickly fixed. I even reviewed a few modules to get myself put into the high priority list.

I eventually got a human to review my code, and he had some good things that I did indeed overlooked. I quickly patched those as they really were stuff I just plain missed. Again, not a big deal, as that's the entire point of the process - making sure that code is released to the wild that is in the best possible shape. A second person reviewed my code and had a few more suggestions which I implemented. The third review was even shorter.

I then got knocked down out of the high priority list because of an issue with the GPL header I had in my files. Drupal enforces a GPL 2 license on all the code, and I had accidently added a GPL 3 header to all of my files. Despite the GPL page saying to put a header on all the files, I removed the GPL 3 header instead of modifying it to say GPL 2. I'm fine with that change since the build process on will take care of adding the license file. I was just trying to follow what the GPL site said to do. That review also had the most in-depth recommendations, which were implemented.

That was a month ago.


Since then nothing has come from the project. One review mentioned some missing links in my .info file, and missing permissions, which had actually been taken care of a while ago. I responded to the reviewer, and got nothing back. A second person reviewed the code, and gave me the same code sniffer issues that had been fixed over a month ago. I ran PA Review myself and got a different set, which corresponded to the code that was sitting in the repo. So I have no idea, but both of those knocked my back into "Needs Work" status each time.

And that's where it is sitting. Frankly, the entire situation has soured me on releasing code on Some of the requirements I only came across because someone linked to them. The tools are dependent upon what versions reviewers have installed, so one person can submit a code sniffer report that gives one result, and another reviewer can get a different result. These results can be different than the automated tools that run. I'd run the tools locally and get different results as well.

Since I'm at the mercy of the community I can do little other than sit and wait for someone to review my module. Even when I was in the High Priority list I was waiting weeks for someone to just look at the code. The entire process seems to penalize code that doesn't sound interesting, since I saw other projects pop up, get immediately reviewed, have back-and-forths, and get launched while mine sits and stagnates. The last review I had mentioned issues during the installation completely unrelated to my module, but because of that I get penalized and knocked down to "Needs Work" status again. Five minutes of work later I've resolved some issues (completely unrelated to the ones that knocked me down, because they haven't existed for a month), and I'm back in the waiting game.

I'm Not Sure I Care Anymore

It sounds like I'm whining, and partially I am. I'm frustrated with the process, especially since there isn't anything I can do. Sure, I can review some more modules myself and get back into the High Priority list, but why? The first time did nothing for me as I still waiting weeks between reviews, which the High Priority list was supposed to help with. So here I am, two months into a project that just sits there, waiting for someone to look at, like some puppy that has grown just too large for people to want to buy.

And lest one think this is an outlier, this wasn't the first time I had tried to release code on A few years ago I wrote a stripped down module for interfacing with Facebook because the "fb" module on was incredibly bloated. has many projects that duplicate functionality, you just have to justify why yours is different. I didn't even get to the point of committing my code because my Facebook project was immediately shot down by someone. Since I couldn't log into that account anymore (I must have used an e-mail that I no longer have access to), I started fresh. And here I am again, stuck without the power to do anything meaningful but sit here.

I went into this process looking forward to finally releasing something on and see how well the process works. Now that I'm in it, I'm not even sure I care anymore. Yes, this is a one time thing and once I'm approved I can release other projects without this hassle but the damage has already been done. This process has taken over two months and I have nothing to show for it.

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!