About two weeks ago I released version 2.0.0 of my User Shortcodes Plus plugin on the WordPress.org repository. This new version contains a couple of new user shortcodes, the addition of a custom tinyMCE button, and an architectural overhaul of the codebase.
A few weeks ago Kevin and I discussed me taking one day a week as a day to focus primarily on new development. I split my time between new development, bug fixes, and high level support, so the schedule gets crowded. A day to focus on new development without distraction seemed like a good way to assure that we are moving forward with product development. There will always be more bug fixes (maybe not, in theory, but life is not theory), so I personally need to set aside time dedicated to certain tasks.
Ninja Forms offers two premium extensions for creating posts on form submission. Front End Posting and Front End Editor both contain this functionality (note: The two extensions cannot be activated at the same time, as Front End Editor contains Front End Posting).
When a post is created from a submission, the ID of that created post is saved as a form setting in the `$ninja_forms_processing` global variable. This value is available during the ninja_forms_post_processing hook:
I recently spent some time poking around the Runway Framework from Parallelus, a “solution for making WordPress themes, fast!” What first caught my attention was the theme export feature, which allows theme developers to export “self-contained standalone versions, independent of the Runway framework.” This makes distribution and deployment much less complex compared to the typical framework/child-theme model.
Ninja Forms uses the jQuery UI Datepicker to add datepicker fields to forms. jQuery is bundled with WordPress, so the jQuery UI Datepicker is an easy choice. However, the datepicker defaults still need to be localized. In the short term, I have put together a plugin that helps to localize the datepicker defaults for Ninja Forms. Note: The plugin currently has limited language support based on immediate customer needs, but can be easily updated as those needs change.
This is the moment of truth for my first major feature of the Ninja Forms core product. Today, the team at the WP Ninjas released version 2.9.12 of Ninja Forms, which introduces the Upgrade Handler. The importance of this update is further highlighted by the milestone of 200,000+ active installs for the free core plugin. As I mentioned in a previous post, Responsible Plugin Upgrades, upgrades don’t run just once on a development environment, but rather on each customer’s website. Again, for the sake of emphasis, that is 200,000+ websites, and a lot that can go wrong.
When your plugin is running
100,000 200,000+ active installs every change that you make is a big deal. For example, when you need to alter the structure of the database you aren’t changing it once, you are changing it 100,000 200,000+ times. Every install needs to make the change, not just your isolated development environment. This reality can be very daunting, however, there are steps that you can take to make the process of change painless an exceptional experience.