Content Creation in Themes

top feature image

Content Creation in Themes

I’ve been involved in WordPress for about 6 years now, since I retired from my real job 🙂 When I retired I fumbled around a few programming areas ( Objective C, Visual Basic) looking for something to keep me busy, and keep my mind sharp. My daughter needed a website, and I developed her one from a theme I purchased from Themeforest. From there I continued to pursue WordPress and discovered this was what I wanted to do in my retirement. I’ve always loved programming, and the WordPress world of PHP, HTML, CSS, and JS has been a great fit for me.

My first theme was blogBox, and my first review was shall we say difficult. I had experienced a couple of Themeforest themes at this point, so my vision of what a theme should look like and do was shall I say somewhat different from the theme requirements world that is WordPress .org. I looked at the review, and saw; no shortcodes, no contact forms, and I thought, what is the reasoning behind all of this?

Well I managed to get the theme approved, and have since learned to appreciate many of the requirements, that I was so upset about at the time. That experience forced me to create a plugin to provide the short codes I wanted in the theme, and a Contact Form Plugin, that I used privately. It also provided me with the incentive to join the Theme Review Team, learn theme’ing better, and perhaps help in driving the direction that WordPress Themes take.

After my third theme was approved, I noticed requirements getting more and more strictly applied. Particularly the content creation rule. Non Trivial content creation is not allowed in .org themes because users will lose the content when they switch themes. At this point I had become quite versed in theme requirements and was part of the admin group of 8 that carried more senior responsibilities in theme reviews.

As mentioned the content creation rule was there but no one really concerned themselves with the rule when options were used to populate the theme landing page. The rule was never really applied in that case, however that changed a few years ago, and it was no longer allowed. As a admin I was strongly opposed to this enforcement, as most themes that were in the repo at that point were not required to change, because of the adverse affects on existing users. I removed my themes from .org at that point because they populated home pages using content created from options. The decision was easier as there were not a significant amount of users, though the users I had loved the themes.

I would like to point out that I did not receive 1 complaint from any user over the three years those themes were being used, about losing content when they switched themes.

To deal with the content creation rules, authors do essentially one of 3 things:

  1. They set up posts of specific categories that may or may not include featured images. The option for a section then includes a drop down list where you can get select a category. The author can then access the post content and featured image for use in static page elements such as service boxes or sliders. So if a user switches themes, the posts remain, and the content is available for other themes use, though this usually requires changes in some way.
  2. They develop a plugin, submit it to the .org plugin repository. The plugin is then recommended through the theme admin area, typically using the TGM-Plugin-Activation plugin. Of course we must remember that the theme must operate fully without the use of the plugin, and plugins can only be recommended not required.
  3. Forget your own home page development as an author and encourage the user to use a page builder plugin.

Post Method

This method is great for setting up sliders and for creating portfolio pages, and I use it all the time for those things. However when creating sections for a landing page, there are difficulties for both the user and the author of the theme. Some home page sections are designed with an icon or image, title, content and a link button. All of these require specific styling, and handling this from the content area of a post is extremely difficult.

To get around these problems many authors will put in an option for the font icon, perhaps a link, then the drop down where they will retrieve the post title, content and image (if they can figure out how to do that) for a selected category. The other content is considered trivial so it’s fine.

Other authors will add a section title and description and then the drop down category list for post content and title.

The problems I see with this method:

  1. I strongly believe many authors compromise their design to use this method.
  2. What do you do with the blog index or recent post widget for posts that you are using to populate home pages. These posts are hardly post quality. The answer may be to use Page post content, better control but still searchable. I have modified recent posts and filtered posts selection for the blog index to exclude categories used for these purposes. Many authors do not do this.
  3. Users have trouble grasping the feature post content principles for populating sliders and portfolios. It takes significant documentation to help out the normal user. Most themes do not provide this level of documentation. Compare this with an image upload button, a title and description content area in an options panel, repeated for multiple slides. It is much much easier in the options panel. To suggest other wise is just silly.
  4. Overall this method lowers the theme quality, as compared to using options to populate the landing page. The argument is always made from senior reviewers and of course expert coders, that this method is fine and easy….but it is not the case.

Specialized Theme Plugins

Many authors develop plugins that are used to create the content for their theme home page. I really do not agree with this method for the following reasons:

  1. Significantly more coding is required, to supply the same information that could be easily supplied through options.
  2. The plugins are quite specialized and really in most cases only will work for the theme it was developed for. So the .org repo is being filled with plugins designed for a specific theme.
  3. Many times the theme and plugin need a common set of bundled resources, such as font-awesome, or jQuery animation script or a slider. In principle these resources should then be included for both the theme and the plugin if needed in both spots.
  4. Though I don’t have anything to back this up, I suspect the users don’t care much about this content when they switch themes anyways, because when a new theme is selected to freshen up a site, content is also freshened up.

Page Builder Plugins

Page builder plugins are available in the .org plugin repo. Though I have tried only one, I must say they are massive plugins, that essentially favor website developers and not the average user.

As a general rule I feel that a well programmed integrated theme is a better choice then a simple theme and extra plugins to achieve a more integrated approach. The reason of course is simple: one programmer, one update. I’m not saying plugins are bad, just that having to add plugins for things that could be easily integrated into a theme is bad, in my opinion. For example Testimonials definitely belong in a plugin.

There are a couple of alternatives to the above options :

  1. Let the User Decide. Allow content creation for the home page, and other minor things such as Author widgets and Call to Action widgets. Add a Content Creation Tag to the style header, and ensure any theme that creates content should have this tag included. This is an option I prefer.
  2. Back up content created to a Page. Allow content creation if the author provides a system where this content is backed up to a page. I recently submitted a theme to .org that does this. All options are backed up to a draft page at the users request. The option is well documented in the theme.

The second option was discussed extensively at the bi-weekly TRT meeting Sep 26. 2017. There was some lively discussion at the meeting, and I really don’t know if my theme will be approved. I did find it interesting and a couple of thoughts arose from the meeting:

  1. There are folks at TRT that just can’t let go of the thought that WordPress is just for blogging. This is perhaps the biggest hurdle to overcome. WordPress is now a content management system, and we need to advance that concept.
  2. Many theme houses also use content creation in Pro versions. In fact this becomes one of the selling points for Pro versions. So why is a more integrated approach working in their pro versions, but not in the .org repo?
  3. Attitudes around TRT (slack) are without question, more restrictive and less progressive. The tendency is to find ways to say no, rather then find ways to say yes.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post navigation

  Next Post :