Introduction
The point of this framework is to provide a standard, reusable way to rapidly build and deploy our partner websites utilising both the procedure, pre-configured tools and pre-loaded content, including many of the assets you may require, sized and optimised and ready to use.
Once this and associated contact with the customer are synced into a contiguous process, this should facilitate extremely rapid development of partner websites – with the whole exercise almost a form filling exercise, design a header or footer, design the navigation, tidy up, test and deploy!
This framework includes a whole library of tried and tested plugins that really ought to facilitate completing any task you should need in the course of developing a site; all of the plugins provided have been extensively tested for code cleanliness and interoperability and selected over other plugins for this and other reasons – there really should be no need to install any other plugins!
If you feel there is something you cannot accomplish without doing so, please discuss it with Jason, because it would be better to add an appropriate plugin to the initial framework than immediately negate the entire point of the framework by introducing random unknown quantities!
Similarly, the settings chosen within the core and plugins of this framework have been tried, tested and selected for their interoperability, and it would be best to adhere to them unless you have extremely good reason to change them and fully understand the implications of your actions.
THAT SAID…. there are a number of settings that you may very well need to change – most notably, the global rules assigned to Asset CleanUp may potentially prevent you from running certain scripts that are necessary to your content, and you may need to create an exception for a given page where you require them. Just to reiterate… DO NOT remove global rules. Create a ONE TIME EXCEPTION to the rule where you need it.
I have begun documenting the various elements of the framework in separate pages, all categorised as ‘Internal Docs’, including information about the GeneratePress theme and it’s Premium plugins, the visual editor Elementor Pro, about the Custom Post Types and the PODS framework that facilitates them, and the collection of plugins I’ve extensively tested and included with the framework.
I have also included some example pages that demonstrate the use of some predefined shortcodes and template snippets.
NOTE! These documents are deployed publicly as part of the site, so that you can refer to them at your leisure! They should obviously be deleted before any live deployment!
A handy list of the internal docs pages so far, courtesy of one of my hand crafted extra shortcode functions:
Checklists
I have incorporated a series of checklists within the framework itself, via the Zephyr Project Management plugin, which should more or less cover every step of your website creation from before you even deploy WordPress to after launch. Refer to them!
They include:
- Pre-Development Checklist
- Development Checklist
- Launch Checklist
- SEO Checklist
- Security Checklist
- Maintenance Checklist
Functions and Configurations
It should be noted that I’ve added some additional functionality and defined some pre-configured presets over and above what you’d expect in the WordPress core. In the proper places, too. That is to say that some are defined in wp-config.php, and some in the active theme’s functions.php.
The configuration tweaks are mainly things like: max post revisions, auto empty trash time limits, auto save intervals etc.
You may have to manually add my tweaks to your own wp-config.php depending on how you approach loading the framework. It should just be a copy paste job in cpanel file manager.
Fortunately for you, I’ve also included a complete copy of the additions you should make in this documentation.
There are a few helper functions, such as the very manually hand crafted “post_auto_cat” which automatically assigns certain taxonomies to certain post types when you create a new one. For when you forget. Obviously, these can be customised. But do make sure you understand what they’re doing and the implications of any changes to any dynamic queries etc! (It’s all very well commented, naturally).
Client Dashboard and Appropriate Permissions
As important as any part of your development on the front end, is making a useful, easily accessible, simplified and, most importantly, less breakable back end admin interface for the client.
To that end, I’ve been looking at Client Dash, which is a visual editor for the back end of WordPress, configurable role by role. I’m not 100% sold on it as the solution yet, because whilst it’s pretty slick, it has some limitations, and is hard to pre-configure as part of the framework, because its contexts and content will change as you enable or disable plugins etc, making its configuration one of the very final steps before live deployment.
Generally, and particularly now we have all the custom post types, a client should not need access to anything but the written content itself. It’s likely that you’re going to have to assign the end user the role of Editor, so that they have the required capabilities to edit existing content they didn’t create.
Unless they have ‘guest authors’ or ‘bloggers’ or something, you shouldn’t really need any other role. So it’s not that much of a hardship to customise the Editor Role.
The defaults I’ve already set up do the following: Removes access to the Anywhere Elementor and Elementor Template menu items, the Tools menu, the Comments menu and Appearance menus, and access to the contact forms (which are very easy to screw up if you don’t know what you’re doing!) because by that point, each custom post type should be auto assigned the one you’ve designed for their site, and there should be no need for them to access the templates or anything about the site UI themselves.
Useful Links
For want of somewhere to add them, here’s a couple of links you’ll want:
Font Awesome 5 search, pre-set for ‘Free’, ‘Solid’. https://fontawesome.com/icons?d=gallery&s=solid&m=free
Better Font Finder https://jmattthew.github.io/better-font-finder/better-font-finder.html
GeneratePress Premium includes a raft of importable, Elementor compatible ready-to-go site templates, if you wish. See https://generatepress.com/site-library/
Policy on roles and access… Like, we should have one.
I would suggest we DO NOT assign the end user full administrative access, no matter how much they beg, plead or demand.
My opinion is that we should take a strong stance on this; if they do insist on full access, then the conditions of providing that level of access are:
- we will not host their site, and they will have to make alternate arrangements; it’s too easy for someone who doesn’t know what they’re doing to not only screw up their own site, but to seriously impact shared hosting and therefore directly affect other partner sites.
- we will not support their site from that moment forward, other than providing their designated IT people the files they need to redeploy the site themselves
- they will have to buy licenses for all of the premium plugins we’ve used in building their site to ensure continuity, and forward us their license details to replace our own before we can make them an administrator and provide them a copy of the site. It will need to be done in this order, because obviously we can’t be giving them products that are licensed to us and have them potentially break the terms of the license and affect all our deployed sites.
While we’re on policies to end users…
No, you can’t host it yourself! In my opinion, we should not be agreeing to create sites for Partners to host themselves in the first place – which I understand we have been doing. We’re offering an inclusive package of design and host. You don’t get to pick and choose… you don’t get to use us as a free web design house…that’s the offer, take it or leave it. With that stance and understanding made clear going in, we shouldn’t end up in a situation where a user is later demanding admin access and we’re having to boot them off our servers per the above.
No, we won’t host your email! Apparently, some of the people we’ve been doing these sites for have the cheek to try and save themselves a few quid and want us to host their corporate email for them too! If we do, we’re inviting a world of pain and ongoing support and finger pointing, and frankly, if we even entertain the idea, then we’ve just completely lost the plot…