Building a WordPress site plugin

Nearly every WordPress site can benefit from some custom programming. Code that tweaks things a little, usually using hooks (actions and filters) to adapt the output or how certain things function. These type of small changes are usually best organized in a “site plugin”, that is a custom plugin built for your specific website. This is done instead of the other more common “solution”, stuffing any custom code changes into the theme functions.php. Now there is a time and a place arguably, to use functions.php as a place to organize code. However theme stuffing as I tend to call it, is definitely over-used, and comes with many drawbacks.

At the very least you should ask yourself (as a developer) is the change I’m making really a presentation (theme layer) change? If not, use a site plugin. Even in cases where the change does affect the presentation, bear in mind if it involves any substantial logic it may not really be suited for the theme layer. You could make the argument for instance that a custom menu walker used to render the output of WordPress menu’s differently, is a presentation change. That’s true to some extent, however, that logic can be applied to almost anything that changes what you see in a web page, or template. The reason a custom menu walker would be better placed in a site plugin is because it may require future changes, and it’s a fairly substantial amount of code. A walker class can be several hundred lines. It is a PHP class, which should be your first clue that it belongs in a plugin.

As a site owner if you’re reading this and not sure when/where site plugins would help, that’s okay. My advice is aim to work with developers who have plugin build capabilities, rather than those who only work at the theme layer. You’ll get a lot more mileage from your developers in terms of extending and integrating plugins and API’s, and the benefit of keeping your custom code better organized.

Better organization of code isn’t just for a developers benefit. It has a direct impact on the cost and effectiveness of development. Site’s with a lot of theme stuffing can be very difficult to work on, time is lost sifting through poorly organized code. A well organized and commented site plugin can be structured to make finding custom code a lot faster, and that should translate into lower development costs.

A custom site plugin should not be the end all be all solution however, otherwise you may run into the same problems as in using functions.php. Although it’s fine to organize many smaller changes into a single plugin, it’s important to know when to create a second custom plugin (or 3rd or 4th) for specific site features. Don’t continue to expand the scope of your “catch all” site plugin which is there mainly as a utility plugin. If for instance you had an ecommerce site with a number of WooCommerce customizations, those should fit well into your site plugin. However if you have extensive subscriber management customization involving WooCommerce Subscribers, this is an area that probably deserves a second custom plugin to isolate that codebase.

Site naming conventions for site plugins should be kept simple and easy to understand. If the site name domain is “cancun-dental.com” use the domain name and make the site custom plugin name “cancun-dental”. Easy peasy. Now if you have need for more custom site plugins consider adding to that name such as for the example WooCommerce Subscriptions customizations, the plugin name would be “cancun-dental-subscriptions”.

Working with WordPress Tags

Metabox plugin is awesome

How awesome is the plugin metabox from metabox.io? It’s amazing that’s what! Look, I’ve been an ACF fan for years. Coming from a Drupal background the first question I had about switching to WP development was “does it have a field API”? The answer was no, but try ACF. And I did. And I came to rely on it for just about everything. Long story though, I eventually became less enthused about ACF. I very much regretted embedding ACF into QuizMaster for instance, which is a different topic.

Metabox in my view stands head and shoulders above ACF. I actually like their extension driven approach, which I think is a good structure for WordPress plugins in general. ACF interestingly enough was extension driven earlier on and has since gone away from that model. Of course 3rd party developers can (and do) still publish extensions for ACF, but there is something about the core using the extension system that I trust a lot more. Meaning it’s one thing to say you can extend a plugin (but we don’t!) versus saying you can extend it using the same extension system we just used to built all these extensions over here. Metabox can say that, ACF cannot.

I’m not familiar enough with the Metabox extensions yet to say if Metabox can do all that ACF could. A quick tour of their extensions directory (salivating at the prospect of buying the development license!) and I found several extensions that do stuff I always wanted to see done in ACF. It looks to me like they either kept tabs on what ACF customers were asking for (and delivered it) or they just have a great vision of what a field system should be capable of. For instance one of the pet peeves with ACF is the way it stores data. It essentially “doubles” for lack of a better word, the meta storage for each field value. One meta entry to reference the key, another to reference the value. Something like that (it’s complicated). Now with ACF or Metabox you might not ordinarily be accessing the meta directly anyway… but if there is one thing I know about strange ways of handling things in any system, you usually suffer for it eventually. ACF’s odd way of storing data was often cited as the reason the developers could not deliver certain commonly requested features. Exporting values for instance has always been weakly supported by ACF.

Is this a post about ACF or Metabox you might ask? Well getting back on track here… Metabox has an extension that allows you to store your field values (meta data) in a custom table. There is one example of how it offers flexibility that ACF (AFAIK) does not. Another is something like a “merge data” option that enables grouping data together to reduce the table rows. Meta data does have the risk in WordPress of quickly piling up a massive number of table rows, WooCommerce for instance stores something in the range of 40 rows per order! Just think how that can add up on a high volume website.

Here are a few of the things I’m liking best about Metabox:

  1. Online Meta Box field and metabox generator. Visit https://metabox.io/online-generator/ to try it out yourself.
  2. Extension selection of Meta Box Extensions available at https://metabox.io/plugins/. Many of the plugins are free, and for the premium plugins the licensing terms and prices are fair, especially if you buy either the developers license or the lifetime license.
  3. Data storage as regular post meta. Unlike ACF the Meta Box plugin stores post meta in much the same way we would normally, so it’s easy to retrieve manually even without using the Meta Box value getters. There is also an extension that can store your data in a custom DB table.
  4. Easy to integrate into a theme or plugin. Current versions of Meta Box integrate even more easily than in the past where it took setting constants and possibly using a class. Today it takes 1 line, that’s it! Perhaps to avoid conflicts or check for versions it is worth wrapping that integration in some form of plugin activation check, but if you own the site you’re building on you can just be sure to integrate Meta Box only once. 
  5. Great support by dedicated developers. After using Meta Box only a short while I’ve already been in touch with the developers and they provide great support. It’s clear from their regular updates and involvement with their community that their very dedicated to the Meta Box project.

Well I’m off to integrate more Meta Box extensions into Clay Framework which powers GoldHat.ca. Stay tuned for more articles about Meta Box including some tutorials as I continue learning and working with it.

Setting templates from your plugin

Often when we make CPT’s (Custom Post Types) we want to provide a default template to render the single posts. We also want that template to be overridable in the theme layer. The answer is the filter single_template which allows us to direct WordPress to load the template from our plugin. As for making it possible to override the template, we won’t cover that here but you can learn about how we do this in QuizMaster and Clay Framework by watching this video: https://www.youtube.com/watch?v=aQyQ615oWcM.

Example code below shows the use of single_template filter to select a template from a plugin.

 

WooCommerce developer mods compilation

Removing the annoying “Showing the single result” message when the catalog has only 1 product.

This example does the job, but bear in mind that the ‘woocommerce_result_count’ action won’t show at all even if the count increases later.


Change the add to cart button text.


How to remove the “default sorting” dropdown from WooCommerce

 

NoSQL with XML

I’m always interested in the idea of NoSQL, alternative databases and document storage because I think someday this approach may become standard. If there is one constant pain in any CMS, it’s the challenge of syncing different versions, updating code. It’s great we have GIT to keep our code in sync, too bad our content and the site configuration is rolling out of date every single second.

On FWW (http://freelancerworldwide.com) which we have hosted on WP Engine we’re constantly faced with this hurdle when deploying. We use WP Engine’s GIT Push feature to update code on a staging server, then when it’s ready to deploy we do a manual migration with WP Engine’s migrate code-only feature. The database obviously cannot be migrated from testing sites or else we’d lost live data. Sure we can roll forward our staging sites using the latest DB from live, but even that comes with it’s own risks. We had to a “cleaner” script to eliminate all the sensitive user data from the live DB otherwise aside from privacy and security risks, we’d be possibly sending email notifications from testing servers out to the live users.

Imagine a system without a DB, with a form of version-controlled content and configuration. I tend to view this as a way to solve all these migration issues. And I like XML for it’s relatively low learning curve. I envision users, even non-devs, being able to manually edit XML files to change config settings, or even to write their own content directly into a file. And I also like XML because it’s tangible, or real in a way that some of the other NoSQL DB’s are not. If the data disappears, then requires code to retrieve, to me that means the objective is lost. I want the absolutely simplicity and flexibility of being able to open a document on a web server and see, there is a the configuration, or there is the content in “plain sight”.

On two GoldHat projects we’ve used some form of raw XML storage. Certainly storing data in XML is easy enough. It’s searching and filtering and other matters that become interesting, and sometimes messy. But nothing so far has really stopped us from doing all the normal operations we’d usually see in a DB solution. Below are a few of the tactics we’ve used to make an XML-based data storage system with version control:

  1. Create a separate directory from the rest of the project, we’ve been using “/data” but it could be “/content” or other.
  2. Version control the content directory separately from the source code of your project, which means adding it to your .gitignore file so it doesn’t end up in the source code.
  3. Create a method that automates indexing of records. When an XML record, say “ticket” is created then the “ticket index” file is updated merging in the reference to the ID of the given ticket.
  4. Create random alpha-numeric ID’s for records, possibly prefixed by a code for the record type such as “TKT-8779XC81729”. Then store the files in a directory based on type such as “data/ticket/TKT-8779XC81729.xml”.
  5. Write loading methods in a class such as “Records” to load a single record such as $record->getByID( $id ).
  6. Write a class specifically for loading record lists such as “RecordList” and provide methods to set filters such as $record_list->addFilter( $field, $value, $operator ). Filtering is then handled by XPath queries.
  7. Use a front-end solution such as List.js or jQuery Datatables to limit your need for filtering and sorting on the server side. Build your system to load list data unfiltered and unsorted, but dynamically apply front-end sorting/filtering.

 

Concrete5 Version 5.7 Review

Preface: this Concrete5 Version 5.7 Review is a WIP (work in progress) and I’m updating it as I continue to explore C5.7.

By my count there are currently 115 C5 addons in the Concrete5 addon marketplace for 5.7. The 5.7 marketplace for both addons and themes is entirely new. C5 is now basically 5.6 and below, and a completely new CMS system for 5.7 and above. None of the 5.6 C5 themes or addons are compatible with the 5.7+ version.

In comparison the addon marketplace for 5.6 has an estimated 930+ addons based on a reporting of that number from C5 founder Franz Maruna in June of 2014. This significant divide between addon availability is sure to mean that 5.6 is to remain the choice of developers for new C5 sites for quite some time to come. After all building a site today is often just as much or more about what you can integrate or add to the CMS foundation as it is about the CMS system itself. Without significant coverage of common requirements for a wide variety of sites, what happens is that nearly every candidate to use the system finds some form of blockage due to lack of addons. This is a problem that will never be found in WordPress.

As somebody whose view of the CMS world focuses mainly on WP, Drupal and C5 I see this unveiling of Concrete5 version 5.7 as being something more similar to Drupal’s approach than WordPress. Drupal is notorious for it’s policy of launching completely different and largely incompatible versions at every major release. Put D6 modules into a D7 site? Of course not. Use anything from Drupal 5 in Drupal 6, no way. The sheer cost of constant full upgrades involving lots of manual work and requiring countless development hours, is almost like a Drupal make-work project for the community of developers. All at a huge cost to Drupal site owners of course, who I have to say I now pity despite my years as a Drupal developer.

C5 has promised that this fully new version 5.7 is a one-time occurrence, or at least we will not see a repeat of this approach for a minimum of 6-years. That’s a reasonable amount of certainty I think for theme and addon developers to begin building for 5.7 safe in the knowledge their work will stand some of the test of time. After all getting a return on these investments does often take 2-years or more. Perhaps another reason we don’t see as much of a marketplace within Drupal (among other factors) for premium modules.

Installing C5.7.3.1

First notable difference is the cPanel QuickInstall that I have in my demo hosting account does not have the C5.7 version available. Hopefully that will change in the future. While for a real project with a full site build I would generally be in favor of a manual install, I do like having an automated install to use for demos or when testing an addon or theme. Whatever differences occur in the install are not important enough to me to warrant the time of setting up my database and especially uploading the files to the server. Speaking of which I should check if this version of C5 installs easily on local machines using WAMP, something I found C5.6 often had troubles with for various reasons.

The install process for 5.7 seemed to be the same as I remember it. After install I see a screen that shows the getting started with C5.7 video. Nice video, but I’ve already seen it thanks! I am automatically logged in with the user I added as the admin. So far so good, install worked and took only a couple of minutes most of which went into the file upload and database setup.

Concrete 5.7 Responsive Content Slider

The first thing I notice after install is that my site actually looks like a polished, working website with placeholder content but nonetheless it works. I like it. The responsive slider stands out. I test it’s responsiveness right away and find yes, it’s very responsive! And it’s not just a slider for images, it’s a true content slider evidenced by the content it has already loaded up in the dummy content.

I put the page in edit mode and go to edit the slider. What I find is the slides can be changed with a simple form that offers me an image selector, title, body and optional link. I would seem I must have an image so it’s still more an image slider than a content slider. Once concern I have is if your slider has 10 images, that’s 10 different forms listed in a big long column. It could get really annoying to scroll through to find the image you want to edit. I feel like with this type of content maybe a list of the images would be a better interface approach.

Like any C5 block this image slider can have custom templates, and that’s an exciting prospect given that customizing sliders in other CMS systems is often quite a pain. I can imagine here we can make a custom template, and between that and some CSS we could create nearly any slider layout or design that we wanted. Definitely loving the general concept of the C5.7 responsive image slider.

Sidebar Editing

When I went to try to edit the sidebar I found the notice “This block is an alias of Page Defaults. Editing it here will “disconnect” it so changes to Page Defaults will no longer affect this block.”. I haven’t used C5 in awhile so I’m somewhat hazy on how Page Defaults work but generally I think this notice means it’s like a template area used throughout the site. If I change it on 1 page, that version is then no longer part of the template. Can you follow that logic? Hope so because this is the kind of issue that might still make C5 a challenge for the brand newbie. I could see people not understanding this, or making changes then being surprised by the results. As much as the “in-context editing” that Concrete5 CMS has is a key selling point, it can at times come with it’s own challenges and complexity. For managing sidebars for example, I’d still have to argue that relatively old-fashioned WordPress with it’s widgets system is faster and more intuitive. Not that it’s an apples to apples comparison because really the whole concept of site editing is so different.

Text Block Editing

Instead of the familiar popover Text Blocks can be edited inline. This is a really nice enhancement of the editing interface. Upon clicking edit block, the Redactor editor appears above the block of text. It hovers there and remains in view during scrolling. Works well even when editing long text blocks.

The Mystery of Adding New Blocks in C5.7

Well my first major hurdle in testing out C5.7 is adding new blocks. I click on the big plus symbol in the C5 edit menu, it turns into a throbbing blue dot. Looks good, but then when I anywhere on the page, I still see the menus applicable to editing. Click a block and I see the block editing options. Click a page region, I see customization options. I don’t see a way to put a block into the page and there is no instructions in sight. I suppose a trip to the C5.7 editors guide would solve this, but I’m more of the bash my desk with my fist until the answer appears type. Seriously though, how could something this simple be not totally obvious to me?

I eventually solved this by switching out of edit page mode, then click directly on the add button. At that point the block options appeared as a side menu which is what is supposed to happen. Not sure if I discovered a bug or oddity, but for some reason when I had been playing around in edit mode clicking add content did NOT open the block menu, which meant that there were no blocks to choose from.

Concrete5.7 Development Resources

My Favorite CMS Features from WordPress and Drupal

I work with both WordPress and Drupal. As a PHP programmer I was drawn to Drupal in 2009 and started with D6. I avoided WP despite all its popularity, always thinking of it as a blog, or more for small sites. I wanted more structure, more of a programming framework. Back then I also worked with PHP frameworks, and given the choice I would have normally rathered to work with CodeIgniter than any CMS. After all when I started building sites in 2002, there were no CMS’s at least nobody told me about any worth trying.

Today I am always a bit torn about “which is better” between Drupal and WordPress. Like many others I’d like to be able to make a definite statement on that and say well, I’ll just focus on ____BLANK. It’s not that simple, I used to have this site goldhat.ca in Drupal. Then I tried Concrete5 briefly, that didn’t work and when shifting away I decide no I’m not going back to Drupal, I’m going to try WordPress. Having seen how easily many parts of WP work on client sites, I wanted to see if it could handle some of the customizations and extensions I wanted to add to goldhat.ca. I found it could, especially with the help of a plugin now use in nearly every WP site I run, ACF (Advanced Custom Fields).

What is the key differentiation between Drupal and WordPress?

If I had to point to 1 key different in these systems it’s that in WordPress generally things just work, and they look good. In Drupal, again speaking generally (and no offense to Drupal gods!) most things look terrible and arrive broken and require extensive work to make functional. Now that might sound like a damnation of Drupal, which it is to some extent. But we have to consider that if you measure based on the general “size” of a website, measure not really by number of pages but by complexity of features especially the need for external integrations, complex logic, custom programming etc., then the comparison tends to look like this in my mind:

  1. Small, simple site: WordPress rocks. Install it, pick a theme, customize theme, install some plugins, everything looks good and works good and the build is fast. Management is fast, further development easy. Drupal in contrast, much more configuration needed to get this simple site looking and working well in most cases.
  2. Medium site: here is where it’s a bit of a toss-up because in this range WordPress might be okay, and Drupal starts to be more competitive. I’d still tend to lean toward WP but that’s because I’m very comfortable extending WP with plugins and using ACF to add the fielding and custom content options that make it seem a lot more like Drupal. With a medium complexity and size you have to start looking at specific plugins and modules and features and asking which system fits the specific site being built.
  3. Large, complex site: no question in my mind that when already have more complexity in your site, then the complexity of Drupal starts to make sense. The time required to get up and running, is acceptable because you would have to spend that time in WordPress anyway given all the functionality you might need to build up. A key example of this is when you need advanced roles/permissions. Drupal generally has better support for this (though WP has plugins that add more support in this area).

A principle I now live by is to use WordPress whenever possible. Meaning only go to Drupal, or another solution including a PHP framework or custom platform like Moodle/Magento if WordPress really seems like a poor fit. And I find increasingly that is a rare situation. In fact I’m working on a site right now where the lead build team said absolutely no way we could build this in WP, it’s too big, too complex, needs too many roles and access handling, security features, etc., but I’m not really convinced that was true. Often I believe that Drupal builders make the presumption that only Drupal has various features, when in fact WP has them perhaps implemented in a different way.

Best Drupal Feature

In my mind without question Drupal is a leader if “Fielding” or custom content type development. This is where you need custom content such as a real estate listing, and you can build your own content type and add the various fields such as bedrooms, baths etc. It’s like being able to develop your own custom application inside the Drupal admin. Other CMS systems of course have some equivalent feature, WP now has custom content types in the core but it doesn’t have fielding in the core. So fielding is a key feature because in almost any significant site your main goal is to store various types of content. And being able to do that with “fields” rather than building up pages with text alone is crucial. Drupal handles this in a powerful way. And fielding doesn’t stop at making the fields, there is also display handling so you can dictate how your fields display. For many situations, you can make your custom content types and your fields in the admin, and configure the display, and never need to do any custom coding to have a function system to add/edit/delete custom content and display it.

Best WordPress Feature

Is simplicity and everything working and looking good a “feature”. It’s not as easy here to pick something that stands out and maybe that’s because WordPress is less about “powerful features” and more about a holistic system that is balanced and works well in every aspect. You might complain about lack of a feature in some areas, but you will rarely complain about something not working or not being well designed. Back to the point… best WP feature in my book is the drag/drop widget handling and the sidebar system. This makes adding widgets really easy and when you’re building themes or doing more extensive customizing there is enough power under the hood to extend this system and create whatever sidebars you want. It’s definitely much friendlier to use than the Drupal equivalent which is either Blocks Management or Context. And the fact that Drupal has Context, which is basically a more advanced way of handling Blocks showcases that the core blocks system is not very friendly to use.

 

 

VeganServer WordPress Plugin

When working toward launching a vegan cafe (VeganCafe.ca) one of the first things to come to mind (being a geek) is “what software will I use”. And knowing from previous experience that some of the big titles in food management are costly, I wondered if we could could find or build something that would get the job done.

We needed an online menu, but also a lot more.  Like online ordering from the menu. Delivery options, eCommerce integration. Nnutritional analysis and costing information, purchasing lists. Food inventory management. A full “ERP-style” approach to food management. And though certainly there were plenty of existing food and drink WordPress plugins several of which we tested out on our restaurant demo sites, none did it all and few worked together in any meaningful way. Most were one-shot fixes for a single issue, such as a nutritional analysis plugin where you had to enter the values manually. That’s not going to save us hours and give our vegan cafe a technological advantage!

VeganServer is our invention to give vegan food companies a user-friendly, effective and powerful food management application built into the WordPress software many are already familiar with. You can see an example of how it creates stylish recipe displays here at http://vegancafe.ca/recipes/greek-pizza/ and learn more about the plugin itself at http://vegancafe.ca/vserver-wordpress-plugin.

We are currently beta testing VeganServer and working on tweaks to the costing system and some of the other extensions. It’s already useful for recipe display and menu display, and we look forward to having a number of vegan food recipe sites and vegan restaurants trying out those features during beta testing.

Wordpress Shortcodes

WordPress Shortcodes

Simply put, a shortcode is a coding version of a shortcut. It is a WordPress-specific snippet of code that allow you to save time and create functionality in your WordPress site that would otherwise take a lot of time and effort. 

When you are editing a WordPress site, shortcodes such as the examples below can be dropped into any page or post (including custom posts).

  • [shortcode_name]
  • [most_popular_post]

From the WordPress.org site:

A shortcode is a WordPress-specific code that lets you do nifty things with very little effort. Shortcodes can embed files or create objects that would normally require lots of complicated, ugly code in just one line. Shortcode = shortcut.

For WordPress developers shortcodes provide a way for their plugins and themes to pass on functionality to users. Shortcodes create a bridge between the complexity of writing code and the users ability. It’s also a simpler approach to passing on functionality than say to build an entire separate interface.

Developer Resources for Creating WordPress Shortcodes

Tutsplus tutorial on WP shortcodes: http://code.tutsplus.com/articles/getting-started-with-wordpress-shortcodes–wp-21197

 


About the CMS Feature Comparison Series

CMS systems like WordPress and Drupal have so many features it’s hard to keep track of them or compare them. Often comparisons are apples to oranges, or even apples to turnips. It requires context to make comparisons of features, and we need to look at what the goal is of the given feature. In our series of CMS features comparisons we do our best to look at a useful feature of 1 CMS system and then compare it to other systems that we work with. We focus on WordPress, Drupal and Concrete5 but may include other systems in certain feature comparisons.