WordPress: A Month Later

Posted on

I have been using my new WordPress site for about a month now and can say that I am very satisfied with how everything is working. So much so that I would really like to convert all my sites to WordPress, if not for the fact that hand migration process from Drupal was a horrible pain.

The Good

WordPress is much faster than Drupal. Even without a caching plugin I am seeing my pages load up super quick. With the cache enabled—which, as an editor, I don’t actually see—the pages load almost instantaneously.

The Gutenberg editing interface takes a little getting used to, but works very well especially with the addition of the EditorsKit plugin. Adding images and media like YouTube embeds or audio files is completely hassle/code free. The EditorsKit plugin adds in the all important Insert Special Character function and a few other less common HTML tags like `abbr`.

Askimet provides spam-blocking that actually works. Drupal used to have a great anti-spam service in Mollum, but that was unceremoniously discontinued and the floodgates of spam opened up. In a related note, WordPress comment moderation is very simple and clean and, for the time being, I actually like seeing pingbacks

With the right plugins, creating custom content isn’t as bad as I originally thought. I had to pay for the unlimited install Advanced Custom Fields plugin, but, between this site and my work projects, it has been well worth the investment.

Finally, as I have stated before, updating the site is a complete breeze. This was my main reason for making the switch to WordPress. Click a button and the WordPress core is updated! The latest version allows me to tell the system to install updates automatically based on a per-plugin setting. Coming from Drupal, this is life changing.

The Bad

It’s not all hearts and rainbows here in WordPressland. There are still a few areas that could use some improvement. First and foremost is that lack of anything like Drupal Views. Views allows front-end users to display site content in any manner they can imagine without needing to touch a single line of code. Instead, I am stuck having to hand code queries into WordPress PHP template files. The query code is relatively easy to learn but every little tweak you want to make requires hours of combing through help forums and documentation for an answer. I still have no idea how to add filters to my various Reviews lists. In Views you just expose a filter and poof you have a dropdown or a field that visitors can use to narrow down a list.

I’m sure there is a plugin for this, but I would want to set up automated backups of the site. The WP All-in-One Migration plugin makes backing up easy, but I can figure out a way of making it run on a schedule.

While the front-end of the Media Library is excellent, WordPress is constantly creating unnecessary image copies of every image I upload, regardless of context. This means there’s a lot of unused junk in my uploads directory. It’s not horrible, but my Internet ’98 mentality wants me so save as much hard drive space as possible.

Most of my other complaints are about things that could be accomplished with a module in Drupal but require PHP coding to do in WordPress. Off the top of my head: highlighting a menu-trail based on a content type, customizing RSS output, custom menu blocks, etc.

The Ugly

Clint Howard

Pages of Fun, Now With WordPress

Posted on

It took about two weeks, but I think I have finally finished converting this site to WordPress. The bulk of that process was copying and pasting every post into the new system. I’m sure I probably goofed up a few posts along the way and there are bound to be many broken links. But I think was very thorough, going as far as copying every single comment and tag description.

My reason for moving away from Drupal was my general disappointment with Drupal 8. Nothing ever seemed to work exactly right. I’d make a few changes on the back-end and the site would unbeknownst to me be put in maintenance mode. Several key plugins withered on the vine and stopped working. The built in WYSIWYG editor was absolute garbage. And the worst part of it all was the horrifically user unfriendly update process. There are modules that require Composer to install and update and others that are always in pre-release dev states. No thanks. After a decade of loyal advocacy and usage, it was time to bid Drupal farewell.

I have built a couple WordPress sites for work this year and now feel much more capable in this system. The main disadvantage of WordPress is its lack of a Views plugin. If you want to get creative with outputting data, you need to dive in to .PHP files and WP_Query() loops. There’s a massive user base, so finding help on the Internet is fairly easy and, once you understand the basics, you get an idea of how to accomplish tasks.

As I type this, I am prepping to launch the site. Hopefully all will go well. Having never run a WordPress site with comments enabled I worry that I will find myself buried in comment spam.

The Last Straw

Posted on

This was all a big mistake. Upgrading to Drupal 8, that is. Nothing ever works right and Drupal hates casual users. I am now in the process of converting this site to WordPress by migrating every post by hand. There’s about 1700 posts so it’s going to be a while. There’s probably a plugin that can automagically do this, but the biggest con of WordPress is that good plugins aren’t free. Sigh.

Drupal 8 Migration

Posted on

I have resisted migrating this site to Drupal 8 for years. Every time I looked into it there was some killer feature that D8 couldn’t do. The times I attempted testing out the process it was always a complete disaster. Well, time is running out on Drupal 7. The old system is slated for end-of-life in 2020 and it’s now or never for the “upgrade.”

In this post I am going to recap my experience in migrating a fairly simple Drupal 7 site to Drupal 8. Hopefully, someone facing the same issues as me will come across this post and will find something helpful.

Long story short, the migration process sucks bad. If you don’t have a little experience with directly manipulating a database or troubleshooting software in general, don’t even attempt it.

I am not a command-line guy. This was going to be a drush-free migration.The whole push in Web development towards command-line apps for everything has been one of the worst things to happen to the Internet. It is virtually impossible for a beginner to just jump in and start creating content. Developers have made huge strides in interface usability and yet the tools to create those interfaces are nightmares of horrible UI design puzzle-boxes that exist mostly as job security for entrenched Web devs. Thank Shatner for the few out there like Prepros.io who are at least trying to make new technologies user friendly.

The first hurdle for me was finding a decent local development environment that could handle Drupal 8. My old standby, Xampp, has become garbage in recent versions with no 64-bit support and no interface improvements. I found Wampserver64 and it has turned out to be fantastic. Most importantly, it allows me to run two different local domains, which is required as the migration process works by sucking an old site into a new one rather than overwriting an exiting Drupal 7 install.

After setting up a clean Drupal 8 install with all the migration modules installed I set about creating a plan of attack. Oh, as an aside, whatever you do, do not install the Migration Example modules. It will fill your new site with a bunch of garbage content and fields that don’t get removed when you uninstall the module. My first order of business was to determine which I my D7 modules had D8 versions. A spreadsheet and lots of notes proved helpful. I tried to limit only the most integral modules and skip any ones that are just cosmetic. A lot of popular modules have been added into the core, but in many case they are watered down versions (Menu Block stands out as particularly bad).

Migration Begins

At that point I clicked all the buttons, watched and waited. It looked like most of the content came over but there are big problems with text-filters. If they don’t match with the new D8 filters, the content won’t render. That is really dumb. I had to log in too phpMyAdmin to manually change values. The next big problem was that my post were peppered with strange characters. This had to do with my Sql server not having correct character encoding. This article explains the fix you should do before migrating (I had to search and replace for hours because I failed to do this). Basically, add the following to mysql.ini:

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

Comments

The next big problem were comments. Only the most recent comments were rendering and I couldn’t see any difference between those and the bad ones. There appeared to be two tables for comments in the database: comment_field_data and comment__comment_body. Turns out if the langcode column doesn’t match between these two tables, the comments don’t render. More stupidity. Had to manually add “en” to the fields. Thankfully this site doesn’t have that many comments.

Page Caching and Dev Environment

The next step was setting up the local.settings.php to disable caching and render theming helper code. A couple YouTube videos explained this pretty well, although I still am having to flush the cache to see changes half the time.

Views, Oh God Views

Views is a fantastic module. It’s the reason we all use Drupal in the first place. So, why the holy hell aren’t views migrated by default?! So freaking annoying! I had to recreate about 15 custom views manually in order to get many of the site features back. Don’t delete that Drupal 7 site yet. You will definitely need it for reference.

Turning on the Modules

I then started installing and enabling various modules. Like I said earlier, things are different here in Drupal 8. Menu_Block is missing features, Menu_Position is just plain broken (a fix is in the works), Redirect is flaky and throws errors.

Everything to do with CKEditor is horrible. TinyMCE was orders of magnitude better. More robust, more advanced features, better looking, better integration with Drupal… sigh. I have a feeling I am going to be using code view a lot with CKEditor.

Pages of Fun Theme Redux

If there is one area where Drupal 8 is leaps and bounds better than D7 it’s the new Twig-based theming system. The syntax is far less cryptic. A simple {{ content.field_myfield }} renders a field. Perfect. My theme is far simpler than before, yet looks pretty good. Lots of fancy CSS layout tricks here that probably fail in Internet Explorer.

Launching the Site

So, after about two weeks of poking at it, I finally launched the site on December 19th. Within about 30 minutes I got my first spam comment. I do miss Mollum. I’ve tracked down a few anti-spam modules, but it’s going to be tough. I gave up on comments on the Nonagon.us site long ago and this may be a losing battle. Out of my cold dead hands Russian bot farms!

And here we are, a couple days in and things seem to me working okay. I’m sure I will need to upload fixes very soon. There are always sections of the site I miss. And when my first round of analytic come in I may need to start hunting down broken links. In the meantime, click around and enjoy. (And buy my art!)

Pages of Fun: Now with Drupal 8

Posted on

Well, I have finally made the jump to the newest version of Drupal. We are now running Drupal 8 and, man, was it a pain in the butt to migrate the old site. I will forever recommend WordPress over Drupal to anyone who doesn’t want to pull their hair out every time a new patch is released.

Still, there is a lot to like about the new system. I will soon post the gory details of my migration experience, but, in the meantime, let’s hope this works and that I am not swamped with comment spam.

Site Update 2017

Posted on

Today I did a revamp of the site’s theme. Mostly this was because Prepros no longer supports Compass in its Sass implementation. I had to go through all my sass code and remove any Compass references and write my own mixins based on them.

In the process I managed to reorganize much of my code and make some style tweaks across the site. I am going to go with slightly bigger fonts and am now using a grid system based on the Bootstrap grid instead of the confusing Zen grid. The biggest change to the site is that now the most recent post appears in full at the top of the homepage with a little “New” label in the corner. Future is now!

Major Overhaul of Planet Pimp Web Site

Posted on

Did you know I maintain an informational resource page dedicated to Planet Pimp Records (the greatest record label ever to exist)? Well, now you do, and today I uploaded a massive update to the site. This is mostly behind the scenes stuff that makes the site easier for me to update, but I have also added some new features including links to external video and audio. There have also been some fancy style tweaks so the site now scales to fit mobile devices.

There are still some quirky buts, but I am working on cleaning everything up and reviewing the site and links. A big thing on my to-do list is getting rid of Flash elements and replacing them with more mobile-friendly HTML5 widgets. As always, if you have anything to add to this vital historical record, please send your contributions to me.

My First Foray into SASS

Posted on

As I mentioned a few posts ago, this site has received a major theme overhaul. Aside from a couple form element styles, this change was mostly structural and behind-the-scenes. The new theme is my first foray into using the SASS CSS preprocessing language. Let me tell you, it was a revelation. SASS allows you to write CSS using a super-clean tabbed coding style and (finally) allows the use variables and expressions in styles. I mean, look at this OCD coder’s dreamscape:

Behold the beauty of SASS!

Gone are curly brackets and semi-colons. Now elements can be nicely nested within each other and there’s lots of neat shorthand to make code more portable.

Now, I am very late to this party and it turns out much of the SASS code you find on the net is written in a more standard CSS syntax (those sass files are saved as .SCSS rather than .SASS). I hope this cleaner, more modern syntax remains supported because I am completely sold on it.

For quite some time I have heard of SASS but have always been hesitant to dig into it because I always assumed that it was some server-side application that would require SSH and Linux and a bunch of crap I don’t care about. I have since realized that this is not the case. SASS files are compiled locally into a single, standard CSS file. Still, the first thing tutorials seem to tell you to do is to go install Ruby and dive into the command prompt. Yeech! Thankfully, smart people out there (“there” equals Nepal in this case) have developed a windows app that will compile and upload everything you need.

Prepros Screengrab

Prepros is a tiny little app that does it all and I highly recommend it if you are developing on Windows. It processes many other languages as well (including Jade and JavaScript) and, regarding SASS, also includes Compass.

Compass is a set of functions and extensions to SASS that makes cross-browser development super easy. A word of warning about Compass: unlike pure SASS it doesn’t work out-of-the-box and requires some research into creating a “config.rb” file. The Zen Drupal theme includes this file and I used that as a base, and I think I understand it now.

In any event, I’m syched about Web development for the first time in a long while and I am glad I made the leap. Also, support Prepros and buy a copy (or two).

Another Site Update

Posted on

Well, recently I’ve been trying to learn how to use SASS for styling Web pages and have kind of fallen in love with it. So here is my first go at it in the form of a new site template. Not much has changed visually, but, trust me, there have been a ton of changes behind the scenes. I will post more about this and the trials of retrofitting a Drupal theme for SASS sometime in the near future. In the meantime, look at the neat comments buttons I made!

Drupal, Pathologic and Corrupted URLs

Posted on

I’ve been having some technincal issues with this site lately. Strange links to content within the site have been appearing at random. I would insert a hyperlink to an archived post and then, days later, I would come back to see that the URL has been rewritten with a random sub-domain prefix. My domain would appear as www.wqw.robertgomez.org or similar.

I am not entirely sure what was going on but I think bots and the Drupal Pathologic module are to blame. Pathologic is a great module that will convert any internal site link into a standardized absolute URL. In my code I would create a link with an href of “node/1098” and Pathologic would convert that href to “http://www.robertgomez.org/blog/2014/03/17/drupal-my-list-essential-modules”. However, I suspect that when various bots crawled my site they used weird sub-domain prefixes in hopes of doing… I don’t know what?! Occasionally, one of these bots must have triggered a cron job, and my links were rewritten with the phony sub-domain. Seems feasible, right? If there is a real reason why this was happening, let me know in the comments.

The bad links could be fixed by opening a node and re-saving them. I used the Resave Nodes module to bulk save everything again. However, by the next morning the bad links had returned. The phony sub-domains were still being crawled. The next step was to use a rewrite rule in my .htaccess file that would force all subdomain traffic to a non “www” prefixed URL of the site. I then re-resaved everything, an so far thing are back to normal. Again, if you know what’s going on, shoot me a comment.