As you’re all in the midst of your WP theme builds, I thought it might be useful to summarise some important aspects for workflow and setup for WP. A few reminders of basics and some things to avoid.
This goes without saying really ~ don’t even attempt to start on your theme build if your WP site has only the default content. An empty shell will not show you the elements of content your design includes. My advice is to install a very basic theme (like our vanilla theme) and activate it while you work on content publishing. As this theme is only very basic in design and pretty much the default setup, it will show you your content as it will look in WP ~ without distractions.
Once you have this installed, work on publishing your content first. This does not need to be the complete content but should be enough to have some content in each of your planned sections. Exemplary content will do for starters. Work on your structure at this point, i.e. create the pages and categories for your posts as needed. Publish a few posts for each category ~ and then set up your menu/s.
Once you’ve got the menu in place, the content published and linked to correctly — only then is it time to work on your theme.
theme builds and previews
One aspect to decide on initially is where to build your theme. You could work on a local server (install WP locally, add your theme there and develop it, previewing the local version). Or you could work on the server – be that a staging server or simply a sub-folder in the main directory. I’d recommend working on the final server as this will make the launch easy and quick and allows you to test everything on the final setup (+ save time on having to move the finished site).
To work on your theme, I’d recommend to find a workflow that suits you. You’ll have to edit your code, save and upload it ~ then preview your changes via your browser. To give you an example, here’s how I work: I use Nova as my code editor (and versioning tool). I set up a project and add the details for the server as remote directory ~ setting the file path to my new theme (the theme folder is inside your wp-content > themes folder). I also set up the publishing ~ this will keep track of any changes I make to any given file, be that the template file or the css. I then work on the code and publish the changes as I proceed via the upload function; testing the pages as I go.
In short: you will have to have your new theme uploaded to the themes folder and activated in order to preview. Once that’s in place, you simply uploaded the updated files as you work your way through the theme files.
If you are already working with versioning via GitHub or BitBucket, then you should do regular commits and pushes in addition. I have my repos on BitBucket and use Nova for my versioning.
But don’t worry if you’re not ready to do this yet ~ all in good time :) If you have not started wokring with versioning yet – there’s still a manual way of doing the same thing. Start your theme file, and in the theme description, start your version numbering:
Theme Name: MP
Theme URI: https://yourdomain.com
Author: your name
Author URI: https://yourportfolio.com
Start your theme build (saving and uploading as you go). Before you make a major change (maybe one that could break the theme), make a copy of the folder locally as backup, give it the name and version number as folder name for easy referencing. Then update the theme version to 1.1 — and carry on working in the same theme folder, again saving and updating as you proceed.
And if your changes result in a mess and all goes wrong, you can now copy/paste the files from the previous version into the current theme folder again and start fresh. If you do this at fitting points throughout your project, updating your version numbers, you are essentially doing your own versioning and safeguarding yourself against your mistakes with an easy way back :)
A word on plugins
My first question is always: do you actually need a plugin?
When you are new to working with WP – and you explore the available plugins, it’s easy to conclude that you’ll likely need plugins for any WP site. However, it is really only certain functions that will require a plugin, such as the GDPR consent (the cookie notice), or certain security measures — or more complex functions such as setting up a multi-lingual site or one with memeberships. In those cases, plugins are excellent as they allow you to add that functionality relatively easily.
Plugins that involve visual enhancements however are usually not required at all ~ despite how their descriptions might sound. WordPress now has the Gutenberg blocks which offer much if not all the functions these plugins advertise and sell.
A word of advice on pagebuilders ~ they’re evil :-P
well, that is an exaggeration ~ but I do strongly recommend you avoid anything that involves the word ‘page builder’!!! These had their purpose in the old days of WP ~ they met the needs that the Guternberg block now meet, offering options for custom layouts. Nowadays, for at least the last 5 years or so, these options are now part of the editor in WP directly, no need for plugins like these anymore.
The reason why I call them evil is that many of them have a bad impact on performance – they tend to work with huge JS overloads for editing as well as publishing and slow down everything. They often resort to adding lots of uneccessary scripts, slowing down your pages and in the worst case scenario, when you disable them, you have to revise ALL your content as everything will be broken. They’re not all bad – but as you know how to code ~ your best approach is to make good use of what the editor offers, and create your theme, templates and styles to do your own designs.
How to choose the right plugin
Do your research – read up on the documentation, check the reviews by others and see how the technical support is handled. By now, there are millions of plugins out there, some are by now outdated, no longer updated or supported, others are freemium, i.e. free for a basic version but better as pro when a fee is involved.
It’s important to be sure that the choice you make is for a plugin that will work for you on all fronts and that has good technical support. And try out the ones you feel might fit, see how they’ll intergrate into your theme before you make a definite decision. This will take a bit of extra time but will be worth it in the long run.
While there’s tons to learn to build a theme for WordPress, you’ll of course have to be familiar with using it for content publishing in the first place. This is an excellent manual, written for publishers and available to read for free online ~ well worth checking out before diving deeper into themes.
A simple, easy to read WordPress Manual
You won’t find any talk of HTML, PHP or creating WP Themes here. What you will find is a simple, easy to read WordPress manual that will guide you through the process of editing your site content.
You can read the Easy WP Guide WordPress manual online, download the free PDF, or purchase the eBook or brandable Word document. If you’re a WordPress consultant, use it to help your clients get the most out of their brand new site.
Grab a copy today and start learning!
Posted in articles | Comments Off on Easy WP Guide
We can choose to install our WP site into the root directory of our server, or keep the files within a sub-folder. My usual approach is to place all WP files into a folder in root. This allows for the holding page in the main directory to remain in place while the theme is being developed and built — and makes the launch as simple as switching a switch :) This article will outline the core points.
Lucky for us, WordPress will assist in taking care of the relevant changes to the URL structure and update the .htaccess file accordingly. We will use the general settings for the permalink structure to add in the 2 different URLs for our site:
WordPress Address (URL) this is where WP lives, i.e. the directory of all WP files in the case of this very site this means: https://eyelearn.org/seewp
Site Address (URL) this is the domain’s main URL which will access the site’s homepage. in the case of this very site this means: https://eyelearn.org
NOTE: as this domain is not using this site as main website – the details here are for demo purpose only.
Once you save these changes to the settings, WP will add the relevant code to your .htaccess page and this should be it. You can check on the htaccess file to see the Rewrite rule added.
3 parts in place
For a pretty permalink which removes the sub-folder name – we’ll have the following in our root directory:
seewp —— the folder for WP
index.php —— setting the WP site as main site for the domain
Advanced Custom Fields is a WordPress plugin which allows you to add extra content fields to your WordPress edit screens. This is ideal for scenarios when you want to present quite specific details in a formatted way, e.g. a directory of people or places.
NOTE: There are 2 versions available for this plugin: a free version, and a pro version which requires a yearly license fee for updates and support. While the pro version does include some useful additions, the free version already offers much, likely all you’ll need, and it’s ideal as a starting point while you’re still new to theme building.
How does it work? And when should I use it?
ACF allows you to add content fields to the editor. When editing a page or post using ACF, you will see more than the heading and text input bo – you will find additional inputs which you will have set up as fields and field groups. Their inputs are then pulled in via the theme file ~ same as the content itself.
The process is fairly straight forward:
install + activate ACF note: the free version is excellent and a good starting point for learning.
create a new Fieldgroup
add a new Field, add more as planned, e.g. for a profile this might be a photo, name, and job title.
set rules for use of the fieldgroup, e.g. configure settings to use on people directory posts only, ie used by that specific template.
edit relevant theme file to display inputs, you can now add the markup for your design, add the functions to display content of the fields.
edit your CSS to include the new content elements, your CSS will refer to your newly added content as written in your markup.
ACF becomes useful when you content is more than a combination of text and images. Keeping to the example of a people directory, you’d consider the layout of the details shown per person.
Do the WP editor or Gutenberg blocks allow you to implement your design easily? ~ If so, you won’t need to use ACF.
Does the content require specific markup for implementation of design? ~ If so, ACF will be the most effective approach, giving you the ability to mark up each content element yourself and specifying parameters for easier input.
What’s the difference to Gutenberg blocks?
ACF extends the content editing via a setup of custom fields with specific parameters. These can be added to the WP editor for specific pages and posts. Custom fields can be added via the template, or added as shortcode in the editor.
While the Gutenberg blocks offer a similar enhancement to editing, they also include formatting and additional settings and are therefore technically more complex to build.
NOTE: ACF have now developed ACF Blocks for Gutenberg as art of the PRO version — which is something you might fancy trying out when you’re ready to look into GB block building.
example: people of the web
Here’s a little site which is now replacing my slides for our web introductions. people of the web
setting up the fields
Each person’s profile includes a list of details:
first + last name
job titles / roles
known for … link + extra info (access via (+) toggle)
links: website + description
elsewhere: list of links to social media accounts
To allow detailed input, and set up links as required, I’ve used the following setup of fields within my ‘People’ fieldgroup:
This setup will result in the editor for any new ‘people’ posts to include the new custom fields:
Here’s Léonie’s top section as example:
Once you have content to display, edit the template to pull in the details as required. Here’s a snippet to show the markup of the profile photo and credits.
This might all look a tad long-winded and you might think it’s quite complicated — but it really is not ;) Once you have used one custom field successfully, you’ll be well on your way and it’ll get easier and easier :) The ACF documentation is excellent and will help you understand your options.
There will be times when things go wrong, as with any web setup. The dreaded white screen of death might rear its ugly head, or the connection to database seems broken. The causes of such errors vary: a WP update might have thrown up errors with plugins that previously worked but have not been updated; the theme is no longer compatible with the version of WordPress or PHP, for example.
The best cause of action will be to check on theme and plugins yourself. You might be able to find the culprit and therefore solve the isue yourself. If not, it might be time to open a ticket with technical support and ask the server experts to have a look.
To find which part of your setup is the trouble-maker (more likely a plugin than the theme) — start by disabling the plugins and checking whether the site is back.
To disable plugins:
connect to your server via FTP and navigate to the wp-content folder Remember: this is the only folder you should make changes to.
rename the plugins folder to something different, e.g. plugins-deactivate This will cause WordPress to ignore this folder, and therefore render all plugins inactive.
If the theme works at this point, without any plugin content or enhancements, then it’s likely that a plugin caused the problem. Check whether any updates are needed and ensure both WordPress and plugins are up-to-date.
To activate plugins:
rename the folder again, back to plugin This will cause WordPress to recognise and load this folder again.
All plugins are available again in admin ~ you can now proceed to activate them again, one by one.
Proceed with enabling your plugins one by one and check when things go wrong. Worst case scenario is when your site uses a plugin which is no longer being updated. You can then either try to update the code yourself, or find an alternative.
If you are using a given theme, a similar scenario could happen. If a theme clashes with an update to core, then the process would be the same: deactivating the current theme and forcing the default template to be used instead.
To deactivate theme:
connect to your server via FTP and navigate to the wp-content> themes folder You’ll need to know the name of the theme.
rename the yourtheme folder to something different, e.g. yourtheme-deactivate This will cause WordPress to ignore this folder, and therefore revert to using a default theme instead.
By changing to the default theme, any theme or theme function related issues are no longer present. The site should behave as normal. You can now check the theme files for compatibility or errors and update your code accordingly.
To reactivate theme:
upload the new theme version, or rename the folder again after update, back to yourtheme This will cause WordPress to recognise and load this folder again.
There is one seemingly common issue you might get while working on your sites: an odd error stating the lack of cookie support (despite correct details given and cookies enabled).
“ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.”
Usually, once you’re set up and switching themes, installing/removing plugins etc ~ all will hold up fine. You can log in and out as you need. Some plugins are fairly light-weight and won’t touch any major settings. Others however will go deeper ~ cache and security plugins will edit files to perform their functions.
This cookie error is usually caused by these edits or when you change your server. In short, settings for the cookie domain itself are wrong with your WP install, rather than this being an issue with cookie support in your browser.
NOTE: this is one of the reasons why I advised you not to use any performance enhancing or security plugins during the early stages of your theme build. These are great plugins and will serve their purpose in the end ~ so you should consider them and set up your selected ones just before launch. Prior that point though it will be better not to risk any of the caching or security plugin interfering with your work :)
Troubleshooting login error
The WP crowd primarily offers up two solutions to this problem: to edit the wp-config.php file or to add to the functions.php file. Both will resolve this error by redefining the cookie domain.
While you should not touch any of the core WP files, ie the files inside the main directory of the WP site, – this is the one exception, the only file to use for edits to configuration details. You might have used this file already during a manual setup, for example.
1. open the wp-config.php file and find this comment
(This file is in the main WordPress directory.)
/* That's all, stop editing! Happy publishing. */
2. paste the following line just before this comment and save the file
define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );
This will define the cookie domain — next up, clear your cache etc… and try logging in again. This should have solved the problem.
If this does not work, comment out or remove the line and try the next option.
The function file can perform the same function by setting the cookie path. Again, we’ll add to an existing file, in this case, the file is part of our theme.
1. open the functions.php file
(This file is in your theme directory.)
CAUTION: the functions file is quite special and very powerful ~ well worth exploring and experimenting with! Know that errors here can throw up major issues (so be ready for some white screens of death :D). It’s best to tread lightly ~ keep working versions of this file as an easy way back if something goes wrong. Breaking things will be how you’ll learn what works and what doesn’t ;)
SPECIFIC REQUIREMENT!! It is vital to end the code on this page without any extra empty line line breaks and NOT to add the closing PHP tag ?>
2. paste the following line at the very end of the code and save the file
!!! ensure clean line ending – no closing PHP tag ?> – no extra line breaks !!!