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”.

Creating a custom post type with Meta Box

MB Custom Post Types extension installed

MB Custom Post Types extension installed.

In this tutorial we’ll build a custom post type named “Services” with the Meta Box plugin’s free extension Meta Box Custom Post Types. If your site doesn’t already have the plugin installed, search the WP Plugins directory through the WP Admin > Add New or download from the WP Plugins directory listing at https://wordpress.org/plugins/mb-custom-post-type/.

Meta Box Custom Post Type plugin menu

Meta Box Custom Post Type plugin menu

For docs and to read more about the Meta Box Custom Post Types extension visit it’s page on metabox.io at https://metabox.io/plugins/custom-post-type/.

Now let’s get started using Meta Box Custom Post Types extension!


 

Our goal in this project is to build a “Services Directory” that provides general information about GoldHat Group’s services in a way that generates leads from propective clients. We don’t sell these services directly so this needs to be outside of our shop where we sell WordPress plugins and some packaged services. This is more of a traditional agency approach to displaying services so that prospective buyers know what our capabilities are. We also want to tie our services pages to the any product packages that contain the given service, and reference projects in our project showcase that demonstrate the services we offer. Using a custom post type helps us organize this in a way making regular WP pages would not. And this principle of using CPT’s for distinct types of content is one we can apply in many situations when building websites, key benefits include:

  • Having an archive page (directory listing page) that lists all the posts made using the custom post type
  • Breaking the content management of the custom post types into fields by using meta boxes and fields
  • Setup custom taxonomies (categories and tags) to apply to the content
  • Manage content more easily in the WP Admin

 


Meta Box add new post type

Step 1 Basic Settings

Click “Add New Post Type” from the MB Custom Post Types menu. Enter the plural and singular names for your CPT into the Basic Settings form.

We’re using “Services” as the plural name and “Service” as the singular name. The slug will be generated automatically, and unless you prefer to change it you can leave that automatically set. In our case the slug is “services” which means posts will be published at https://goldhat.ca/services/[SERVICE-PERMALINK].

 

 


Meta Box CPT advanced settings

Meta Box CPT advanced settings

Step 2 Set Advanced Post Type Settings

Under advanced settings you can edit the labels, set an icon for your Custom Post Type and configure how the CPT will be handled by WordPress. There are a lot of options, the Meta Box Custom Post Type plugin provides defaults that will work well in most use cases. If you are want to learn more about the options available one of the best resources is the register_post_type() documentation at WordPress.org. What Meta Box CPT plugin does is organize these settings and then call the register_post_type() function, and most of the settings for that function seem to be represented in the MB Custom Post Types interface.

For our services CPT we set a custom icon, the “hammer” as a way to make this post type stand out in the WP admin menu.

After this step I like to save the custom post type so I don’t lose my work if for some reason the window is closed. The CPT is now published, but we have a few more steps left in setting up it up.


CPT Supports Settings

CPT Supports Settings

Step 3 Set the Custom Post Type Supports & Taxonomy Settings

On the right side of the post type editor screen Meta Box Custom Post Types provides the “Supports” meta box. The defaults are title, editor and thumbnail. We’ve added excerpt, comments and author support for Services.

Note that “thumbnail” means featured image, and this is the way WordPress describes it at the development level although in practice most content managers would be familiar with a post having a featured image. 

Meta Box Custom Post Types can also be used to build custom taxonomies, which are then applied to custom post types. Right now we’re just checking off the default Category and Tag used by posts (not shown in screenshot). We may build custom taxonomies for this post type later, but if so it’s easy enough to revisit the post type editor and attach them.


Caffeinate! Save your post type and grab a java it’s time to recaffeinate. In the next steps we’ll be making test posts and trying out our new post type.


Test post custom post type

Adding a test post with the new custom post type

Step 4 Adding test posts to our custom post type

Make at least 3 test posts so you can see how things look in the archive.

Our services list is now coming together with our test posts in place. Check the list of posts, and visit the single post (click view link for the post) to make sure permalinks are working correctly.

Meta Box custom post types list

Services list after adding test posts.

 

 

 

 

 

 


 

How to enable Meta Box free extensions when Meta Box is embedded in a WordPress plugin or theme

The situation is this, we’ve embedded Meta Box (core) into our plugin Clay Framework (which powers this site, goldhat.ca). Everything works fine, and we added the Meta Box AIO (collection of all premium Meta Box extensions). Now so far AIO was just activated as a plugin, not embedded into Clay Framework. And all the premium extensions seem to work fine, though there are so many we haven’t had a chance to test them all yet! Where we ran into a bit of a snag was when we installed Meta Box Custom Post Types. This post types extension is not bundled into Meta Box AIO because it’s free (only premium Meta Box extensions are found in Meta Box AIO). And when we activated it, a notice appeared that said “Meta Box needs to be installed”.

Digging into the code we saw that Meta Box Custom Post Types plugin uses the “init” action to check if Meta Box is installed. The priority on that check is 0, which doesn’t leave a lot of room to integrate Meta Box before it’s called. We were able to solve that using -1 as the priority in our init hook call where we integrate Meta Box. I wasn’t sure if that would work because I didn’t know if “minus values” are supported as hook priorities, but apparently they are! Is it good practice though, could it cause some complications? I’m not sure, leave a comment if you know the answer to that.

For now we’ll continue setting -1 as our init priority to integrate Meta Box, and that solved the problem for the Meta Box Custom Post Types plugin. It now loads properly and seems to be functioning normally.

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.

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

 

7 reasons why hiring offshore based developers is a bad idea

Over the 15-years I’ve spent as a PHP programmer I’ve seen the rise of offshore development, the fall in average cost of development, and more recently the resurgence of on-shore development as customers realize they’re sacrificing business opportunity when they hire the cheapest developer they can find. Today Upwork, the largest freelancer site is dominated by Indian, as well as Pakistan based developers. There is no doubt that this region serves a definite need in the marketplace. Just look at some of the jobs posted at Upwork. Build me a WooCommerce website with a custom theme for $200 reads one. Build me a massive social network like Facebook for $120 reads another. One wonders what happens on these projects? Does the budget increase? Does the project fail? I can only gauge from what I see, which is the work provided by new customers whose previous developers were from India. Based on that experience of being “the guy that takes over” the site/plugin, here are 7 reasons why hiring Indian based developers is a bad idea.

  1. Many offshore developers fail to respect even the most basic development principles. The most common example is the “hacking” or editing of base themes and plugins. Nearly every site we take over from an Indian based developer has edits to plugins. The result is those plugins cannot be updated. This is a problem worthy of it’s own blog post. If you’re unsure if your site already has these kind of edits, ask your developer about it. While in some cases editing a plugin might be necessary, it should be a last resort. WordPress has a hook system, and is a modular framework that is designed to enable custom functionality and new features without editing existing plugins and themes. On the theme layer, a child theme should always be used rather than editing the base theme for instance.
  2. Errors are ignored and not fixed. Often sites built in India have hidden errors, or functionality bugs that have not been detected. Thorough testing reveals these errors, as does turning error reporting on. Because error reporting is usually turned off for live websites, as a site owner you might never see these errors. While they don’t break your site (warnings) it is possible data isn’t being stored correctly, notices are not being sent to customers, form submissions are not being processed, and a host of other actions are not happening. At the very least these errors indicate a lack of quality in the work, and symptomatic of larger problems hiding under the surface.
  3. Are you really saving money? An all too common story of the website development project sent offshore to an Indian developer is that part-way through the project the scope changes, more money is demanded, and the final cost is much higher than expected. In fairness scope management is a factor for developers everywhere in the world, but Indian developers have a reputation for holding their customers hostage refusing to deliver work or finish projects if their demands for more money are not met. This cuts into the savings you might perceive from the initial quote. A much costlier problem is that if you eventually realize you’re not getting good work from an Indian developer, you might bring your development projects back onshore. But is the foundation of your WordPress website solid? We’ve seen sites built in India that require major fixes before any new work can be performed, and the costs of this repair eliminate or deeply cut into any savings.
  4. Schedules are often missed by Indian-based developers. Having hired over 30 India based freelance developers myself before I stopped trying to work with developers from India, at least half of them stopped a project partway due to a festival. Now to be clear these were 30 different developers working on different projects at different times of the year over a decade. Yet, midway through the projects, it was suddenly festival time. Either India has a lot of national holidays, some that last for weeks, or developers use these kind of excuses to buy them time before they are fired when their unable to meet a deadline.
  5. Lack of commitment to project completion is one of the scariest factors in hiring offshore developers. In the west we are used to professionals feeling a sense of obligation to finish what they start, and unless there is a significant reason such as missed payments or serious disagreement over the terms, we expect once we’ve hired a freelancer that they will finish the job barring something catastrophic happening. Perhaps it’s a cultural difference, or just a side effect of trying to work on a massive volume of projects, but many offshore-based developers have been known to end a project over trivial disputes, or simply say “this project is too difficult we cannot finish”. In those situations there is often an unapologetic attitude, the offshore developer simply says the project is over, often refuses to refund any pre-payment, and will argue that even something as basic as sending over partially completed work is not something they need to do. When things go bad in India for example, they go really bad, and there is little recourse in these situations. Don’t be under the false impression that a freelancer website such as Upwork is going to resolve these issues, though they do provide some protection for buyers it’s often not enough to offset the damage done when a project fails.
  6. There are affordable developers in some parts of the world with vastly superior track records. Many buyers today feel they have to offshore somewhere, they simply cannot put together a budget high enough to hire an American or European developer. And the availability, and willingness to work on certain projects is also a concern with on-shore developers. So where can you offshore more safely than India? Personally I’ve had the most success with Ukrainian developers, and other Eastern European locations such as Serbia. The work ethic and attitude of developers there is much more similar to Western Europe and North America. The communication level is also better, with many Eastern European’s able to both write and speak fluently. You will certainly pay more for developers from these regions, but there is still substantial cost-savings compared to on-shore development.
  7. Offshore developers are rarely able to provide consultation and make development choices, which becomes a big burden on project managers and site owners. A typical situation early in a project is the Indian developers asks what to do. You might (should!) have a written project plan, requirements document, perhaps visual designs. You provide these to the developer and offer to clarify them. More often than not they will come back to you and say okay I got your docs, now can you tell me what to do? Whether it’s a communication issue, or lack of experience, Indian developers are famous for not being able to identify the tasks required to turn requirements into deliverables. If you want something done, you literally have to ask for each step. This leads to micro-management. It’s also dangerous for project scope, because now you’re essentially looking over the developer’s shoulder and telling them which steps to take on a one-by-one basis. If things go wrong and the requirements are not met, the developer can simply say “well I did what you told me to do, sorry it didn’t work out”. That’s why you should always try to ascertain that a developer is results-focused, that they can convert requirements to working solutions, and they can do this without hand-holding.

I know I might take some flak from those who would say this is generalizing about a large number of developers from a specific region who vary tremendously. There is no doubt that there are many talented developers in India and other major offshore regions. But is it 1%, or 5%, or 10%? Who knows, but I can say that in dozens of attempts, I rarely found an Indian based developer that would be considered equal in merit to the average hire from the Ukraine, as an example. And in cases where an Indian based developer is a proven professional, most of them are not available for freelance work as they either have high paying jobs, their own firms, or work on a select number of big projects. Like any other market, top developers in India earn double or triple that of their counterparts, so don’t expect the truly qualified to be bidding on what is effectively a $3/hour job.

Let me close with a tip when hiring WordPress plugin developers from any part of the world. Always ask to see a plugin they built, they should be able to share at least 1 that is publicly available either hosted at WordPress.org in the plugins directory or for sale on a site such as CodeCanyon. Verify they actually have plugin experience, rather than just being site builders. Going back to Indian based developers, I’ve rarely seen a WordPress plugin that was built in India. They do certainly exist, but rarely do they rank in the top options in any of the plugin categories. And of all the Indian based developers that routinely respond to our job posts, out of around 200 we asked to send us proof of plugin development experience, the number that were able to do that was 0.

Epic WP Guide to Custom Post Type Permissions with Map Meta Caps

Setting up custom capabilities (permissions settings) for custom post types. It’s a topic that has frustrated many developers from novice all the way to expert. It’s the type of technical topic that tends to require more than a surface level understanding. Following a tutorial often isn’t enough to grasp it in a way that allows you to fully unleash the power and flexibility of the WP capabilities system. The good news is this Epic WP Guide from GoldHat Group is going to give you an in-depth exploration of how to use custom capabilities with CPT’s, how to use the map_meta_caps filter, and what to expect from the WP admin when you take various approaches to capability mapping.

Because this probably isn’t your first stop in making sense of how to use capabilities for CPT’s let’s start with an overview of the process before we begin to delve into the details. This epic guide is only going to involve 3 steps. That’s the good news. The bad news is there is enough complexity that we’ll be looping over these 3 steps a total of 3 times each in order to help your brain assimilate the information.

  1. How to use the capabilities settings (“capability_type”, “capabilities”, “map_meta_cap”) when registering CPT’s.
  2. Using the map_meta_cap filter to map primitive capabilities to meta capabilities.
  3. How to assign capabilities to roles and/or users.

CPT Capabilities Settings

When you setup your CPT there are 3 settings we care about that will affect how capabilities are mapped. These are “capability_type”, “capabilities”, “map_meta_cap”.

A common mistake is using capability_type and capabilities. This appears to cause conflicts, however we don’t have an authorized statement from any official docs saying don’t use them together. It’s just been our experience that using either setting alone works as intended, whereas using “capability_type” AND “capabilities” appears to cause either a problem with mapping capabilities which we handle later with the map_meta_cap OR it simple interferes with how permissions are applied. Whatever the case we advise using one or the other, not both. The “map_meta_cap” defaults to false, it should be set to true only when using “capabilities”.

To summarize you have 2 major configuration options using the 3 capabilities settings:

  1. Use capability_type (which defaults to string “post”). We call this a “semi-custom” approach, because WP will automatically create custom capabilities and map them for you. You won’t control the naming, that’s done by convention, and you won’t have control over the exact mapping that part will be done in a standard way. However before disregarding this approach, consider that you will still have extensive options to impose logic and affect permission utilizing the map_meta_cap filter. Ask yourself do I need more, and if so why? The more you understand how custom mapping of capabilities works, the more appropriately you’ll be able to make this decision. With this approach you DO NOT pass the “capabilities” or “map_meta_cap”. If you have a situation where these are being automatically set – you would need to pass an empty array for capabilities and false for map_meta_cap. These are both the defaults.
  2. Use custom capability mapping. This is the “fully-custom” approach, gives the maximum control. It allows you to pass an array of your custom capabilities, and to map them to the post capabilities which we’ll discuss in detail later. Using this approach allows you to control naming and to map multiple default capabilities to a single custom capability that you define. When using this approach DO NOT pass “capability_type”. You must set the “map_meta_cap” to true for this to work, and you’ll need to use the map_meta_cap filter.

Using Capabilities Settings in CPT’s

This is not a beginners guide to WP permissions so if you’re entirely new to capabilities and never used functions like user_can() we recommend brushing up on those basics. What we will cover here is how capabilities are mapped in relation to custom post types.

There are 2 types of capabilities: meta and primitive. Imagine meta capabilities as being major highways, routes or freeways. Let’s say you’re in a big city and you have 3 of these major highways, the one is called highway 5 another route 9, and finally we have route 17. If you want to head east, everybody knows, take the 9. You could be going to vastly different places, but you start with this major roadway. Same idea with capabilities. Always start by thinking about the meta capabilities, which will lead you to the primitives. You’ll see a lot of texts explaining these things in reverse, talking in terms of mapping primitives to meta capabilities. And it’s true, as you’ll see later when we work with the map_meta_caps filter that yes we do end up spending more time focused on the primitives. But that’s just like when driving someplace, you spend most of your time navigating the exits and smaller turns to find a place. You’ll never get even close if you don’t the right highway!

There are only 3 meta capabilities. Memorize them: edit, delete, read. For posts the actual name of them always ends with “post” so we have the list shown below:

  • edit_post
  • delete_post
  • read_post

Meta capabilities are not mapped to roles, whereas primitive capabilities are. The relationships here between the role, the primitive capability and the meta capability can be understood as follows:

  • Imagine you have a jug of water and a cup. As owner of the jug and the cup you can do whatever you want with either one, including pour the water in the cup, pick up the cup, drink from the cup and finally smash the cup on the ground.
  • Your child, can also pick up the cup and drink but cannot fill the cup or smash the cup!
  • Your dog isn’t allowed anywhere near the cup! He has full permissions only for the dish.
  • Our roles are owner/child/dog. The PRIMITIVE capabilities are pickup_cup, drink, fill_cup, smash_cup. The META capabilities are use_cup, destroy_cup.
  • When any of our users in this scenario try to pickup the cup, the question is asked “can they use the cup”? The question at this point is in the context of the meta capability, use_cup. We don’t directly get the answer, instead use_cup will reference which primitive capability(s) are required. The logic involved will take into account the user specific context, such as whether the user is the owner of the cup, or whether the cup has already been smashed!

To see the full list of capabilities available to map for a custom post type it’s worth reading the section at https://codex.wordpress.org/Function_Reference/register_post_type under the heading capability_type and capabilities. As mentioned earlier using the capability_type setting enables a “semi-custom” approach to mapping capabilities. As shown in the docs example, if the custom post type was “book”, setting capability_type to “book” would result in the capabilities shown below:

Now let’s look at an example of the fully custom capability mapping that is more commonly used when building plugins. When we want full control, and perhaps a different naming convention. This is form our QuizMaster plugin, notice that we prefix all our capabilities with “quizmaster_” which keeps them consistent with the naming conventions used in other areas of the plugin.

You’ll notice our custom definition of capabilities includes primitive capabilities such as “edit_published_posts” that are not automatically mapped when using the capability_type automatic mapping. This is because WP core generally does not use these in the WP admin. These other capabilities however can be very useful in providing more fine-grained control later when we define permissions logic in the map_meta_caps filter.

Mapping Capabilities with the Map_Meta_Caps Filter

The most common place where developers go wrong is in failing to utilize the map_meta_caps filter when they’ve set map_meta_cap to true in their CPT definition. If you’ve set map_meta_cap to true, you must use the map_meta_caps filter because generally speaking, all access will be denied until you return capabilities from this filter. You might think not using the filter would open permissions up, but quite the opposite in what may be a safeguard, no filter return means no permissions granted. That’s not to suggest that the purpose of map_meta_caps filter is to determine if permission is granted. It’s job is much more limited. It merely answers the question given the current context including the meta capability, the post, the user, what primitive capability would the user need to do what their trying to do?

 

http://wordpress.stackexchange.com/questions/155644/whats-the-difference-between-role-and-meta-capabilities-when-to-use-map-meta-c/215389

 

QuizMaster Plugin Project

The first time we worked with WP Pro Quiz was when DatGenius, a dental training website, approached us about a project. They wanted to show the completed quiz results students were taking on their WP Pro Quiz site. This feature which sounds like a given in any quiz system, was not available or even easily supported by WP Pro Quiz. This was the start of what today is an addon plugin for WP Pro Quiz, called WP Pro Quiz Completed.

It was during the “Completed” addon project that I first started thinking about forking the WP Pro Quiz project. There were a number of reasons. I’d seen this style of development before. Conventions ignored, unusual features, limited documentation. It’s impossible to write about this without being critical of the original developer of WP Pro Quiz. So I’ll preface this by saying it’s a major accomplish to build something as sophisticated as a quiz system, and to attract over 20,000 active users, according to the last WP directory stats. Now let’s it real and talk about some of the reasons for forking WP Pro Quiz versus contributing to it and aiming to enhance it as an open source project:

  1. Lack of responsiveness from developer. Every project needs a leader, and if the leader is absent it’s hard to move it forward even with pushes from people who offer help. When pushed code, and suggestions get largely ignored, that’s a big problem. There are countless complaints about WP Pro Quiz support being slow, and when responses do come they are not always as helpful as people would like. Providing support, and leading development, is a tough ask of any development team, let alone a lone developer, but the case is that a user base of 20,000 is going to have questions. Especially if…
  2. The documentation is limited or non-existent. Most aspects of WP Quiz are not documented, if we rated it like translation on a basis of completion we might say it’s currently 2% documented. Consider how this compounds the support issues, because if you have good docs you can minimize support by referring users to docs and save time leading to faster responses.
  3. Extending WP Pro Quiz is moderately difficult. Giving credit where it’s due the MVC approach in WP Pro Quiz makes it’s objects reasonably extendable. Yet for such a significant plugin, it only has about 3 actions and 5 filters, none documented. And more pressing is the widespread use of Javascript in places where PHP or a mix of PHP callbacks from AJAX calls would have made the system easier to extend. Combined with the lack of docs, trying to build an extension to WP Pro Quiz is a “you’re on your own pal” kind of experience. And it doesn’t need to be that way, the plugin is a solid foundation of functionality and with focus on making it extendable it could be possible to develop great hooks throughout.
  4. Language issues. Again we have to give credit to the translation work that makes WP Pro Quiz very accessible. But from an English-version perspective, and a developers perspective, the plugin is littered with English-errors, and very inconsistent use of titles. Helper text is oddly worded and often instructions for options don’t mean what you might initially expect based on the way it’s written.

I could carry on raising other smaller factors but I think you get the point. The distance between where WP Pro Quiz is, and what we would call a good place for a popular plugin is significant. After the release of WP Pro Quiz Completed as an addon, I reached out to the developer of WP Pro Quiz twice asking about opportunities to cooperate in building an addon system, and joint-marketing. There was no response.

Our path forward now with development is a dual-track approach. We’ll be continuing to build addon’s for WP Pro Quiz Completed and offering those in our store alongside WP Pro Quiz Completed. At the same time we’ve created QuizMaster, initially a fork of WP Pro Quiz. As we develop this it will remain fully open source, and after we add value to it we’ll aim to have it included in the WP Directory. Until that time it’s hosted on GitHub at https://github.com/goldhat/QuizMaster.

  • As QuizMaster is developed we’ll be creating a QuizMaster Pro version. This will be an enhanced feature version of QuizMaster with support for some of the features often requested now from the WP Pro Quiz project.
  • We recognize that quiz systems are used in a variety of ways, and the base plugin itself cannot (and should not) try to serve all. Instead it should be extendable so that developers can easily add custom plugins that tie into hooks the quiz plugin provides. QuizMaster will be highly extendable, with great docs and tutorials. We view it as a platform for quiz management.

Where can we improve QuizMaster and add value compared to the WP Pro Quiz plugin?

Before we add any functionality to QuizMaster we’ll be starting with a revamp of the foundation of the plugin and aiming to bring docs up to a good standard.

  1. Document existing features.
  2. Add hooks and filters to existing codebase.
  3. Improve the UX in key areas such as “Add Quiz” form, adding tabs/accordion or other approach to organizing options and making the page less cluttered and daunting to users.
  4. Fix existing codebase issues reported on WP Pro Quiz issues pages.
  5. Look into data storage and see if there is a way to optimize it, or reduce use of custom tables.
  6. Develop a migration path, preferably an automated migrate from WP Pro Quiz to QuizMaster.

Do you want to contribute to this initiative as a developer, or run a WP Pro Quiz powered site and want to share your input? Your comments below are welcomed! Thanks for reading about QuizMaster.

WP Pro Quiz Completed Plugin

We have just finished version 1.0 of a new plugin named WP Pro Quiz Completed. This is an addon for the WP Pro Quiz plugin that is quite popular as a stand-alone quizzing system.

WP Pro Quiz Completed provides users with a list of their completed quizzes, and the ability to review all of the answers. Surely that must be part of the core plugin you say? Well it isn’t, normally students can only review quizzes immediately after they take the quiz. Admins can see statistics in the WP admin, so that information is stored. We have just taken the available statistics and made them available as a shortcode so they can be added to any page.

Visit https://goldhat.ca/product/wp-pro-quiz-completed/ to purchase and download the plugin which is available for $25.

Plugin docs are available at https://goldhat.ca/wp-pro-quiz-completed-docs/

Websites need documentation too

It’s not just software that needs documentation. As the line between “app” and “site” blur, every site is an app and has software running. Much of it is critical to the operation of the site. Other parts are small plugins/modules, scripts that require minimum development beyond the install. Still, all these parts are potential failure points.

Website Documentation Saves Debugging Time

As developers we want to minimize the debugging process that happens if a bug appears on a site. Let’s say you upgrade a plugin and some custom feature breaks on your website. The more details we have about the feature, the faster we can find the source of the problem. Just realizing a feature is “custom built” on a website is important, again something that would be noted in any documentation. Often if we take over management of a site, it’s not immediately clear what is made from contributed plugins versus functionality altered via theme code, or custom plugins.

Any site that has custom plugins definitely should have documentation along with those plugins. A plugin should be thought of as a piece of software.

Finding Time and Money to Write Website Documentation

Of course all the good intentions about documentation don’t help if you don’t have the budget or the time to write documentation on a project. Often project limitations make documentation difficult. Still, we feel developers should always remind clients that documentation will save them time and money in the longer-term. As well as making the site more manageable in the short-term.