It's time to ditch FAQ section in themes - Expandable FAQ - commercial-friendly plugin for theme authors (FREE)

You don’t need to integrate FAQ into your theme anymore - I made a FAQ plugin for you, dear ThemeForest author. I’m so upset keep seeing that Theme Authors absolutely break the idea of what WordPress theme is (even some most-selling theme authors at “ThemeForest” is absolutely failing at this point), and what is the plugin, while half on “ThemeForest.net” should be named as “BundleForest.net” as that are not themes. And it is not just about the fact, that site should not break if you change the theme that does not support your theme FAQ’s, but more important is the CONSISTENCY (you will need to update theme less frequently) and STABILITY (your theme changes won’t impact existing sites, so your customers won’t be scared to update the theme anymore thinking that their child theme will break - currently I’m super scared to do that with many of top-selling themes on ThemeForest, as they change with almost every bigger update any previous child themes breaks totally).


GitHub Repository (for those, who want to contribute via “Pull Requests”):

The one of the main reason why many authors did not included “FAQ” plugin into their package was the fact that 99% of plugins on w.org runs on GPLv2 licenses meaning that it is pretty much forbidden with GPLv2 plugins to bundle them to commercial bundle packages (that is the correct term of what 75% of ThemeForest.net is about - it is a resource of bundles, not a themes-only), and in that case you would be required to open-source all your ThemeForest bundle pack.
So to finally solve this problem for every commercial-theme author I created Expandable FAQ plugin based on most-secure and most-scalable S.O.L.I.D. MVC coding standard with a MIT license - meaning that you can include Expandable FAQ plugin into your commercial theme package without any need to open-source whole package (as long as the copyright lines in file header part stays in-touched) .

Over 90% of ThemeForest authors bundle plugins as required or recommended into themes via TGMPA ( http://tgmpluginactivation.com/ ), which is bad way to do in 2 of 3 times. The main reason is that you then creating overhead code that will always stay inside theme’s folder even if that plugin will never be used (so TGMPA actually should be used only if that is a kernel plugin that is a must for your theme to work - that should become very rare situation after PROJECT GUTTENBERG release).
So my advise is to go with alternative - include this plugin into /Optional Plugins/ folder of your ThemeForest’s full package, and write about the optional plugin installation in documentation if your item as bundled package has a demo website with FAQ part on it.

About the plugin

First - differently than any other similar plugin, this plugin is based on MIT license, which is a holly-grail for premium theme authors on i.e. ThemeForest or similar marketplaces.
Differently to standard GPLv2 license you are not required to open-source your theme and you CAN include this plugin into your premium websites bundle packs.
I do say here bundle packs, because you should never have an F.A.Q. to be a part of your theme, because that would be a bad idea - you need to leave your customers a flexibility for the future scale:
What if your customers will decide later go with some kind of fancy knowledge base system like in Change.org /help/ part or Envato.com Support part - if your customer will grow that big,
he won’t need to have F.A.Q. plugin anymore on their website, he will want to replace it with that fancy knowledge base system.
So my advise is to include this plugin in your bundle pack’s /Optional Plugins/ folder, so that you can tell about in the installation instructions, but make it fully independent from your theme.

Second - this plugin is fully MVC + Templates based. This means that it’s code is not related at all to it’s UI,
and that allows you easily to override it’s UI templates and Assets (CSS, JS, Images) by your theme very easily (and there is detailed step-by-step instructions given how to do that).
This means that you making a theme to be what the theme has to be - a UI part of your website, nothing more.

Third - it is much more secure than any other plugin’s on the market. It is based on top-end S.O.L.I.D. coding principle with input data validation with data-patterns, output escaping.

Fourth - this plugin is scalable – it’s source code is fully object-oriented, clean & logical, based on MVC architectural pattern with templates engine, compliant with strict PSR-2 coding standard and PSR-4 autoloaders, and easy to understand how to add new features on your own.

Fifth - this plugin works well with big databases & high-traffic websites – it is created on optimal BCNF database structure and was tested on live website with 1M customers database and 500,000 active daily views.

Sixth - it does support official WordPress multisite as network-enabled plugin, as well as it does have support WPML string translation.
At this point, if you need more than one language, I’d strongly advise to go with official WordPress multisite setup, because it is free, it is official (so you will never need to worry about the future support), and, most important - WordPress multisite is much more suitable for websites that needs to scale. You don’t want to have that additional translation bottle-neck code layer to be processed via database.

Seventh - it has nice user experience - it’s has a default design, it does allow you to have more than one F.A.Q. item open at the same time - so it don’t have that annoying accordion feature,

But the most important is that this plugin is and always be ads-free. I personally really hate these freemium, ads-full or tracking plugins which makes majority
of the plugins on w.org plugins directly (and, actually, many of premium marketplaces). So this is the key features we always maintain:

  1. Never track your data (nor even by putting some kind of GDPR-compliance agreement checkbox, like Error Log Monitor plugin),
  2. Never make it pseudo-ads-full (even such a big plugins like WooCommerce or Contact Form 7 has nearly 80% of their home screen or 20% of their main buttons about how to install \ buy other plugins
  • this is a really ugly behavior of pushing-more and going to Facebook-like business, where you get like drug-addicted to company products).

So I wanted to help all these developers to save their time, and I’m releasing this plugin for you to simplify your work. And I’m releasing it under MIT license, which allows you to use this plugin your website bundle without any restrictions for both - free and commercial use.

Plus - I’m giving a promise to you, that this plugin is and will always be 100% free, without any ads, ‘Subscribe’, ‘Follow us’, ‘Check our page’, ‘Get Pro Version’ or similar links.

Finally - the code is poetry - the better is the web, the happier is the world.


Live Demo

Expandable FAQ (Live Demo)


Screenshots






So I’ve releases S.O.L.I.D. MVC Engine, Version 6 patch with Semantic Versioning support (Semver 2.0.0, read more at https://semver.org/ ) that runs behind the Expandable FAQ. The Semver pretty much is unavoidable thing if we want to control the updates and rollback to not get to so-called “DEPENDENCY-HELL”.

Why Use Semantic Versioning?

This is not a new or revolutionary idea. In fact, you probably do something close to this already. The problem is that “close” isn’t good enough. Without compliance to some sort of formal specification, version numbers are essentially useless for dependency management. By giving a name and clear definition to the above ideas, it becomes easy to communicate your intentions to the users of your software. Once these intentions are clear, flexible (but not too flexible) dependency specifications can finally be made.

A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past. Consider a library called “Firetruck.” It requires a Semantically Versioned package named “Ladder.” At the time that Firetruck is created, Ladder is at version 3.1.0. Since Firetruck uses some functionality that was first introduced in 3.1.0, you can safely specify the Ladder dependency as greater than or equal to 3.1.0 but less than 4.0.0. Now, when Ladder version 3.1.1 and 3.2.0 become available, you can release them to your package management system and know that they will be compatible with existing dependent software.

As a responsible developer you will, of course, want to verify that any package upgrades function as advertised. The real world is a messy place; there’s nothing we can do about that but be vigilant. What you can do is let Semantic Versioning provide you with a sane way to release and upgrade packages without having to roll new versions of dependent packages, saving you time and hassle.

If all of this sounds desirable, all you need to do to start using Semantic Versioning is to declare that you are doing so and then follow the rules. Link to this website from your README so others know the rules and can benefit from them.

Minor 6.1.0 update was released to the Expandable FAQ plugin, including the S.O.L.I.D. MVC core as well, that has all crucial changes for theme developers to ensure that we are fully up to coding standards, including major redesign of outputting, meaning now everything is really late-escaped (escaped in templates or HTML render blocks), and no more as model parameters or via explicit ‘print’ functions. As well as solved issue with Multisite setup with a special workaround until WordPress core bug #36406 will be fixed.

Changelog:

  • NumberDropdown bug fixed in StaticFormatter.
  • All table classes are now marked as final.
  • For ‘getDataFromDatabaseById’ used array($paramColumns) with getValidSelect instead of paramColumn.
  • ‘esc_html’, and ‘esc_br_html’ are now used everywhere.
  • Import demo and global settings are now fully translated.
  • Added support for ‘style’ [0-9]+ shortcode parameter.
  • Added a note for data population in status page.
  • Replaced ‘getPluginJS_ClassPrefix’ & ‘getPluginJS_VariablePrefix’ with native call.
  • ‘StaticCookie’ and ‘StaticSession’ caching model classes improved.
  • Fixed issue with network installing when multisite is enabled in WordPress, as well as created workaround until WordPress core bug #36406 will be fixed (read more at https://core.trac.wordpress.org/ticket/36406).
  • PHP 5.6 backwards compatibility added.

6.1.5 minor patch was released. It does fixes all know issues, and bugs as of today, as well as it more clearly addressed licensing information, about MIT and GPL licensing different, and what is the biggest benefits of writing a plugin for SolidMVC micro-framework, instead of calling plain WordPress functions - meaning that all your plugin’s code in SolidMVC case would be intensivelly-dependent on MIT open-sourced SolidMVC code, and not WordPress core’s GPL code.
Read more about licensing here:

GPL vs MIT licensing differences, and why SolidMVC is MIT-licensed

CHANGELOG:

6.1.5 Patch

  • Abbreviation functions support added as es(..), at(..), abh(..), eh(), ej(), et() for use mostly in templates, but they can also be used in models, if you use observer models that may be generating and returning to controller whole HTML blocks. Also these functions may be valuable for developers, that wants to have their HTML templates (or PHP-enhanced templates) be fully based only on SolidMVC (MIT-licensed), and not WordPress (GPL-licensed), as in this case your templates would be intensively calling only the MIT-licensed SolidMVC micro-framework’s functions. Additionally, this allows you to write a shorter code for your templates, which is easier to read for your designers.
  • escBrHTML(…) support added for language interface.
  • Minor documentation and code tune-up.

6.1.4 Patch

  • Small tune-up, gallery support added to configuration.
  • [SITE_URL] BBCode support added for install/import.

6.1.3 Patch

  • Redirection bug fixed for updating the plugin from plugins page.
  • Left-over CSS classes and PHP code removed.
  • Small minor label bug fixed and small renaming done.

6.1.2 Patch

  • Fixed wrong admin JS filename issue.
  • Improved variable naming to FAQ_, where was still missing.
  • Other small naming improvements.
  • Missing translations added for manuals, demos and FAQ tabs.

6.1.1 Patch

  • Escaping added, when necessary to ‘_doing_it_wrong’ calls.
  • Network-updating now can be done for 6.1.1 successfully.
  • Some additional minor improvements / patches.