DEV Community: Peter Tasker

An introduction to Gatsby for WordPress Developers

Peter Tasker — Thu, 18 Jun 2020 00:00:00 +0000

For a long time, my personal website was a built on WordPress. I’ve worked with WordPress a bunch in my career and felt like it was a good balance of functionality and flexibility. But lately, I’ve thought about ditching it all and switching over to a static site. I personally love writing in Markdown, and the new WordPress editor relegated Markdown writing to a second class citizen. So I figured now was the time to switch over to something else entirely different, something like Gatsby.

Gatsby is a static site generator, if you’re not familiar, that allows you write your templates in React and uses NodeJS under the hood to compile your site. I enjoyed building my new site: creating templates, configuring the GraphQL queries and getting back into traditional web development.

At work, I’ve written about using WordPress as data source on the SpinupWP blog, and I wanted to know what it would be like to switch from WordPress to a Markdown based blog.

What follows are the steps I followed to migrate my site from a self-hosted WordPress site to a Gatsby site hosted on Netlify. It may not be the exact process that you will need to follow to migrate your own WordPress site, but I think it covers the most common steps.

Extracting Content From WordPress

The first step to getting content out of WordPress was grabbing an XML export. This can be done using the WordPress core exporter. You can run create the export by logging into your wp-admin and going to Tools > Export.

Once you have an export XML file you’ll need a markdown converter. There are few available online, I used the wordpress-export-to-markdown script, but there’s plugins and scripts like ExitWP available online that do the same thing.

It’s pretty straightforward to convert the XML export into Markdown. With the wordpress-export-to-markdown script it’s really just this one command:

npx wordpress-export-to-markdown --save-attached-images true

After the script ran, I had a folder with a bunch of new markdown files and a folder with my media uploads. I just dumped the markdown files into a ‘blog’ folder and all media into a ‘blog-post-images’ folder. You could group each post in a folder with it’s media, but I opted for this set up for the old posts to keep them separate.

The data in the Markdown files was a little mangled, but not too bad. The ‘frontmatter’ (the metadata for each post) was chucked in the header of the Markdown file, so a lot of the work formatting the files was removing this junk.

For the most part, the posts came across ok. There was a bit of formatting and styling needed in terms of <code> and <pre> tags, as well as fixing up image paths. Other than than, most formatting was in pretty good shape!

via GIPHY

Getting Gatsby up and running

Alright, so now we’ve got out WordPress content, now what? Welp, the first thing we have to do is get Gatsby up and running. Fortunately this is pretty easy and the Gatsby docs are very helpful.

// Install the gatsby cli tool globally
npm install -g gatsby-cli

// Create a new Gatsby site in a 'gatsby-starter-blog' folder
gatsby new gatsby-starter-blog https://github.com/gatsbyjs/gatsby-starter-blog

I opted to use the Gatsby Starter Blog starter as it already has a lot of the Markdown plugins included, as well as some pretty decent defaults and app structure.

In Gatsby land, starters as pre-built boilerplates, and it’s really awesome how far they can get you right out of the box. There are a bunch of options for pretty much any design style you could ask for. Think of starters as a WordPress theme and set of plugins.

Gatsby does have the concept of themes as well, but for most smaller sites a starter is just fine. The only thing you lose by using a starter over a theme is that if the starter is updated down the road you’ll have no way to pull in any upstream changes.

For me, that’s a solid “meh”.

Once you’ve run gatsby new, you’ll have a pretty nice Gatsby app ready to go. If you cd into ‘gatsby-starter-blog’ and run gatsby develop you should see your new blog running at http://localhost:8000. And at this point, if you’ve moved your markdown files into the ‘content/blog’ folder, they should have been created as Gatsby posts.

How’d that happen?

How Gatsby Works

If you’re coming from WordPress land, the concept of a ‘compiled’ website might seem a little strange. That’s what Gatsby does, it compiles a dynamic site (React components and a content source) into a (mostly) static website. Because of this compilation step, most of the magic happens during the build step.

Before we get into the build side of things, it’s helpful to see how the content and structure of the site is created.

The first thing to learn about is the gatsby-config.js file. This is where we load in our Gatsby plugins and configuration. For our Markdown files, we use the gatsby-source-filesystem plugin to load them in, specifying the path in the configuration:

{
    resolve: `gatsby-source-filesystem`,
    options: {
    path: `${__dirname}/content/assets`,
    name: `assets`,
    },
},

The Gatsby starter will have this file mostly populated out of the gate, but it’s good to know it’s purpose and location.

Gatsby Node APIs

The next thing to learn about are the Gatsby Node APIs. These are managed by the gatsby-node.js file. Here, we define how pages get created and how they interface with the GraphQL layer.

The main function to create pages is the called, unironically, createPages(). In here we define the query to get our posts, and any additional data we want to add to our posts/pages. We then call the createPage() function for each ‘post’ we want created.

It’s important to note that gatsby-node.js file is essentially just a node script with access to the Gatsby APIs. This is helpful information if you’re debugging during the build process, you can debug the Gatsby build site just as you would any other Node script.

In this file, we import a template to use when the createPage() function is called a bit later.

const blogPost = path.resolve(`./src/templates/blog-post.js`)

Then, we have our GraphQL query which is saved in the postsResult variable. We use the graphql function which is part of the Gatsby package;

const postsResult = await graphql(
`
    {
        allMarkdownRemark(
            sort: { fields: [frontmatter___date], order: DESC }
            limit: 1000
        ) {
        edges {
            node {
            fields {
                slug
            }
            frontmatter {
                title
                type
            }
            }
        }
        }
    }
`
)

allMarkdownRemark is a function that’s part of the gatsby-transformer-remark plugin and is Gatsby’s port of the Remark markdown parser. In the gatsby-config.js file we’ve already configured this plugin so it knows where to find our Markdown files.

Gatsby also has a great overview explaining what GraphQL is and why it’s so cool.

All we need to know about the above query is that it gets all of our content from our markdown files, sorted by date and limited to 1000.

The neat thing about GraphQL is that it returns data in the same format as we request it. So we can access data in the postsResult variable like we would any other JS object.

So in our query we’re asking for:

{
    allMarkdownRemark(
        sort: { fields: [frontmatter___date], order: DESC }
        limit: 1000
    ) {
        edges {
            ...
        }
}

And in the postsResult var:

// Create blog posts pages.
const posts = postsResult.data.allMarkdownRemark.edges

You can think of GraphQL queries as similar to WordPress custom WP_Query() calls. We specify what we want, and it returns the data.

<?php
   $args = array(
      'post_status' => 'future',
      'meta_query' => array(
         array(
            'key' => '_thumbnail_id',
            'value' => ’,
            'compare' => '!='
         )
      )
   );
   $slider_posts = new WP_Query($args);
?>

<?php if($slider_posts->have_posts()) : ?>

<div class='slider'>
   <?php while($slider_posts->have_posts()) : $slider_posts->the_post() ?>
      <div class='slide'>
         <?php the_post_thumbnail() ?>
      </div>
   <?php endwhile ?>
</div>

<?php endif ?>
?>

Example of getting posts for a ‘slider’

Just like in WordPress, the last thing to do is loop over all the posts and apply our HTML:

  const posts = postsResult.data.allMarkdownRemark.edges

  posts.forEach((post, index) => {
    let previous, next

    const { node } = post

    // Figure out links for previous and next post
    if (node.frontmatter.type === "post") {
      previous = index === posts.length - 1 ? null : posts[index + 1].node
    }

    if (node.frontmatter.type === "post") {
      next = index === 0 ? null : posts[index - 1].node
    }

    //Actually create the page
    createPage({
      path: post.node.fields.slug, //Post 'slug'
      component: blogPost, // Template to render
      context: { //Context date for this post/page
        slug: post.node.fields.slug,
        previous,
        next,
      },
    })
  })

In a WordPress theme, you would probably just output some HTML inside the loop. In Gatsby, since this is during the build step, you need to explicitly call the createPage() function to create the page on our site.

The createPage() function uses our React component (blogPost.js) as the template. Just like WordPress uses individual theme component files to output parts of our theme, the createPage() function grabs our template and injects the data needed to render out everything.

The blogPost.js template isn’t super complex, it’s just a React component with dynamic data passed in.

I’ll defer to the Gatsby docs for explaining how templates work.

Things also differ from the traditional WordPress development workflow when it comes to images.

Image Handling

We’ve seen so far that Gatsby uses GraphQL to query content for our posts, but how are images handled? Images in Gatsby require the gatsby-image plugin.

gatsby-image is a pretty sweet little package. It will take your large images, resize them, strip metadata, lazy load them and use a ‘SVG blurred placeholder’ all in one.

Yeah.

Per the docs, it’s basically just installing a couple npm packages and adding some base configuration to your gatsby-config.js file.

Then, you have a few options for how to use the image in your template and your posts.

For markdown, you just use the markdown syntax for images, and use a relative path to the image:

![](../blog-post-images/screen-shot.png)

In a component, you can query for an image with a GraphQL like so:

query BioQuery {
    avatar: file(absolutePath: { regex: "/profile-pic.png/" }) {
        childImageSharp {
            fixed(width: 50, height: 50) {
                ...GatsbyImageSharpFixed
            }
        }
    }
`)

Then elsewhere, use the gatsby-image Image component to render it.

<Image
    fixed={data.avatar.childImageSharp.fixed}
    alt={author.name}
    imgStyle={{
        borderRadius: `50%`,
    }}
/>

It seems a lot more complicated than what you would need to do in a WordPress theme, but I find it only slightly more verbose than this:

<img src="<?php echo esc_url( get_theme_mod( 'banner-section-image', '' ) ); ?>" alt="Alt text" >

I’d argue that the biggest improvement over WordPress is Gatsby’s image handling. Having the correct sizes created automatically and having them lazy-loaded is a game changer. It requires next to no effort and everything is super performant out of the box.

via GIPHY

Ok, so let’s review:

✅ We’ve exported our WordPress site content to Markdown
✅ We’ve exported our media
✅ We’ve created a new Gatsby site that loads our markdown files
✅ We’re loading up our images in posts and our templates

All that’s left is deployment and hosting!

Deployment and Hosting

One of the sticking points with WordPress is finding a decent host. Most managed hosts can get expensive fairly quickly, and shared hosting is a no-go if you want decent performance. You can self host on a virtual server as I did for years, but you have to keep the underlying OS up to date and patch things, modify the firewall etc. etc. etc. (plug: SpinupWP from Delicious Brains mitigates all of these issues 🤩).

Does hosting Gatsby have the same issues? In a word, no.

Because Gatsby compiles down to essentially a static HTML web site, you can host almost anywhere. There’s no dynamic content, so it’s pretty quick right out of the box. Even more, Netlify offers free hosting of Gatsby sites, including Let’s Encrypt SSL certificates and custom domains. That’s where I’m hosting this site and it’s the bee’s knees.

I’ve also set up git deployments, so pushing to master deploys the site.

Where WordPress is a better option

Ok, so all this sounds pretty great doesn’t it? Well it is, and Gatsby is awesome, but it’s not without issues.

Gatsby isn’t a CMS, so none of the CMS nice things are available. Want to handle a contact form? That’s an external service. Want comments on your blog post? That’s an external service. Want to sell stuff or have user sessions? That’s an external…

You get the point.

It’s a static site, so it’s a static site. There’s no dynamic aspect to the site, everything is built at compile time. That’s probably the biggest drawback of Gatsby, there’s no ‘dynamic’ functionality on your site by default.

Of course, there are workarounds and services that will get you this interactivity, but it involves weaving together third party services, like Disqus for comments or Shopify for ecommerce.

I’ve got Disqus comments enabled (leave a comment!) and use Netlify’s form handling for my contact form. But if you’ve got a highly dynamic site with dynamic content, Gatsby is probably a no-go.

WordPress on the other hand is dynamic by default, so you can get pretty far with plugins and custom code.

In the end

For my own purposes, as a developer, Gatsby is a great solution. I can write in Markdown, deploy my site with git push origin main and write React code for my templates.

One more time.

via GIPHY

What do you think about Gatsby over WordPress?

You can check out the source for this site on Github

Common JS libraries and tools

Peter Tasker — Thu, 11 Apr 2019 17:48:45 +0000

Something I wish was more common in the JavaScript ecosystem - a list of standard libraries and tools that are 'up to date' and that everyone uses.

It can be difficult to digest what is 'standard' without doing a bunch of reading.

For example, using the immer (or another immutable library) with Redux is basically a necessity with complex state.

What are your 'standard' JS libraries and/or tools?

What are your CLI go to commands and aliases?

Peter Tasker — Fri, 14 Dec 2018 12:57:16 +0000

I realized that I have a bunch of CLI go to commands and aliases that speed up my productivity and was wondering what others use.

A few of my favs:

history | grep 'something' - for finding a command I ran in the past
zz - opens up ~/.zshrc for editing
wpd - uses my local PHP version to run WP CLI so I can use XDEBUG on the CLI

What are your aliases and CLI goto productivity commands?

Devs using font ligatures, what's the selling point?

Peter Tasker — Wed, 18 Jul 2018 12:35:27 +0000

I've just enabled them in my editor and I don't really get it. Is it because it makes code shorter and easier to read?

People using Go in production, what are you using it for?

Peter Tasker — Thu, 19 Apr 2018 18:10:21 +0000

I've been looking at learning Go and bit more and seeing what it's all about v.s. PHP, Python, Ruby etc. I know there are a bunch of people using Go, but I'm wondering where it's fitting in everyone's workflow. Are you building full fledged webapps with it? Or are you building microservices for small parts of your API? Lambda functions?

Nginx, Let’s Encrypt and taking my own server down 😢

Peter Tasker — Tue, 10 Apr 2018 00:49:15 +0000

Photo by Simon Fitall on Unsplash

If you pay attention to Google and it’s indexing rules, you’ve probably heard that you need an SSL certificate on your site. I’ve known this for a while and my personal site at petetasker.com wasn’t a high priority situation.

Welp, I was bored one night and decided it was about time to get one of those fancy-pants free Let’s Encrypt certs installed on my old Linode server.

There are tons of resources on the internet that outline how to get an SSL certificate installed on your site, so I’m not going to go over that portion. What I will go over is how blindly following them can take down your server…

You see, most tutorials want you to use Certbot to install your certificate and configure Nginx.

certbot --nginx -d petetasker.com

Seems harmless enough, no? That little --nginx flag, if you didn’t read the fine print, will modify your virtual host config. Yeah. There’s an option when setting up the certificate to redirect all HTTP traffic to HTTPS, and obviously I said ‘sure’.

And queue the redirect loop. Site monitor email deluge, Twitter ‘the site is DOWN’ DM’s…

Everything is going swimmingly!

I managed to solve this issue by removing the following block in the /etc/nginx/sites-available/petetasker.com virtual host declaration:

if ($host = petetasker.com) {
    return 301 https://$host$request_uri;
} # managed by Certbot

And adding a simpler redirect block, just to be reallllly clear, at the top of the file:

server{
        listen 80;
        server_name petetasker.com;
        return 301 https://$server_name$request_uri;
}

So what’s the lesson here kids? The lesson is that if you’re using a tool that will ‘automagically’ do something for you, and it sounds too good to be true, it probably is.

If you’re wondering what the final virtual host block looks like:

server{
        listen 80;
        server_name petetasker.com;
        return 301 https://$server_name$request_uri;
}
server {

        listen 80 default_server;
        #listen [::]:80 default_server ipv6only=on;
        server_name petetasker.com www.petetasker.com;

        server_name petetasker.com www.petetasker.com;
        root /usr/share/nginx/sites/petetasker.com;
        index index.php index.html;

        location / {
                try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/petetasker.com-0001/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/petetasker.com-0001/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

The post Nginx, Let’s Encrypt and taking my own server down 😢 appeared first on 🔥 Database Critical 🔥.

People that don't use Github, what do you use and why?

Peter Tasker — Thu, 29 Mar 2018 17:21:19 +0000

As a developer I've been using Git and Github for the past few years. To me, it's such a breath of fresh air compared to SVN and gasp CVS. I also find that Github has the most mature integrations and tooling compared to Gitlab and Bitbucket. I'm interested to hear what others use, and more importantly, why.

What's the dumbest bug you caused yourself

Peter Tasker — Fri, 15 Dec 2017 19:24:41 +0000

I was thinking about this recently, what's the dumbest bug you've caused yourself?

I'll go first.

More often then not my code won't work because of a rampant letter 's' somewhere in the code. 'Undefined variable s' etc.

The reason? Hitting CMD-s to save a file and letting off CMD too early...

:face-palm:

Using async await with jQuery’s $.ajax

Peter Tasker — Thu, 14 Dec 2017 17:26:01 +0000

Photo by Denys Nevozhai on Unsplash

If you’re like me, you’re probably stuck using jQuery more often than not. It’s everywhere, and to be honest it’s a solid, mature library. It’s also often already loaded on the page, especially if you’re working with WordPress.

Outside of DOM manipulations (which you can now do mostly with native JS), jQuery’s $.ajax() method is really handy and works well.

But did you know that this function provides Promise interface out of the box? I recently remembered this and I thought to myself:

Hmm I wonder if I can use async/await with jQuery’s $.ajax().

Turns out, you can!

The setup

Async/await is really new still, it’s only in the ES2017 spec, so you’ll need to use a transpiler like Babel to get it working in older browsers. Most of us are using Babel anyway with our bundlers (Webpack, Browserify), so this isn’t a huge deal.

Assuming you already have Babel installed and configured, the first thing you’ll need to do is get Babel to use the ‘env’ preset. In your .babelrc file, add these lines:



{
...
"presets": ["babel-preset-env"],
...
}

You’ll also have to install this Babel preset and polyfill from npm: npm i -D babel-preset-env babel-polyfill.

Once that’s done you’ll also need to install this magic plugin for Babel: npm i -D babel-plugin-transform-async-to-generator. This is the key package that lets you use async/await in your code. I should mention that this simply gets Babel to compile the async/await syntax to ES2015 generators, so if you’re not targeting most modern browsers keep that in mind.

The next, and FINAL thing you need to do is use the babel-polyfill module in your code. You can use a Webpack loader if you like, or just include the package in your source files:



import 'babel-polyfill';

Phew!

Ok, now we’re ready to go. Start up Webpack and let’s start using async/await!

Don’t call me, maybe

Back in the day you had to use $.ajax() like this:



//Function wrapper that confuses alot of devs because async code works differently
function doAjax() {
    $.ajax({
        url: ajaxurl,
        type: 'POST',
        data: {
            stuff: "here"
        },
        success: function (data) {
            //wacky nested anonymous callbacks go here
            var something_but_not_really = data;
        },
        error: function (jqXHR, textStatus, errorThrown) {
            // Empty most of the time...
        }
    });

    return something_but_not_really
}

I know when I was a junior dev I had no idea why something_but_not_really was undefined. I had to learn about callbacks a billion times .

But now…



async function doAjax(args) {

    const result = await $.ajax({
        url: ajaxurl,
        type: 'POST',
        data: args
    });

    return result;
}

And result actually returns the AJAX result. Cool right?

The big benefit of async/await is that it makes asynchronous code appear synchronous. As in, do this thing, wait for it to finish and then give me the result.

Errors

Notice anything missing in our new function? Yep, error handling is non-existent. Fortunately, since async/await is essentially synchronous, you can use try...catch()!!!



async function doAjax(args) {
    let result;

    try {
        result = await $.ajax({
            url: ajaxurl,
            type: 'POST',
            data: args
        });

        return result;
    } catch (error) {
        console.error(error);
    }
}

And there you have it. Some error catching built in. Now, there’s other ways to handle errors with async/await, but they’re a little more complex.

The other thing to keep in mind now, since we’re returning the result of an awaited function, result will equal a Promise instance. You have 2 options with what you can do with the result.

The first option is to make sure that you use await when calling doAjax() later on.



// Elsewhere in code, inside an async function
const stuff = await doAjax();

The other option is to use the Promise interface and roll that way:



doAjax().then( (data) => doStuff(data) )

Promises aren’t all that bad, and can look cleaner or be easier to work with, depending. I’ve found that using ES2015 classes it’s sometimes easier to use the Promise interface, so YMMV.

But that’s it – go get your $.ajax() using async/await today!

The post Using async await with jQuery’s $.ajax appeared first on 🔥 Database Critical 🔥.

JavaScript’s cryptic ‘this’ – what, when and why

Peter Tasker — Thu, 30 Nov 2017 20:30:18 +0000

Photo by Tarun Ram on Unsplash

Before MDN started to organize their JavaScript documentation, finding answers to your JavaScript questions often landed you on Stack Overflow.

Welp, these days MDN has mostly done away with that practice, that is, except if you’re looking for answers around the usage of JavaScript's this keyword.

The documentation is great, it really is, but it’s not exactly full of helpful, real-world examples. So I thought I’d put together a few tips and tricks about the ever so magical this keyword.

Old-skool JS

“Back in my day we had to alert out our objects!”

Ok, so yeah, if you run console.log(this) in your dev console you’ll generally see that by default, this = Window{}. Super helpful...😏

It gets more interesting when you check the value of this inside a function:

function mahFunc(){
    console.log(this);
}

mahFunc();
// Window{}

You should still see the Window object. Ok so, nothing new here.

But what if you add 'use strict'?

function mahFunc(){
    'use strict'
    console.log(this);
}
// undefined

Hmm.

Ok now, but what if you call mahFunc() on the Window global (since it’s a global function)?

function mahFunc(){
    'use strict'
    console.log(this);
}

window.mahFunc();
// Window

Huh?

Strict mode is a funny beast, but it generally makes errors more obvious and cleans up your JavaScript.

Something not mentioned in the MDN docs is that bundlers/loaders/concatenators like Webpack/Browserify, may have strict mode enabled by default. You might end up with some wacky loader that enables it with out you knowing because all your scripts are bundled together.

So keep an eye out if you ever see your this call returning something funny.

Call me plz

Ok so this in a global context is weird, but who doesn’t use objects and ES2015 classes these days? If you’d like to use a different value for this, (as-in not undefined or Window) inside your function, you can pass a context with .call() and .apply(). I always remember these with ‘yadda-yadda.prototype.call()’.

function mahFunc(){
    console.log(this);
}

const config = {

    stepOne(){
        //do step one
    },

    stepTwo(){
        //do step 2
    }
}

mahFunc.call(config);

//{stepOne: ƒ, stepTwo: ƒ}

And there you go. this references the object passed in argument to .call(). Cool right?

This way you’re able to specify a context for a function. It’s super handy and what a lot of frameworks and bundlers use internally – check out your Webpack bundles!

I won’t go over all the possible cases/uses of this, there’s quite a few and the MDN doc is really good.

It’s important to remember this 🙄.

The post JavaScript’s cryptic ‘this’ – what, when and why appeared first on 🔥 Database Critical 🔥.

Best way to copy an object in JavaScript?

Peter Tasker — Wed, 22 Nov 2017 20:22:55 +0000

So I'm always looking for a way to use vanilla JS whenever possible these days, and I discovered that deep copying an object in JavaScript is still weird.

StackOverflow reminded me of the JSON.parse( JSON.stringify( obj ) ) trick, and it looks like Object.assign still doesn't copy nested objects.

jQuery's $.extend() works. But that's not vanilla JS any more.

What hacks do you guys use for copying JS objects?

¯\_(ツ)_/¯

Open Source, PHP and Visual Studio Code

Peter Tasker — Tue, 21 Nov 2017 19:51:03 +0000

Lately, VS Code has been getting a lot of hype in the dev community. It's been around since for a few years and TBH is a really sweet editor. Lots of great extensions and community support. It's also quite fast (for an Electron app 😬) and the peeps and Microsoft seem to be keeping it up to date and iterating quickly.

However, anything you really need to work with PHP is missing by default. I believe this is by design to encourage a vibrant extensions community. Luckily, like most languages, there's a vibrant open source PHP extension community. There's a few great extensions for PHP: PHP IntelliSense, PHP Debug (both by the same developer) as well as PHP Intelliphense (#wat?). There's even a really great intro by Jeffrey Way on Laracasts outlining everything you need to do to get VS Code set up for PHP dev.

Some of the PHP packages work fine and have over a million installs (!!!). Sometimes, however, they don't work. Like, at all. Just today, the PHP Debug extension completely broke. Luckily the developer was paying attention and rolled out a fix within hours. Pretty awesome support for an open-source product!

However, if you paid for the editor, say something like PHPStorm, you could go and raise an issue on their support channel. You could complain about the product not working, rightly so, as you've paid for the right! As a 'customer' you have a certain amount of clout with a vendor like Jetbrains. This is NOT the case with open source, and I feel that we developers forget this.

This is where I take issue. I'm all for open source software. I've built my career on it. The issue is that the developer for this plugin had to fix the issue himself. There's an expectation there that he HAS to fix the issue, and do it RIGHT NOW. And if it's not done immediately people freak out, complain on Twitter, write a blog post about, have a cow 🐮, man.

Open source is just that, open. If you find an issue with a plugin, editor, extension or WHATEVER, see if you can fix it! That's the whole point. Let's not throw our hands up and complain, let's get our hands dirty and fix the damn thing.

That's what open source is all about. Let's remember that.

/rant