Announcing Games Collector, a tabletop game management plugin for WordPress

I’ve been quietly building something under the radar for a couple weeks. It’s been really just a passion project that came out of a conversation after the holidays.

Basically, we own a lot of games. Blame Wil Wheaton’s Tabletop for some of it, but, really, we’re frequently finding excuses to get new games. In fact, getting a new game for the family has become an annual tradition. We have so many games that it’s sometimes hard for other people to keep track of what we have and what we don’t have. And that’s where the nugget of an idea for a plugin for WordPress came in.

It started off as just a way to list the games that we own. But as I was thinking of ways to display the games, I started thinking about the user experience a bit more. Lists aren’t fun, but you know what is fun? Stuff that moves around. So, I decided to integrate Isotope.js to sort the games by different filters. Isotope animates the transition, so you’ll see games disappear and reappear and there’s lots of different things you can sort by.

As I was working with these filters I thought “wouldn’t it be cool if you could use the game list as a way to get ideas about what games to play?” What game to play depends on the audience, right? So, I added a “difficulty” dropdown that you can use to determine how hard the game is to learn. The range goes from Easy to Hard Core. What game you suggest also depends on how many people are playing, so there’s also a dropdown for number of players. So if you have a group of 4 hard core gamers, you can get a list of games that would be good for that group, and for that many players. Whereas, if you have a group of 7 or 8 casual gamers, you can get a list of games that are more laid back and are good for larger groups.

How does it work? Well you can take a look right here on my blog: Games. It uses a shortcode which you are probably familiar with if you’ve used WordPress for a while. There’s some notes on setting it up on the GitHub page. Here’s a screenshot of the back-end.

If you love games as much as me and you use WordPress, download the plugin and let me know what you think. I’m not planning on releasing it on WordPress.org any time soon because I don’t want to deal with the support forums and because it’s written for PHP 5.6 or higher (which is greater than the minimum requirement for WordPress), but if you have questions or feature requests, you can reach out on GitHub.

This is just the first iteration. I’ve got some ideas about how to extend the plugin moving forward, including integrating the WordPress REST API so the game data could be used outside of WordPress, in an app, for example. The mobile experience isn’t great, and I’d love to eventually build a way to manage and view your game list in a dedicated app on your phone.

Anyway, this is a cool little thing that I’ve been working on and excited to share. Again, download it and let me know what you think!

The single greatest contribution to open source by WordPress is documentation

I’m going to throw an idea out there, and that is that the single, most important contribution that WordPress has made to open source software as a whole is documentation.

When I first started using WordPress 8 or so years ago, that was the biggest difference between WordPress and other platforms. You could search for something and actually find the answer. There was even a huge wiki dedicated to how to use — and modify — the platform: the Codex. With other open source web application software platforms at the time, documentation was always scarce. The first Magento project I worked on, I had to teach myself how their theming system worked. Likewise for ZenCart and Joomla!. This self-education takes time, and this is the whole reason we say “I am a WordPress developer” as opposed to “I am a web developer.” Sure, I have skills that extend beyond WordPress, but I know WordPress in a way that I don’t know other platforms. I am much more able to work on the fly on something I’ve never tried before in WordPress than I am on a roll-your-own platform or some other CMS. And the availability of documentation plays a huge role in this.

The two WordPress-specific businesses I’ve worked for — Event Espresso and WebDevStudios — both have had their own, internal documentation based (at least in part) on the WordPress Codex. That’s in addition to the user documentation that’s readily available for most premium plugins. The docs may not always be complete — and they may not always be good — but they are there and you can usually find answers. Plugin developers specifically are motivated to provide good documentation to eliminate the amount of support requests they get via support forums. These support forums are a form of documentation, too. I asked a question on a Magento forum a few years ago and I don’t think I ever got a satisfactory answer back. If that happened on a WordPress forum, the hounds of hell would be unleashed on the plugin author or, at the very least, everyone would start to avoid that plugin. If it was a WordPress core component, a Trac ticket would crop up pretty quickly with a long discussion about how best to solve the problem and, eventually, a fix would get built into WordPress core.

WordPress people are always talking, always communicating, and this is part of what helps WordPress grow. The first blog platform I used was sBlog, which had little-to-no documentation and a very small community around it. If you’ve never heard of it before, that’s because it doesn’t exist anymore. A slightly better platform I played with for a couple years (which does still exist) is Ampache, a web-based music player where a lot of discussion and documentation happened in the forums or else in the IRC channel on Freenode. But because there aren’t blog posts about “I built this awesome thing with Ampache” — and because there isn’t the amount of documentation for Ampache to help developers build awesome things — not many people know it exists.

And that’s part of the reason why I was initially lured into the Docs contributor team. WordPress documentation is a huge part of how I got where I am today, it’s what sets WordPress apart and helps it grow, and it’s vitally important to the continued success and growth of the software. But what I’ve noticed in those years since first toying with Joomla, Magento ZenCart, sBlog, and Ampache, is that other projects now have more documentation available, and put more of an emphasis on documentation. Look at HTML5 Boilerplate or Bootstrap. Look at Git and jQuery. Spend some time on StackExchange. There are tons of answers out there now, answers that weren’t there for us 8 years ago. I feel like the success of WordPress has brought with it the rise of better documentation — and those platforms that fail at documentation get passed over by ones that have documentation. And that documentation increases in relevance and quality as things like MediaWiki have cropped up and allowed for the crowdsourcing of said documentation so that anyone can be an editor or an author of a tutorial or code reference. Yes, I credit at least some of this to the popularity and rise of WordPress as a publishing platform, and I suggest that it is the most valuable contribution by WordPress to open source software. Even if WordPress someday fades, its’ footprint will be left by the emphasis on — and prevalence of — good documentation.

Is it possible that my glasses are rose-tinted because of my involvement in the WordPress community? Sure. But the thing is, WordPress is the most common CMS in the world. More than 20% of the web is built on WordPress and the percentage of new sites using WordPress is even higher. So, one way or another, other projects will need to learn by the example set by WordPress if they want to stick it out and become a viable platform that people can pick up and use without having to dig through lines of code to figure out how.

Code: Getting rid of the duplicate submenu with add_menu_page and add_submenu_page

So  I ran across an issue today when creating a custom admin menu and submenu items. I wanted to have a submenu item in the menu that linked to the main admin menu page, but did not have the same anchor as the parent. I kept running into this:

 

You can see that, since I’m currently on the Options page, both the submenu item for “Program Areas” as well as the submenu item for “Options” are both saying they are active. That’s because this is the way you expect to create submenu pages:

See? You declare the admin menu. Then you add the submenu. Makes sense, right? Everywhere you look, that’s how you will see it written. Even over here, where this guy was having the same problem.

But that will give you a submenu item with the first item in your submenu being a duplicate of your parent. There are even hacks where you create a menu item that’s just blank. So, great, here’s an empty tag in my menu. That’s a good solution, right? (Note, that didn’t work for me, either, but it did help in figuring out what did actually work.)

This is what you actually want to do if you want this:

 

See what I did there? I’m adding the submenu pages before the parent menu. For some reason, this short-circuits the tendency to create a submenu item with the same settings as the parent and allows me to have a submenu item with a different anchor link. This is the actual, working code from the project: