Posts Tagged ‘Wordpress CMS’

When WYS is not WYG

When WYS is not WYG

CMS Editor Quirks & WordPress TinyMCE

While I am a huge fan of CMS (Content Management Systems), I do believe they have often been oversold by web design companies. The typical client for a CMS is an office administrator who is trying to find a way to save her company money by bringing the website updates in-house.

Content Management Systems CMS

A CMS like WordPress is supposed to make those in-house updates easy for pretty much anyone with any experience level, right? Well, that’s how they’ve been sold. But it doesn’t always work out that way.

The problem is that the office administrator is familiar with office related software, not web design. Being able to create a decent looking page in Word is very different from creating a decent looking page in WordPress. I deal with frustrated clients all the time who just don’t understand why it’s not working as expected. So what’s going on?

There are a number of issues which make a CMS less easy to use than they are often sold and sometimes first appear. So let’s list them.

WordPress is not a Word Processor.

WordPress (and any CMS) is fundamentally built on web technology. So its content formatting is restricted to the way that your browser can read and display it. Word (and other word processors) don’t have that restriction. They are built using system level code. They are not restricted to displaying in a browser. They create their own display. So they can format their code anyway they like.

A good example is bolded text.

The correct way for a word processor to format bolded text is to refer to the bolded version or defined weight of the font being used. If the font doesn’t have a bolded version or weight, it will not display the text bolded.

postscript fonts

Probably in favour of user friendliness, but with the effect of driving prepress and printers crazy, Microsoft (Office and Publisher) decided to implement their own method. Instead, they use a visual only bolding effect when you hit that little bold button. The word processor bold button adds an extra weight graphic in the editor display window even if the font doesn’t have a bold version or weight.

User friendly, right? Because it looks bold, the user thinks it is bold. You can even print it to your home raster printer and it looks right.

Printer friendly? Not so much. When you send it to a true postscript printer, such as those at a professional print house, the bolded texts print without being bolded.

Why is that? Because there really is no information written to the actual print file associated with the visual file regarding the bolding. It was a “user friendly” visual trick to satisfy the majority of home users and printers. The users perceive, and the printers receive, graphics only (not true postscript) from the software.

Good magic trick, right? Well, it’s fine until you take it out of context.

Something analogous is going on when it comes to the design and layout web pages. When the source content comes from a word processor or word processor user, it’s formatted for a completely different context. The WordPress content editor has a bold button which looks like Word’s. But the way it functions on the code behind the visual display is very different.

How to copy and paste from a word processor.

It’s common and good practice to create your website content in a word processor before copying it to your website. I do it all the time. My main reason is that I want a backup not on my website. But I also like my autosave on my word processor better than the one in the editor CMS (if it even has one).

Unfortunately, it’s not as easy at it seems. And there are no warnings telling you something is going wrong. Or going to go wrong. What happens is, at some point, when you start to try to make changes to the web page, perhaps to fix some aspects which didn’t copy so well, the layout goes all quirky. Whatever you try doesn’t work. And often makes it worse!

This is by far the most common problem and frustration I’ve heard. To understand the problem, you need to understand how the content styles are being copied from your word processor to your CMS editor. Just because you can do it, doesn’t mean it’s going to work as expected.

When you copy content from your word processor, your text is being saved in your invisible OS clipboard so it can be used in other programs or windows. It doesn’t copy the native DOC format because that would be useless outside of Word. It doesn’t copy the visual display, since that is basically a graphic. It formats the copied content as RTF (rich text format).

RTF is similar to HTML (the language of web pages). But they are not the same. They are similar enough that the web content editor can interpret most of the RTF and convert it to HTML. So, like the problem above, from a visual point of view, they usually look almost identical. But under the hood, the code is usually quite a lot different, usually the RTF includes a lot of unnecessary nesting. And that’s what get’s you into trouble later.


For you, the problem arises when either they don’t appear as expected, or changes are made and those changes don’t appear as expected. The main difference between RTF and HTML standards for web pages is that RTF includes all its style properties “inline”, while the HTML standard is to include class references to CSS styles (what tells the web browser how to display the content) defined elsewhere. HTML standards decided to separate the content from its CSS formating. But because RTF is an inter-document exchange format, it needs to encapsulate all its content and formatting (and images) within the same document.

For example, consider the humble paragraph. Here is what your paragraph HTML might look like when it is copied from Word:

<p class=”p1” style=”color: #000; font: times, serif 12pt normal; line-spacing:1.5; margin-bottom: 12px”>Here is an example from Word with <span class=”s1” style=”color: #000; font: times, serif 12pt bold;”>bolded text</span> copied into WordPress.</p>

And here is what it should look like:

<p>Here is an example from Word with <b>bolded text</b> copied into WordPress.</p>

The only good solution is to use the Paste as Plain Text button in WordPress. Or if you have already pasted it, use the remove formatting button. That remove formatting button will save you when you get into a mess and don’t know how to fix it. However, you then also lose all your HTML formatting. You’ll be starting from scratch. But that’s actually a good thing. That’s what you want to do. You were taking a dangerous shortcut. Stop and start over.

Here is an example from Word with bolded text copied into WordPress.

Removing and reformatting your content is a better solution in the long run because you don’t start stacking and nesting tags on top of each other with unpredictable results. WordPress should handle the paragraph tags automatically. For other simple formatting like bold, italic and underline, you can go through your text in WordPress and re-apply them where needed there. WordPress should add the proper cleaned HTML. Links are another formatting element that you will be better to add in WordPress after pasting them as plain text.

Keep your layout simple, stupid.


Another related common problem occurs when the office administrator is over-ambitious with their design and layout. They’ve learnt how to wrap text around images, create columns and tables, and love to play with font colors, sizes and styles. The problem is that these more complicated layout and formatting don’t translate very well. And they are not all that simple to recreate in WordPress if you don’t know the proper HTML and CSS method for them. For consistency with your theme formatting, and to avoid formatting issues, it’s best to keep your design and layout as simple as possible.

When formatting, always remember KISS!

The default WordPress editor is TinyMCE, mostly.

WordPress is packaged with the open source, multi-platform, WYSIWYG editor, TinyMCE. It’s the standard default editor used by nearly every CMS. WordPress has customized it, however, based on what they feel are its users’ needs.


For one, they’ve trimmed down its functionality quite a bit. That’s a good thing in one sense because it prevents content editors from over-stylizing their content. There’s no font, font size, and color buttons, for example. The editor is restricted to the styles defined by the WordPress theme CSS for the HTML. While that might be frustrating to the office designer who wants to do something more fancy to make it stand out, it does function to reign in the content formatting so it is consistent with the rest of the website.

The worst website design is one where every page is formatted different using many inconsistent colors and font properties.

The default WordPress editor has no buttons for creating tables or columns, however. And other advanced layout features like text-wrapping around images is not straightforward. TinyMCE is not designed for layout. It is designed for very simple text and image content.
Part of the reason for this is the philosophy that the layout should be provided by the theme. That doesn’t always help, since the theme has very little control over much of your content inside the post outside formatting the standard HTML elements. It could automatically put the entire content of a post in columns, for example, but not select parts.

To get around these limitations, many WordPress users have resorted to plugins. One of the most popular editor plugins, currently listed with 1 million+ active installs for example, is the expanded implementation TinyMCE Advanced. Some of the popular added features include:

  • Support for creating and editing tables.
  • More options when inserting lists.
  • Search and Replace in the editor.
  • Ability to set Font Family and Font Sizes.

As a web designer and developer, I shudder when I see those features available to content editors who have no HTML and CSS knowledge. I still have nightmares from some layouts I’ve had to fix because the user just didn’t understand how to undo what they already did, stacking one mistake on another. Unless you have an understanding of the HTML implementation of those features, they are going to get you into trouble. It’s far safer, and often cleaner, to keep your website layout and formatting as simple as you can.

The difference between responsive and static design.

Another reason not to use those advanced layout features in WordPress is that they are not all automatically responsive and mobile safe. It’s a common misconception that just because your theme is advertised as responsive and mobile friendly, all your content will be as well.

Text-wraps in WordPress, for example, typically use CSS “floats” which are not automatically responsive. That means that when you change the width of your browser, the image might stay the same size, but the amount of text wrapping could decrease. On some devices, that might end up being something which looks silly, like a vertical string of single word lines.

Tables are another example of something we rarely use in responsive web design these days. In the old days, they were often used as page layout tools. It’s not uncommon for office designers to use tables for laying out their Word documents. That’s fine for static fixed width documents, typical for print. We even still use tables to format static fixed width HTML for email.

But for responsive websites, tables don’t work for layout. Instead, we use specially styled boxes which can adjust their size and even the number of columns based on the device’s browser window width. With these, we can get precise control over how the layout responds to the browser width, such as when an image wraps the text right and when it goes full width and drops the text below it.

The downside for the content editor is that you don’t get these advanced responsive design elements, not even with TinyMCE Advanced. We edit the HTML directly to get these. There are plugins which will allow drag and drop page layout building, but none available for WordPress that I would recommend to the regular content editor (a topic for another post). There are also plugins which add responsive design shortcode capabilities, but in general, shortcodes should be avoided in your CMS (another topic for another post). So we’re stuck with our maxim:

It’s far often safer, cleaner, and more mobile friendly to keep your website layout and formatting as simple as you can, using only the simple tools provided with the default WordPress editor.

When you do need something a little more complicated, you can always shoot off a quick email to your friendly responsive web developer.

WYS is not always WYG.

A common theme running through this post is that, when providing content within a CMS, what you see is not always what you get. The Visual editor in WordPress is supposed to give you a preview of how your post is going to look on your website. It doesn’t. Surprised?

There is not much worse for an office administrator / web content creator than spending a great deal of time writing and formatting some new blog post or web page content, only to find out that it looks totally different on the website after it is published.

The main reason for this is that your backend admin is treated like a separate domain with its own formatting. It’s actually a separate theme file, with separate CSS for your fonts, headers, weights, spacing, and so on. That’s what the editor is based on.

If it were a little smarter, it could grab your theme CSS and apply that within the editor window. But it’s not exactly that simple. It would essentially need to read and rewrite your theme CSS just for application within that editor window. Not impossible for a developer to create, but certainly not a default feature.

When you are editing your CMS content, except for the very general basics like distinguishing between paragraphs, and inserting hyperlinks and images, you are basically formatting blind. Again, you need to keep your formatting, style, and other design elements to a minimum.

In WordPress, the best preview is in the Publish widget on the right. The Preview button there should open the page up in a new browser tab for you to preview what it will look like to the visitor. If it’s not turning out how you would like, it’s better to modify the theme’s CSS to get it to do what you want. And if you aren’t familiar with CSS, it’s better you hire a web designer or developer to do it for you. Those are very simple and inexpensive theme edits.

WordPress preprocessing quirks.

Not only is the visual editor not providing an accurate preview of your content design, layout and formatting, WordPress is also modifying your content formatting prior to the theme’s display of it. What’s worse is that WordPress gives almost no administrator settings to control how it filters the editor’s content. There are a few settings which can be changed within the core configuration files. But you usually don’t want to touch those. Basically, the only solution is to be aware of WordPress’ preprocessing quirks and live with them.

What to do when your published paragraphs aren’t showing as paragraphs.

As an example of preprocessing, WordPress automatically adds paragraphs to newlines in its editor content. That means, even if you switch to the Text (HTML) view, you won’t usually see paragraph <p> tags. If this is the case, it’s most likely because a hidden variable wpautop is turned off by something. I ran across this problem recently with my Yootheme. The theme setting, by default, disabled wpautop. But, when disabled, it doesn’t automatically start showing paragraph tags in the WordPress editor. Enabling wpautop in the theme settings fixed the issue.

Your theme controls your formatting.

As I’ve already explained, the way your content displays on your website goes through your theme styles. These don’t show in the WordPress editor, even in Visual mode. That means that WYS in the Visual editor is not exactly WYG on the published website. As a result, you need to constantly Preview your content with the built in Preview button, or use a separate tab in your browser to switch back and forth between the backend editor and the website in the frontend.
Depending on your theme, you can change the styles, such as the font family and size, in the theme settings. If not, you will need your web developer to create or edit those CSS files for you. Using CSS styles is the proper way to handle HTML formatting. Formatting in your editor is not a good work-around for formatting issues. It’s important to understand that the majority of formatting goes beyond what should be accomplished within the editor.

High Expectations.

The root of layout and formatting issues in the CMS can be summarized as content editors expecting too much of the CMS and their ability to control how their content is displayed. Typically Office users see the WordPress editor buttons and think they are the same as Office documents. A great step in the right direction to avoid these problems is to learn the limitations of the CMS, its editor, and website design in general. It’s really a different beast than word processing for print or press.

If you insist on doing your content updates yourself instead of hiring a developer, and you don’t want to learn the HTML, CSS, and how your CMS and editor deals with those, as well as the standard implementations for responsive mobile friendly design and SEO, you’re best strategy is to keep your formatting as simple as possible.

I understand that CMS’s have been oversold as simple, do it yourself, website creation tools. They are if your expectations are simple. As soon as you add any little bit of complexity, along with a lack of website architecture and development techniques, a CMS starts to go beyond a “do it yourself” website builder. That’s partly the reason for the recent popularity in DIY website builders like Wix (a topic for another post).

The solution is to lower one’s expectations of how much they can do themselves in their CMS. CMS’s are still great for organizing, managing and formatting various content assets. They are really powerful tools in the hands of developers, and they radically speed up development time compared with the old custom built website methods. But they don’t yet put all the power in the hands of the layperson.

WordPress editor developer specific notes.

These might read as a list of my WordPress pet peeves compared with other CMS’s like Joomla. CMS’s like Joomla and Drupal are targeted more towards website developers. So it is sometimes frustrating and more time consuming for a website developer when using a dumbed-down CMS like WordPress. Under the hood, at the API level, WordPress is arguably just as powerful as any CMS. But it’s not always available out of the box or even with third party plugins. I’ve found this especially true when it comes to the default editor (as well as the available editor plugins).

No administrator editor settings.

I find it shocking that the WordPress developers chose not to add Editor settings to the Settings menu in the WP-admin. TinyMCE itself bundles with over 40 features and settings. It’s also Open Source, which means it’s easy to customize and extend. I understand the reasons for pairing it down for the regular user. Content editors shouldn’t be given permissions to change administrator settings as well. But for the website administrators, shouldn’t they have access to the editor configuration settings?

WordPress does give us access, but only programmatically. You can manually change the default configuration file in wp-includes/class-wp-editor.php, but that’s not an update safe method to preserve your changes. WordPress does provide a method to hook a custom editor profile through either your theme functions.php file or within the template files themselves, but these are not theme update proof either. Within the WP-Admin, WordPress gives you access to many of its files through Appearance->Edit, but most of these files shouldn’t be changed either. It’s really a mystery why WordPress would include access to them when it doesn’t include access to the editor configuration. In fact, the editor configuration file isn’t even in Appearance->Edit.

The proper way for a developer to make changes to the WordPress core is by either (a) altering a copy of the functions.php within a child theme or (b) creating a custom plugin. Child themes should be preserved through theme updates, so they are the recommended method for making any theme changes, including those overriding the WP core configurations. Themes or frameworks sometimes have their own method for creating child themes which differ from the standard WordPress method, but it should be pretty straight forward whichever theme you are using.

A child theme is great if your changes are going to be theme dependent. But what if you change themes in the future? You, or whoever inherits the web development of the site will need to remember to copy over all the important modifications. A better, theme independent method is to create a custom plugin.

Fortunately, in this case, there is already a plugin available which makes the default WordPress editor configuration available within the backend WP-Admin: Advanced TinyMCE Configuration.

If the developer keeps it up to date with WordPress’ TinyMCE updates, this plugin should do the trick. It’s not super user friendly, requiring one to learn the setting names and values from the TinyMCE docs. It’s not very “Wordpressy”. And it still surprises me administrator access to these settings isn’t a core feature of WordPress as it is in Joomla.

Switching from Text to Visual modes modifies custom HTML.

When switching between Text and Visual modes in the TinyMCE editor in WordPress, sometimes HTML code is rearranged, reformatted, or even removed. This is because WordPress runs Visual mode through some HTML cleaning features. I’m not sure why they chose to do that since, in Visual mode, you aren’t editing HTML anyway. Perhaps it’s intended to clean up bad tags from a copy and paste. But it’s really annoying if you want to primarily or occasionally work with the HTML, then switch back to Visual to check it or add images.
This has been an issue within WordPress since it started using TinyMCE. It’s not a TinyMCE issue, however, as many of the forums suggest. Joomla’s default editor is TinyMCE as well, and it doesn’t have the same issue switching between code view and WYSIWYG view. This is one of the main reasons I’ve always favoured Joomla over WordPress.

What WordPress has done to address the issue is to put a user option to not use the Visual editor. That makes the Text mode of the editor default. It’s not enough, however. Sometimes I want to switch to Visual mode to make updates quicker than looking through the HTML. And there is nothing to prevent other users from opening and saving the post. If they default to Visual mode, then I could lose my custom HTML. It’s not irregular for multiple editors with different skills to work on the same article.

The problem is even worse for me as a developer when my customer wants me to fix their content to make it more responsive. In order to do that, I need to use custom HTML which WordPress might not approve. What we need is some method to tell WordPress not to clean the HTML, even in Visual mode.

Many of the WordPress forums discussing this issue (going back over 11 years) claim that this is an issue with TinyMCE and not WordPress. And again, I am telling you it is not. I’ve read the entire configuration docs for TinyMCE, and there is no setting for auto-formatting the HTML. This is a core addon from WordPress. I haven’t spent the time to narrow it down to a hack yet. But that’s certainly on my to-do list. The bottom line is that editing or hooking into the class-wp-editor.php isn’t going to help here.

Browsing through 800+ editor plugins in the WordPress Plugin Directory, I found three plugins which purport to address this longstanding need. The first, preserved html editor markup plus, hasn’t been updated in 4 years and has a pretty strong installation warning. I’ll have to sandbox that one in a fresh local WordPress install to test it. Being that old, however, I don’t have much hope for it working as is. I’m curious to browse through its code ‘though to find out what method it used. The second one, preserve code formatting, isn’t going to work because it doesn’t address the reformatting issue caused by switching to Visual mode. In its description, it actually recommends never switching to Visual mode, which certainly is not going to work for our clients. I had the most hopes for the third plugin I tested, dont muck my markup. However, I failed to see any difference. I still found that the code in Text mode was being reformatted when I switched to Visual mode.

Without a WordPress recommended method, and no seemingly working plugin for it, it looks like we have to resort to using a different, more code friendly, editor. Of the many editors available, I found that the most popular, TinyMCE Advanced, did the best job of preserving my custom HTML even when switching to visual mode. It’s not perfect, and for client sites I’d want to trim down the Visual editor buttons to just those which are safe for the client to use. But it looks like TinyMCE Advanced provides the only available alternative to WordPress’ quirky default editor behavior, allowing for content editing at the different levels as desired.

No ‘Code Editor’ and ‘No Editor’ options.

In Joomla, I am used to having the option to use the strictly code editor CodeMirror (with syntax highlighting) or even no editor at all (plain text mode like the file editor in WordPress). Joomla has several excellent code only editors with syntax highlighting to choose from. Sometimes I prefer to not use any editor at all. That’s when disabling all editors is useful.
While there are many WordPress plugins which provide syntax highlighting for the file editor (for editing theme and plugin files), I didn’t find any specifically for the content editor. And none were strictly for code editing with no visual mode, replacing and bypassing TinyMCE all together. Even more surprising, there appears to be no way to turn off the editor for posts and pages so the editor becomes like the default one for files (ie, no editor).

This really demonstrates to me how different the audiences are for WordPress and Joomla. Developers for WordPress are more focussed on the lowest skilled user, and not other developers. In Joomla, the developer community seems tighter to me, and the plugins seem to me to be more developed for developers.

I’m not going to argue that either is better since they are different niches. However, it would be nice to have a strictly development mode available in WordPress when I have a client who does not intend to update their own content, or when I need to get in there and do something really quickly without all the extra “user friendly” frills.

Can’t Set Default Editor by User, Role, or Page.

Another feature of Joomla I seriously miss in WordPress is the ability to set the default editor by user. That allows me to set my code editor, or no editor, as a default, while providing the client with a more user friendly visual editor. This could be set in WordPress in the User settings, or in a role management setting, or even on the page being edited (to make it easy to switch between multiple editors while working on some post). The lack of good editors for WordPress, and any developer specific editors, makes this issue a somewhat non-issue at the moment. A minimal plugin could at least disable all editors, however. That would certainly be preferable to nothing.

Developer Notes Summary.

Compared with Joomla, the choice of available editors, access to editor options, and ability to switch or disable editors by user is a serious impediment WordPress attracting developers to build websites in WordPress. Fortunately for WordPress, it is popular enough that clients who don’t understand these issues request WordPress based websites. That doesn’t help us developers however. For the moment, we seem to be stuck with TinyMCE Advanced.

On the upside, the editor issues and gaps provide a niche for plugin developers. I’m seriously considering spending some time to tackle some of these issues. I’m not sure how popular the solutions would be, however. Most of the editor plugins seem to target the wider unskilled user base. There is a quickly growing interest for drag and drop block builders to replace the visual builders in WordPress now that they are commonplace in DIY website builders like Wix and bulk emailer apps like Mailchimp. But there’s no reason you can’t have both. And there’s no reason they can’t be selected by user preference, or even on the page being edited as the user finds need.

Continue Reading No Comments

Welcome to Strategic Website 2016

Strategic Web Development and Digital Marketing

It has been about two years since I did a major website revision, which is about the maximum lifespan for a website. Instead of just reworking or redesigning my existing website, I decided to make a big move from Joomla to WordPress. I also totally revised the content to be more of a gallery style portfolio showcase of my web services and work. The written articles will be reserved for blog posts, which is one of the reasons I decided to move to WordPress. Over the next few weeks, I will be consolidating and reposting many of previous articles, as long as they are still relevant.

Why move to WordPress?

Well, I had a number of reasons to switch my website to WordPress. Here are a few reasons I switched my website CMS to WordPress from Joomla:

1. Blogging.

There is nothing wrong with Joomla for blogging, especially for one who is familiar with Joomla. You can do pretty much the same things as WordPress for blogging in Joomla using Joomla’s blog menu types. If you add the EasyBlog component to the Joomla CMS, you get even more blogging options bundled together than using the default WordPress blogging tools. So why switch?

The fact is, WordPress was built as a blogging tool prior to becoming a full fledged CMS. It was branded and marketed as a blogging tool. And it has created the largest community of bloggers within the blogging network. By becoming a regular WordPress user for my website’s blog, I both (a) get involved and exposed within the WordPress blogging community and (b), although I might not be an immediate fan, I familiarize myself with the regular usage of WordPress’ blogging tools, putting me in an excellent position to help others.

Coming from Joomla, where I was perfectly happy with the toolset I had used, I get a unique perspective on both the advantages and shortcomings of blogging in WordPress. Over time, if I find that there are some tools I had which I just can’t blog without, I can develop them as plugins for WordPress.

2. Content based websites should generally use WordPress for their CMS.

I’ve written this before. I divide websites into three categories: content, service, and product. When I recommend a CMS, I first try to determine whether the website is going to be primarily content, service, or product based. From there, my typically proposal starting point will be WordPress for content based websites, Joomla for service based websites, or Magento for product based websites. There are, of course, other considerations such as the availability of ready made add-ons to accomplish all the desired functions for the website, but generally my categorical analysis works well.

So when it came to my own website, a website about web development, website design, and digital marketing… a content based website by all standards!… I had always gone with Joomla! This should be embarrassing since it is contrary to what I recommend to my clients. And the real main reason is that I like Joomla better. I find it easier to customize, design, and develop within. Since it’s my own website, I should be allowed to choose the CMS I like best, right?

Well… yes and no. While I am actually very familiar with WordPress from its core frameworks and API to its administration interface and settings, my familiarity is entirely from developing websites in WordPress for clients. I have no familiarity of the benefits and headaches involved in the regular use of WordPress for my own website. That creates a little bit of a gap between me and my clients, the majority of which are familiar with and prefer WordPress. So I decided I needed to move beyond my own preferences and put the client’s user experience first.

3. Annoyances can inspire innovation.

As a professional web developer, I do much more than just create and customize websites. I also write plugins for frameworks and content management systems. I enjoy coding a new plugin from scratch with only a problem, annoyance, or desired feature in mind. It reminds me of the good old days when everything on the web was programmed from scratch.

There is no denying that WordPress has become the most popular content management system, if not the most popular platform in general for creating websites. With my background, skills, and attitude, I expect that when I run across something I can’t do in WordPress, or something in WordPress which really annoys me, it will inspire me to innovate a wicked solution. And when I have solution, I can release it to the largest community of developers, designers, and content creators on the web.

4. Blog content.

While I do have a ton of content categories to blog about already, I thought that transitioning to WordPress from the perspective of a “new user” but with the experience of a web developer would make for an interesting blog content category. So I plan to keep you posted as learn WordPress again as if it is for the very first time. I will post about my headaches, as well as tips and tricks as I (re)learn them again as if from scratch. This approach should be able to produce the some of most useful tutorials and walkthroughs available for WordPress.

So that’s it for now! If you have any of your own good or bad experiences with WordPress, why not share them below? Also let me know if there are any topics of particular interest to you. They might just find their way into my next post!

Continue Reading No Comments