Change to backend of WordPress (its administrative part, that is the editor assigned to the various users, administrator, publisher, etc.) are typical of most customizations: in other words, they are the reason why our customers come to us rather than exploit solutions pre-set for the creation of sites. From a technical point of view, the modification to the WordPress backend is formally very complex: if in the case of changes to the themein fact, tools such as actions, filters and themes child, in the case of changes to the internal editor we need to intervene using a combination of elements. Stuff that causes severe headaches to the occasional webmaster, but that the average developer should be able to manipulate with a little practice.
In fact, there is no way to intervene on the backend simple & fast, also because it has been programmed in a rather complicated way (and criticized by many for this): it is not thought, in short, for the modifications, yet we will try the same.
How to change the backend in the worst way
It is useful to start from what you should not do, so to understand by exclusion how to move: our need to modify the WordPress backend is, in most cases, linked to wanting to make life easier for the end user: objective more than legitimate, obviously, given that the numerous options present within the original menu could seem too much to the majority of the users of the site. Complicating the code for such an objective is clearly a contradiction, not to mention that in some cases we would like not to give the customer the possibility to change the theme or modify the plugins, leaving however the possibility to update them independently. A complex game of balances that must provide, in short, to prevent the user from “doing irreversible damage”.
The typical approach, in many cases practical to my knowledge, starts badly, indeed very bad: the typical modus operandi it foresees, in fact, to intervene on the source code of WP, or worse still to modify in an arbitrary way i roles of WordPress, which would seem the drastic & painless solution to our problems. In the long run, however, this approach leads us – apart from writing more code – to bypass the CMS controls, ending up degenerating our customization into a classic case of spaghetti code (code difficult to modify, maintain and decipher).
How to create, edit and maintain a WordPress backend-proof utonto
In honor of the KISS principle (Keep It Simple, Stupid) of maximum simplification of the code, the possible approaches to a change safe of the WP backend code could be the following.
- First of all create a sensible hierarchy of users, that is not to give to all administrator privileges: already to assign in correct way the typology of utilities, in fact, without needing to be an experienced programmer (also the administrator of the site can do it), it allows to do more things than we might think . If a user is an administrator, he sees the classic backend in its entirety; if he is a publisher, he sees a little less and so on, coming to the basic roles that have the most essential backend and which, in fact, in many cases could coincide with the level of “visibility” we want to give to the end customer. We therefore lose some time studying the role of the roles, instead of launching ourselves into unlikely changes to the code (which, in many cases, risk being lost forever to the next update of the core).
- Strictly avoid changing the raw WP code, because the changes will be lost to the next update of the core. In short, you will do a big job that will be invalidated at the next update (on average, WP makes one a month); some “genius”, in this regard, evaluates to disable updates in order to “work in peace”. The approach is completely busted, of course, as well as very risky in terms of safety.
- Strictly avoid, for similar reasons, to edit the plugins, which are not meant for “running” modifications: the correct approach involves, if anything, creating own plugins from scratch.
- Set up automatic theme and plugin updates immediately, and prevent them from being put to hand; to do this, just the simple options within wp-config.php. This will keep your new site stable and clean: my suggestion is to always do it, even if theutonto average does not appreciate these things (until, one day, he does not find himself with the compromised site).
- Many feature or features quite a lot required on the backend are, in effect, available in plugins ready to use: an example could be Admin Columns, which you can install to have the possibility to change the order and type of columns in the post editor. Already the basic version of this menu editor allows you to do a lot of things (there is a paid version that adds search filters, for example), including: adding columns, removing too many columns, rearranging them, deciding whether to hide them via CSS or remove them altogether extra features. Another similar plugin is Codepress Admin Columns, which even offers something more, or – again – Backend Localization which allows you to change the language of the backend only; there are other plugins like Back End Instructions which, however, at the time of writing, have not been updated for long. You can try them at your own risk, or exploit them as a basis for designing your own plugin, provided you know how to program a little better – to use a euphemism – than the average WP developer. However, although backend plugins are not too common, know that they exist, that they can help you simplify some things, and that in 99% of cases, on their own, they will not allow you to meet your list of requirements. You won’t get away with just installing plugin, in short, but it is certainly good to know that certain things exist.
- Take advantage of the action and the appropriate filters, those that allow (in the simplest case) to add some alert or warnings in the backend, passing through the typical controls of the codex that add behaviors based on the nature of the current user. These functions are often a few lines of code that allow very specific “punctual” interventions, and which prove very useful in the test phase, above all; over time you will understand well how to exploit them and appreciate their power. This phase is perhaps the most difficult but it is also the only really valid one: difficult to write, difficult to test but the results will be at least stable and safe. Action typical basic useful to approach in the right way are, for example: admin_init, wp_dashboard_setup, admin_head, admin_footer and admin_enqueue_scripts.
- Exploit more i framework, which I have talked about several times on this site (and which strangely is still ignored by the average developer): for example, it is sufficient to install OFT in your child theme directory to have a new page of options ready to be customized. The typical case of application of this framework is the one in which we must offer the final customer editable labels, editable text fields and other radio and / or on / off options. In more complex cases, you can find such more elaborate environments: it all depends on what you have to do and your budget, as some of them are paid.
- If possible, finally, avoid manipulating the roles, although there are many plugins that allow you to do this; from my point of view, even if statistically the site will continue to work the same, unexpected errors could be generated when we least expect it, considerably complicating – and in a useless way – the management of the code.
Changes to the WordPress backend are a treacherous weapon, so: WP is not meant for such changes, and many might think of an alternative like Drupal which, for example, offers similar functionalities (both from blogs and CMSs), even decidedly more powerful. The problem is that it is based on a mix – for many too difficult even to conceive – between the classic object-oriented programming (OOP) and its AAP evolution: enough because the majority of developers try to stay away from it.
Yet requests for changes of this kind are still alive, so at this point there is hope that things can be simplified even for WordPress, in the near future.