Customising WordPress
I once before took to the stage at the Cheltenham WordPress Meetup. At that time, my presentation was about making a child theme.
I spoke about the mechanics and all the possibilities a child theme might open up for the customiser. Some technical considerations were brought into view, but now I am speaking about customising a very different type of WordPress
Now we have the Gutenberg or Full Site Editor. This development has complicated WordPress even more (dare I say dirtied the output?), because of the extra code which the new editing tool adds.
I am not a developer – I do not use the command line, though I do like my very old html editor and delve into stylesheets and the html which make up a WordPress published page.
As many of you know I entered the WordPress realm because of a job I have had since 2010. I now update pages and publish post items from time to time for that customer.
This job came about because of my experience of electronic typesetting and database publishing, which began in the early 90’s and makes working in WordPress very comfortable, since I see it as basically a database publishing exercise – one which I say should be completed “elegantly” as my physicist
friends used to say – because elegant meant simple and clean.
My use of WordPress
I use WordPress as my everyday workhorse in my “office”. I can keep my own information in tables of the database, and have integrated these new tables into my instance of WordPress, just as many of the well-known plugins do. I have done this as a page not a plugin however.
We have to admit WordPress is a powerful database publishing solution. In my office WordPress I have set up simple book-keeping pages with spreadsheet-type outputs – simple sums. I keep my contacts in WordPress, whether full information on my customers, or merely the name of a supplier. This WordPress database can hold all the information I require for my simple business.
If I wanted to, I could publish this WordPress instance to pages on my public website so that I could use a smart phone to keep everything up to date. But, as I am a bit of a luddite and spend most of my time digging in gardens, I don’t do that. – After all, my phone may drop into the ditch I am digging and I could be out a £1000 electronic gizmo.
Now how do we do all of these customising things we do – do we rely on plugins or do we create new page types? This is the question which started off this presentation. At one of the most recent Meetup’s this question was asked and it stirred me to action – action which ended up with me standing here before you. The new editor helps set up pages within the site, a much easier way of doing this task rather than doing it somewhere else and importing the code onto the site in the right place.
Many ways to skin a cat
In my prepress days, the DTP program I used allowed many ways to do the same thing. In other words there were many ways to skin a cat. The same thing happens with php html and css. We can do the same things with different techniques.
We need to bear this in mind because WordPress can be used in many different ways to produce a page. I even toyed with using WordPress to make this presentation, but I fell at the first hurdle.
So I am using a combination of different techniques. As I have said there are many ways to use WordPress and to skin those virtual cats – sorry, I mean sites – with which we all have to deal. But the first thing we need to realise is this – WordPress is very simple.
Making use of WordPress
The paradigm WordPress uses is that of a simple database publishing program.
PHP gives us the material from our data store, html is the structured output of the material and css makes it all very pretty.
Gutenberg deals with how everything is presented, and this is where WordPress becomes very complicated. The new block editor allows us to style just about any part of the block as you all know from Elliott’s recent performance on this stage.
WordPress output has become very complicated, as you find out by using control+U in your browser. (Sorry, I am an inveterate PC man, but we can have that MAC-PC debate over a pint some time.) Or you can use the Inspector.
A post on SitePoint is apt here. An HTML structure gives us our content once we dig it out from the database which is at the heart of WordPress. See this SitePoint Newsletter post Learning html is the best investment I ever id
CSS selectors and html concatenated classes complicate things. They also allow us to beautify the site. – AT A COST.
Complicated
There are many classes introduced by the WordPress programmers which often make it very difficult to create custom css stylesheets. (In my darker moments I think, “Is this maybe the reason the block editor was introduced?”)
But the stylesheet seems to have been broken up now with Gutenberg. The use of a child theme had once simplified customisation of css because you just added the selectors and their modifications into the child theme’s stylesheet which takes precedence according to the rules of the Cascade. And you added your new selectors there as well. However, with the new editor, I am a little lost.
I think we should consider our paradigm a bit more because if we simplify WordPress’s methods, I am sure that the difficulty of letting the naive user, like me, loose with the full site editor shouldn’t be a problem, because we could find all the problems quite simply.
Most users only want to change how things look. Colours, sizes and different fonts – these are the things they want to customise. – They don’t want to be “developers”. – Pretty backgrounds. Bells and whistles bolted on top are what the ordinary user wants to change. The naive user does not want to get involved with WordPress programming.
Or have I got that wrong? Do users really want to get into php and database development? You have to answer that question, which may be entirely different to my reply.
An appraisal of WordPress
I would like to make make a descriptive appraisal of WordPress. There are wonderful points and some rather dubious practices within this extraordinary content management system of ours.
First of all, WordPress is backward compatible. This is a great benefit for developers and ordinary users. We can employ old themes within full site editing. Having said that, we need to rethink our use of this publishing paradigm.
I believe the K.I.S.S. mantra should be heeded. As Richard Bell pointed out a couple of meetings ago the simple php–html–css model which spawned WordPress has become very complicated, and necessarily so – that complication, however, is under the hood – a place the general user of WordPress on the internet does not want to look, because he or she says, all the bells and whistles usually work as expected on the surface – right out of the box
– after that famous five minute install.
For the user – not the developer – the model needs to be simplified. We should be able to find the complete stylesheet again, a stylesheet which controls the complete look of the site. It is not beyond the wit of programmers to use CSS properly for a whole site and to make it accessible.
I had been trying to do some simple css styling of a test page. I wanted to make the background a certain colour like green and the main content background white. Could I find the css selector? No, I could not do so immediately, and I skinned the cat another way – using the border style property. This worked well on the desktop version, but did not appear well on the mobile display. I think the selectors have become very complicated and don’t necessarily select easily – at least for me. Here I think the KISS mantra should be fundamental when we design our pages. I can understand the complication of WordPress html-css, but I don’t think it is always warranted.
In pursuit of simplicity and the elegance some coders pursue, I think the use of Repeatable Blocks is excellent, but they should create a class of HTML entities which are styled and the selectors placed in the stylesheet.
A corollary to these repeatable blocks is that Ad hoc Blocks (users’ blocks which are never repeated) should become styled inline, not hidden away somewhere difficult to find.
The simpler html–css model would make it easier to rationalise a website stylistically. You programmers could even let us, your naive users, loose in the full site editor without any fear. After all, if we messed it up badly, all of us should be able to find our mistakes and problems easily.
To conclude then –
This naive user learned about stylesheets in the print publication world as an electronic typesetter. The stylesheet is where the user works with WordPress. Let’s make it simple for everyone.
I am an innocent who has come to this table to share my experience with the hope that I might be able to make our experience less painful. Now it is over to you to talk about the current iteration of WordPress.
Some discussion points
- The creation of a new theme is seemingly impossible. WP at present places new elements in the database, not in the stylesheet. The php-html-css paradigm has been broken. Couldn’t we return to it? This came up in a discussion between some developers last month.
- Are we bolting too much onto the simple paradigm? Do we want a website to do too much – “conversion” is not the right term to use for fooling someone into buying something from your web site. We could use all of the javascript, the new css programmable properties, and so many other things in a way that is closer to the older and simpler paradigm of php–html–css.
- I was looking at the notion of “content” in my html editor. I found that usingp.mycontent::before
{
content : “this is my content”;
}we could get closer to a fixed content and so emulate the repeatable blocks of the new editor. But that is just one way of looking at it.
We need to get back to the simple standards as we have done in the past. After all, as those as long in the tooth as I am know, we don’t have to do MS Internet Explorer hacks any more, do we?