The last week or so, I have been busy updating my own internal developments, tweaking settings in my MainWP dashboard and the tools I use in MainWP. This post will be about that, and hopefully it gives you some ideas for your own sites.
MainWP User / Elevation Checking
I made some much-needed tweaks to this snippet so I can run it on a site. It will check for Admin / Elevated admin privileges within the database and access to information users have, i.e if a subscriber has manage options as an ability.
It can now check more; it’s more robust and has the ability to not only return the response to MainWP snippets it can also email reports for all clear to a required email address. I needed to use this this week when I introduced an update in my own update server that turned out to be potentially compromised. Thankfully, it never got seeded, but the site that populates my own repo did get the poisoned download and uploaded it; it never ran, and no other site displayed it.
MainWP Ninja Updater Bulk Settings
Until the incident above, this has worked for me on a site by site bases it allows me to update a site and add/remove plugins from my own update repo. For bulk, I’ve been using a script in MainWP snippets, which still works, and there is some recipient code in Ninja Updater to run on the site and do the work. While cleaning up the pipeline for the above, I was concerned about how slow this was; I had to run it several times to reach the desired outcome.
So I spent some time this week adding two new bulk pages to this intergration that means my utility plugin now works on an individual site but also entirely in bulk. I can add/remove snippets, delete transients, force an update check, add/remove a plugin or theme to update from my repo, all in bulk. What is extra special is that it takes snapshots before we update, meaning once I have pulled an update from my repo, I can put it back to doing it directly to the supplier’s site as it was before. This is brilliant when I need to deliver a one-off hotfix to their code.
TDU Bulk Settings
I replicated the bulk updates and snapshots to my commercial clients’ updater that allows me to do the same without the snippet loading, etc. This means I can temporarily make a customer’s site grab their update from my repo and revert for the same hotfix feature.
I even used this this week after adding it to live to update a plugin’s licence key across my client sites. Due to a licence issue a plugin supplier has issued me a new key. I was able to remotely tell every site to pull updates from my repo for this plugin, open the plugin file, and change it to version XX.XX.XX.1. In that version, I modified the code to deactivate, add the key to the database in a similar fashion to my AutomaticCSS licence automation, and then activate.
All 20 sites running this plugin had the same items run: Change to pull from my repo > I pushed the updated version and code after testing to my repo, increasing the version by .1 (Not used by the plugin provider) > Deleted Transients and forced a refresh (All from MainWP) >>> 20 updates >>> pushed updated >>> Checked plugin site (20 activations after about 15 mins) >> stopped pulling from my repo (Success).
About two days later, the first update with the new licence key was successfully delivered to every site; I didn’t enter a single dashboard to do this.
What does this all mean?
In theory now, when I know there is a compromised version of a plugin, and I have the fix available, I can now force a refresh of the available version from WordPress and force the sites to update to the latest version. I tested this again this afternoon with the new FlowMattic release; it was flawless. Within 2 mins of its release, all sites were on the latest version.
While none of this is new, I’ve had script versions of these tools for a while- the new part for me here is that, after testing, I have an easy GUI way to do the same, and it means it’s quicker and more robust, as I get detailed logs too and can revert automatically rather than having to write another snippet.
What I’ve been testing
I’ve had some more fun with Paymentforms.io this week setting up forms and seeing how I can use this for processing payments. I think once they release native block integration with CSS / JS capabilities, this could become very useful to me for remotely hosted checkouts for tools.
I also had the chance to check out the hosted version of CraftForms; this is a solid setup and good for those users who really don’t want to host their own WordPress secure backend. I still really like Craftforms for static-site form processing, and I have a dedicated install handling this for my installations. It also powers my url2drive.com project. I will definitely find projects worthy of the hosted version, though
Core-forms creator asked me if I’d be interested in trying their Flowmattic integration, and I did and gave some feedback on how this should work. I am really chuffed to say that within about 5 hours of my feedback, a beta was given to me implementing them all, and the fixes I had suggested too. Really good work
EDD Checkout Blocks: I’ve been having a play with the new EDD checkout blocks, and this is a big improvement on what they had before. I haven’t looked to see if similar shortcodes exist yet, but I think this is a really positive step. Just need them to add native Paddle and Polar payment options now, without third-party plugins. I was able to get a shortcode from the blocks with options and make a nicer looking checkout in bricks with a custom code block as below.
