Quora: 1 Year and 1 Million Answer Views

Most people who follow me online know that I’ve been spending a lot of time on Quora lately. I’ve been writing answers, participating in discussions, sharing existing Quora answers with my team and interacting with team members met through the platform.

Which is probably why my local team prepared that spectacular clock for my birthday, conveniently including Quora to my daily schedule:

How I Got Started With Quora

I stumbled upon Quora back in 2013 or 2014 while browsing Google and landing on their site. For the most part, they allowed for browsing the first question without signing up as a new user.

My first answer was published on Feb 5, 2015. I honestly don’t remember much of my activities in 2015 and early 2016 – even though I’ve managed to publish 115 answers in the period of time. I recall reading their weekly newsletter occasionally, and reading some answer threads as well (since their targeting engine was well-adjusted based on the people I followed).

I know that I was generally intrigued by Quora but don’t recall investing much time or energy in the platform. Most of my answers hadn’t received significant activity or led to active discussions. I’ve asked a few questions as well and read several answers with varying quality.

Fast-forward to today, I’m extremely happy to mark my first full year of using Quora actively, writing a total of 855 answers since day one and generating 1 million answer views for my profile:

Why I Initially Transitioned to Quora

I’ve recently answered a related question in Quora discussing “How did Quora change your life?” which I’ll share here as well.

Quora has gradually moved higher on my “top of the mind” list. I do browse around while doing research or exploring a new field. I follow a number of topics and get a better understanding of a certain community. And I receive the type of personalized insight that I can’t find anywhere else.

There’s social media on one end and blogs/Wikipedia on the other.

Most Quora answers on subject matters are in-between. They’re not formal enough to reside as a formal article. And yet, they are not condensed (or thoughtless) enough to materialize as a Facebook post or a LinkedIn one – let alone the privacy/visibility settings. That’s something that Balaji Viswanathan briefly mentioned at Balaji Viswanathan’s answer to What are your research patterns for answering on Quora?

Some Remarkable Quora Content

Quora hosts a good number of tech and business experts and CEOs, investors, employees at companies like Google, Amazon, SpaceX. People share different perspectives in a non-intrusive way through different stylistic approaches. There’s a handful of topics (probably hundreds of thousands) for everyone.

Those are literally extracted from my Activity list over a 3 days interval. I can’t imagine reading those same stories elsewhere.

Quora as a Content Hub

From a writing standpoint, I’ve started using Quora as my go-to place. I hang out, read some intriguing stories, answer questions. Then I maintain a spreadsheet with some of the longer answers that I would reuse. And some of those get posted on LinkedIn Pulse, my blog, Medium, stories for guest posts or repurposed as videos or presentations.

A quick snapshot of my repurposing spreadsheet

Instead of spending hours on a single article covering a specific subject, I could answer random industry questions and connect the dots at a later phase. This allows me to leverage different mediums and reach other audiences as well.

I often work remotely and usually get more thoughtful and diverse insights from Quora than another forum, online community, or social network. Interacting with Quorans is also more personal as compared to a tweet or a random LinkedIn comment. Let alone sessions where industry experts such as Eric Ries take questions.

All in all, it’s been a great place to hang out once you learn how to filter out the noise.

The Community of Quora

One of the strongest aspects of Quora is the community.

When I reduced my activity here on DevWP, I did it for two reasons:

  1. The number of relevant topics I could cover slowly declined. I found myself starting a draft and realizing that I’ve discussed that problem or aspect of the WordPress ecosystem already, ending up with a closed browser tab.
  2. My readership was very narrow. I was talking a lot about the WordPress community while this is a tiny fraction of what I do. Other than being a WordPress contributor, I am a technical architect, a business owner, a manager, a certified Inbound Marketing & Sales expert with HubSpot, and hold a few more certifications in different areas. My content was constrained into the topics that my readers were generally interested in.

I wanted to broaden my horizons and connect with people outside of the community I’ve been interacting with for the past 3 or 4 years.

The first people I followed on Quora were lead engineers in Google, people working for NASA, serial entrepreneurs with multiple successful startups, marketing directors in Fortune 500 companies, investors, and other high-profile figures. Their perspective was adding on top of what I’ve seen before and what I have introduced to DevriX over the years.

I felt challenged before writing an answer. I was fully aware of the top writers in the given category and had to “compete” with them while posting my answer. This made me rethink the way I present my idea – in a condensed yet very structured way, describing the context of the situation where my answer is applicable.

My Content Marketing Focus

I decided to allocate time for Quora in December 2016 – just a year ago. It was a well-thought effort which aimed to test my writing skills, depth of understanding in different fields, and general commitment to a certain type of activity.

We all know that writing is all about persistence. That’s how I approached Quora myself and described our content marketing strategy in another answer.

Since I’ve written a bit over 700 answers over the past year, this is approximately a couple answers a day. Not too shabby, yet not as exhausting for anyone willing to run the same experiment and see for themselves.

Approaching Different Content Topics

By expanding my horizons outside of the WordPress space, I was able to join different discussions related to programming basics, teaching technical courses, hiring and recruitment practices, management strategies, inbound marketing, running an organization, remote teams and several other fields.

This was also in line with the content strategy we’ve been utilizing in DevriX and my blog redesign on Sep 30, 2016.

DevriX has been publishing content in three main categories – business, marketing, tech. I’ve been primarily writing about WordPress here but, truth is, I was just as engaged in the same three categories, leading to the redesign.

And Quora allowed me to repurpose my content across different outlets – including my blog here, LinkedIn Pulse, Medium, a recently started video series and even an attempt to craft an ebook (which may be released during Q1 2018).

A Passion for Writing

I’ve always been passionate about writing and my blogging efforts in 2015-2016 have resulted in a large group of folks discussing my blog posts here or during events. This was really exciting for me as I had never been incredibly regular in my writing activities (despite having my first blog launched in 2006).

I found HARO in the ultimate online marketing guide by one of my virtual mentors Neil Patel. And I’ve managed to land a mention (with a quote) on Entrepreneur early in 2015 out of my first 3 pitches in HARO:

This was outright surreal to me. I’ve given various interviews and appeared on several radio shows and podcasts, but our scale was a fraction of what top entrepreneurs were delivering to the world.

But I kept going and decided to aim for an entire piece published on Entrepreneur, Inc., or Forbes during the first half of 2017.

Published on Forbes, Inc., HuffPost, Entrepreneur, B2C, Apple News

I joined a few marketing communities in 2016 aiming to understand the marketing field even better and learn from the best writers out there.

That’s how I met Josh Steimle as well, joining his influencer group and newsletter and talking shop with him. His feedback was invaluable and taught me a lot about writing for the top publications out there. His group connected me with outstanding writers whom I’ve been following since.

I also followed the Marketing School and other initiatives by Neil and Eric, along with a list of focused resources on content marketing.

One of the most practical communities I joined was Online Geniuses. I met thousands of entrepreneurs, marketers, PR experts and journalists who shared their practical know-how with the crowd. That’s how I met an Indian contributor to several large outlets who connected me with an editor in Entrepreneur India.

I’ve since contributed several pieces there and indirectly hit my goal in March. I also joined Business 2 Community as a contributor and published a few articles on their platform.

The Quora Media and Publishing Team

As I kept investing time and passion into Quora, I woke up one morning with a completely unexpected direct message in my inbox:

I was honestly baffled and couldn’t figure out what was going on.

And I got to admit that I was misinformed prior to this message. I knew that some folks had a “published” badge on their profiles but thought that they are columnist or journalists for various outlets who had some type of partnership with Quora.

None of the folks I was interacting with was contacted and republished back then. And I had just enabled messages from everyone on Quora weeks before I got the contact request.

Needless to say, I was “all-in” and impatiently waited for my first piece to go live.

My profile reports 18 answers republished now in nearly 30 outlets (some get republished in 2 or 3 places at a time if the publishers like the format).

I don’t have a specific process that I follow for that purpose. It’s still enigmatic and purely subjective on Quora’s end for all I know. But that makes it that more exciting whenever I get approached for a republishing request.

Which is why I stick to my writing process – defining the context, busting a myth or two, explaining the general process or a step-by-step workflow of what works and what – not. It may spark interest but often it doesn’t.

Writing on general topics such as religion, hobbies, life, relationships definitely yields higher engagement due to the millions of teens and folks interested in chit-chat. I’m certainly not into that sort of stuff and I stick to the topics that I understand or am interested in.

Content Goals in 2018

I don’t have a specific content wishlist for 2018 yet.

The past years have led to long gaps between my writing cycles. I’ve spent months without publishing and then 4-6 months of writing a post once or twice a week. Most of those interruptions were related to work overload – tough deadlines, onboarding new people, tackling a new internal project or anything in-between.

In 2017, I managed to keep writing “no matter whatwith everything going on around me.

  1. We have a newborn at home and I’m trying to help my wife with anything I can.
  2. I work from home most of the time.
  3. We’ve hired about 10 people this year and I’m managing a number of folks at a time.
  4. I keep in touch with most of our clients on a regular basis.
  5. I participate in the long-term planning and short-term technical challenges at work.
  6. We’ve formed several strategic partnerships and launching into new markets in 2018.

I can easily spend less than an hour a day on Quora and still hit 1,000 – 1,200 words worth of answers if I have a good backlog of answer requests. It gets easier when I use the “Taking Questions” feature which could pop a dozen questions in a niche I’m familiar with.

Repurposing content is also somewhat automated now. All I need is a schedule calendar and cherry-picking the answers worth publishing elsewhere.

Specific Content Goals

I’m interested in compiling some of the best practices we’ve been using in DevriX and forming them as actionable processes. I’ll probably work on some lengthier guides or “How to” series in specific niches. The content I produce is still somewhat chaotic and organization may help specific groups of people interested in a single activity.

Regardless of what happens in 2018, I’ll keep pushing for more educational content that would impact more people.

And if you’re not using Quora yet, they just crossed 200 million monthly users. If you can gain a larger audience with your blog or social profiles, go for it. Otherwise, don’t neglect a network that could feed the right questions and let you focus on writing your best content with no platform lockdown.

The post Quora: 1 Year and 1 Million Answer Views appeared first on Mario Peshev.

Ask Yoast: WordPress themes and heading structure

Headings play an important role in structuring text, whether it’s on paper or online. Since reading from a screen is already quite difficult, you should make sure you make proper use of headings. There’s a hierarchy in heading tags, with <h1> being the most important, and <h6> the least important. This will help both your visitors (whether they’re reading or using a screen reader!) and search engines understand what’s most essential on a page. But what if your theme only allows the use of one type of heading? Is that bad for your SEO, and what does it mean for your visitors? In this Ask Yoast, I’ll get into that.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

Nikola emailed us her question on WordPress themes and heading structure:

My theme has no H1 headings on the homepage (or category and archive pages). All headings are H2. My developer says it isn’t bad for SEO, it’s worse to use multiple H1s on a single page. Is he right?

Watch the video or read the transcript further down the page for my answer!

A logical order in your heading structure

Is he right? Well he is and he isn’t…it really depends. If you’re using HTML 5, you can have multiple H1s, depending on how your page is structured. At the same time, not having an H1 at all in your page sounds very weird.

On a post page the title of that post should be in the H1. On an archive page the title of that archive should be in the H1. On your homepage your brand name should probably be in the H1. So, I’m not entirely sure that he’s right. I would prefer that he does it right in terms of using one H1, then some H2s, etc.

This is more of an accessibility issue than it is a specific SEO issue. But it’s important for people who are blind, or otherwise have a hard time reading your page, because they can actually follow the structure of the headings on your page. So do think about the headings on your page and make them follow a logical order. Good luck!

Ask Yoast

In the series Ask Yoast we answer SEO questions from our readers. Have an SEO-related question? Let us help you out! Send an email to ask@yoast.com.

(note: please check our blog and knowledge base first, the answer to your question may already be out there! For urgent questions, for example about our plugin not working properly, we’d like to refer you to our support page.)

Read more: ‘SEO Basics: How to use headings on your site’ »


The post Ask Yoast: WordPress themes and heading structure appeared first on Yoast.

On the topic of that pesky widget…

When I go to WordCamps, I get this question a lot: “Why do you have the PHP Code Widget still in the directory?”

There’s a good answer for that, but first let me explain why I made the thing in the first place.

If you examine the history of that plugin, you’ll find that it was submitted almost 10 years ago. Back then, widgets were new. Most people using WordPress had hardcoded sidebars in their themes. Changing the sidebar meant changing the theme. Widgets aimed to replace that with draggable objects. The Widget plugin was still a plugin, and not in core, but headed there.

The PHP Code Widget was created to make it easy and simple and fast to migrate from a hardcoded sidebar to a widget based one. You could take your existing code in the sidebar file, paste it into the widget, and then you had a movable widget that you could easily use.

Obviously, this was not meant for long term usage. The goal was to get widget support rapidly in your theme, with the expectation that as new widgets came out, you could replace your old code with newer, shinier, well supported, widgets.

The reason the plugin is still in the directory is because it still fills a need for some people. If I removed it, then they would fulfill that need in worse ways. It does not take much searching to find snippets of code, with bad advice saying to just pop it into your theme’s functions.php file, and voila, now all your Text Widgets run PHP code. That snippet actually exists. It’s a terrible idea, for obvious reasons.

The PHP Code Widget is less terrible than the alternatives.

But it’s still terrible.

And yes, it bothers me that it is one of the top 150 plugins. Storing PHP code in your database and then running it is just dumb. Don’t do that. Code should live in the right place, and that place is not the database.

So, in an effort to reduce the usage of the PHP Code Widget, here’s one way to stop using it, if you still are.

Getting rid of the PHP Code Widget

Step 1:

Get the PHP Code that you are using from the Widget, copy it into a text editor, save it somewhere for safe keeping.

Step 2:

You’re going to make a new plugin. You can call it whatever you like, but I recommend naming it specific to the site you’re making it for. If I was making a plugin for this site to hold widgets, then I’d call it “Ottopress Widgets” or something to that effect.

How to make a new plugin:

(Note: You can use Pluginception for this instead, if you like. That one I’m not ashamed of, it’s a very handy tool.)

a. Make a directory in /wp-content/plugins named after your plugin, like /wp-content/plugins/ottopress-widgets

b. Make a PHP file in there named the same. Like ottopress-widgets.php.

c. Edit that file, and add this header to the top of it:

Plugin Name: Ottopress Widgets

Lovely. We’ve made a new plugin. It doesn’t do anything, yet, but here’s some more code to add to the plugin. This is largely copy-paste, and then you edit it to fit your specific circumstances

Step 3:

add_action( 'widgets_init', 'ottopress_widget_register' );
function ottopress_widget_register() {
	register_widget( 'Ottopress_Widget' );
class Ottopress_Widget extends WP_Widget {
	function __construct() {
		$class = 'widget_ottopress';
		$name = 'Ottopress Widget';
		$widget_ops = array('classname' => $class, 'description' => $name);
		$control_ops = array('width' => 400, 'height' => 350);
		parent::__construct('', $name, $widget_ops, $control_ops);

	function widget( $args, $instance ) {
		echo $before_widget;

		echo '<h2 class="widget-title">Ottopress Widget</h2>';
		echo "<div>Here's my custom stuff.</div>";

		echo $after_widget;

I named this widget “Ottopress Widget” by way of example. In the first few lines of code, you’ll want to change these to your own naming scheme. It’s important that names be unique, which is why I recommend naming things using your site’s name. Unlikely for there to be interference that way.

The $class and $name variables you should also change. The class is used in the HTML that the widget produces, so you can refer to it via CSS. The name is simply used for display purposes on the widgets editing screens.

Step 4:

Finally, the meat of the code you want to edit is here. I’ll point it out specifically.

function widget( $args, $instance ) {
	echo $before_widget;

	echo '<h2 class="widget-title">Ottopress Widget</h2>';
	echo "<div>Here's my custom stuff.</div>";
	echo $after_widget;

This is the code that shows the widget on your site itself. Now, this one is just hardcoded to show the normal before and after code (these are set by the theme, so these should always be there), and then it has a little hardcoded bit there where it echo’s out a title and a div that says “Here’s my Custom Stuff”.

If you’re migrating from the PHP code widget, well, here’s where you migrate it to. You can drop your code from the PHP Code widget here and, you know, do whatever you were doing in the widget before, just now in an actual custom widget, in your own custom plugin. No more storing the code in the database. Just activate the plugin and replace the PHP Code widget with this one.

If you need more widgets because you were using it in multiple places, then simply repeat the process. Paste that whole class in there, only give it a different class name and other info, then put in your other code. You can have as many widgets as you like, they just have to all be named differently. Simple.

Note that this widget has no settings screen of any kind. Why would it? You’re controlling the code directly, no need for settings, presumably. If you want to go on and make your widget smarter and more complex and have settings, well, there’s other tutorials for that.

If this reduces the usage of the PHP Code Widget, well, I’ll be a happier person.

Reviewing the Guidelines – 2017

I do this regularly, but recently I received a comment that the guidelines were still too vague.

I need to stress that this is by intent. If we make guidelines like “You can only have 3 external links” then people will find ways to exploit that. However I do not think that guidelines are perfect. Which is why I’m proposing a minor update to them to address the following concerns:

  • Overall tense of guidelines made consistent
  • Update introduction for readability and unpack what we mean by keeping email updated
  • Explain the converse of 3
  • Put the important part of 5 on top
  • Add link to forum guidelines to 9
  • Add prohibition against harassment to anyone in WP
  • Clarify self-dismissible alerts are acceptable in 11
  • Changed tense of 12 and 13 to emphasize their importance
  • Grammar fix for title of 15
  • Fix reference to zips in 16 (upload now vs link to)
  • Reword title of 17 to explain that PLUGINS must honor…
  • Guideline 18 has received a full rewrite to clarify what rights we reserve and reiterate our promise to do this as fairly as possible.

You can see all the changes proposed here on GitHub

Please read the guidelines and leave comments or pull requests on Github. The plan is to make these live in January 2018 so please jump in and help! Thanks.

#announcement, #guidelines

What does the redirects manager in Yoast SEO do?

The redirects manager in Yoast SEO Premium is a real lifesaver. It’s a feature we at Yoast use many times a day. Once you used it for a while, you wonder how you ever lived without it. The redirects manager makes everyday website optimization and maintenance a piece of cake. It takes care of all redirect tasks, so you don’t have to think about that as much. In the end, it will save you lots of time and money. Here, we’ll shed some more light on the invaluable redirects manager in Yoast SEO.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

What is a redirect?

Before we get into the awesomeness of the Yoast SEO redirects manager lets take a brief look at redirects. A redirect happens when a particular URL is deleted or changed and the browser gets served another URL in exchange. If a site owner deletes a page and does not redirect that old page, visitors to that page will see a 404 error message/page. So, to send visitors to a substitute URL or another relevant page, you need a redirect.

There are loads of reasons for why you would need a redirect:

  • When you delete a post or page;
  • When you change an URL structure;
  • If you move from HTTP to HTTPS;
  • Whenever you move a domain;
  • If you edit the slug of a category;
  • Etc.

Historically, deleting a page and making the correct redirect was a nasty chore. You had to do it manually in the .htaccess file or with scripts on the server-side, like Apache’s mod_rewrite or ngix rewrite module. In all cases, there was code involved. Not something anyone was remotely comfortable doing. Today, with Yoast SEO Premium that process is dead easy. If you are in need of a WordPress redirect plugin, give this one a try!

What does Yoast SEO do with redirects?

Using Yoast SEO Premium, making a redirect becomes a straightforward process. It takes just a couple of quick steps. Let’s say you want to delete a post:

  • Open the post that needs to be deleted
  • Move it to trash
  • Choose if it should receive a 410 content deleted redirect or a redirect to another page
  • Hit OK and you’re done!
  • Easy peasy, right?

redirect deleted post redirects manager

As you can see, the redirects manager in Yoast SEO Premium is an incredibly simple tool to work with redirects. It asks you what you want to do with an old URL whenever you change or delete a post or page. This process takes place in the redirects manager or the post editor. The tool asks you if you want to redirect the post to another URL or to serve a 410 content deleted header, for instance.

Correctly redirecting pages keeps your site usable, fresh and healthy. Visitors won’t stumble upon dead links and neither would Google. Google loves sites that are perfectly maintained. The cool thing is that everyone can do this and you won’t even need to call in your developer to fix it for you.

Not sure how the redirects manager in Yoast SEO works? Check this video and it becomes much clearer:

Types of redirects

The redirects manager supports the most essential redirects. Below you can find the supported redirects. If you need more information about these different redirects, please read the Which redirect post. Want to know the difference between a 302 and a 307? We’ve got you covered which this post on HTTP status codes.

  • 301 – Moved permanently
  • 302 – Found
  • 307 – Temporary redirect
  • 410 – Content deleted
  • 451 – Content unavailable for legal reasons

Inside the redirects manager in Yoast SEO

The redirect manager can do a lot more cool stuff. You can bulk edit your existing redirects to, for instance, change them from a 307 to a 301. Or you can filter for redirects to see which ones need changing or you can find a specific redirect on an article and change it to something else.

edit redirect redirects manager

Integrates with Google Search Console

If combined with the power of Google Search Console, you’ll get the ultimate in site maintenance power at your fingertips. Let Yoast SEO Premium access your Search Console account and you’ll see all the crawl errors appear. After that, you can use the redirect manager to create redirects of all 404 errors instantly. Spring cleaning, anyone?

Michiel did an excellent job explaining how you can connect Yoast SEO to Search Console and how to fix crawl errors. Read that if you want to know more about the combined power of these two killer site maintenance tools.

redirects search console yoast seo

edit redirects search console yoast seo

REGEX redirects

Not for the faint-hearted, but for the true redirect kings. That doesn’t mean you can’t learn to use it as well because you should. Making redirects with regular expressions is different because you have to determine what should happen and how it should happen. It is an incredibly powerful tool that can do crazy smart stuff and is your go-to tool if you need to do very specific or large-scale redirects.

Have Team Yoast install and configure Yoast SEO premium for you! »

Let us configure Yoast SEO for you Info

WordPress redirect plugin

(The redirects manager in) Yoast SEO Premium is an excellent tool, not just as an SEO tool but as a site maintenance tool as well. But don’t just take our word for it. As writer Jody Lee Cates told us:

“I hesitated to pay for Yoast Premium because I am a new blogger without much income yet. But I’m so, so happy I did! The time the redirect manager is saving me is priceless! And it’s giving me the freedom to change URL’s to improve SEO without worrying about creating redirects on my own.”

How’s that for an endorsement?

Read more: ‘Why every website needs Yoast SEO’ »

The post What does the redirects manager in Yoast SEO do? appeared first on Yoast.

WordPress 4.9.1 Released, Fixes Page Template Bug

WordPress 4.9.1 is available for download and is a maintenance and security release. This release addresses four security issues in WordPress 4.9 and below that could potentially be used as part of a multi-vector attack. According to the release notes, the following changes have been made to WordPress to protect against these vulnerabilities.

  1. Use a properly generated hash for the newbloguser key instead of a determinate substring.
  2. Add escaping to the language attributes used on html elements.
  3. Ensure the attributes of enclosures are correctly escaped in RSS and Atom feeds.
  4. Remove the ability to upload JavaScript files for users who do not have the unfiltered_html capability.

Rahul Pratap Singh and John Blackbourn are credited with responsibly disclosing the vulnerabilities. In addition to the changes above, 4.9.1 fixes eleven bugs, including the Page Template issue we wrote about last week. Many sites have already updated to 4.9.1 automatically. To see a list of detailed changes, check out this post on Make WordPress Core.

How to connect Google Search Console to Yoast SEO and fix errors

In our plugin, you can connect Google Search Console to Yoast SEO. This verifies your website for your Google Search Console account and allows you to view your crawl errors. Especially when you have a large site, the number of crawl errors might scare you. In this post, I’ll explain a bit more about crawl errors and show you how to fix them, using Yoast SEO Premium.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

What are crawl errors?

Google uses so-called Googlebots to crawl and index your page. Crawling, in layman’s language, is the process of Googlebot going over your pages, one link at a time. When crawling, its goal is to get to every important page on your site by following links on pages, in sitemaps, etc. Indexing, on the other hand, is what Googlebot does to take in all the content on your pages, to include it in its search result pages.

There are two types of crawl errors:

  • Site errors that affect your entire site. Think along the lines of connectivity issues with your web server, and problems fetching your robots.txt file.
  • URL errors that affect a specific page on your website. Googlebot tried to crawl the URL but did not succeed somehow. It was able to resolve your DNS, connect to your server, fetch/read your robots.txt file, and then request the URL. But after that, something went wrong.

Viewing crawl errors in Yoast SEO

In our Yoast SEO plugin (free and paid), you can view the crawl errors that Google came across on your website. All you have to do is connect Google Search Console to Yoast SEO. In our plugin, we guide you through that process. Let me explain the steps here as well.

Connect Google Search Console to Yoast SEO

To connect Google Search Console to the Yoast SEO plugin, all you have to do is navigate to this page in WordPress: SEO › Search Console.
Connect Google Search Console to Yoast SEO

The next step is to connect them. In our plugin, just click the ‘Get Google Authorization Code’ button:Search Console - Yoast SEO

It’ll take you to Google Search Console. There, you’ll be asked to confirm that you want to connect Google Search Console to Yoast SEO and let our plugin view and manage the data for your sites. Click ‘allow’:Search Console - Yoast SEO

Lastly, you’ll get a key to include in our plugin:GSC copy paste code

Now simply copy-paste that code and insert it into the box in our plugin, hit ‘Authenticate.’
Google Search Console pick profile

Choose the profile you’d like to connect and save it. Done! Now, you can continue in the first tab of that same section in our plugin (Desktop). Be sure to check the other tabs as well to find specific crawl errors.Yoast SEO crawl errors

Here, you will find the information we collected from your Google Search Console. In this table, you see the URL that gave an error, the date Google crawled it last, the date when Google detected the error first and the response code Google sent. In the screenshot, all response codes are 404 Not Found.

So, if you connect Google Search Console to Yoast SEO, you will have a great overview of how many crawl errors Google finds on your website. Now, you can go and create redirects for these 404s, or simply change them to 410s if that page is of absolutely no use to you anymore. More on status codes in this article. When you have ‘fixed’ the error, hover over the URL in Yoast SEO and click ‘mark as fixed’.

Is there an easy way to create that redirect?

Yes! There is an easier way to complete this process, and it is called Yoast SEO Premium. Besides a lot of extras that plugin has to offer, it allows you to immediately create your redirect in our plugin:create redirect in Yoast SEO Premium

Simply click ‘Create redirect,’ and, unlike in our free plugin (which will prompt that it’s only featured in our premium plugin), you’ll get this screen:
redirect and fix crawl errors in Yoast SEO

Our plugin will give you the option to create a redirect, or add another status code (301, 302, 307, 410, 451 are all possible). In case of a 301 redirect, like in the example, simply insert the URL you’d like that ‘old’ URL to redirect to. If you want to tell Google Search Console about this fix, simply leave the check ‘Mark as fixed’ as is and hit ‘Create Redirect.’ It’s as simple as that. In tomorrow’s article, we’ll shine a light on the redirects manager.

Now go and connect Google Search Console to Yoast SEO!

I hope this sheds some light on why you want to connect Google Search Console to Yoast SEO. You’ll be able to monitor crawl errors in our free plugin, and for a few bucks a year, our premium plugin will even help you fix them!

If you by any chance have already used this feature in our premium plugin, I’d love for you to share your thoughts and experiences in the comments!

Read more: ‘Which redirect should I use?’ »

The post How to connect Google Search Console to Yoast SEO and fix errors appeared first on Yoast.

Gutenberg Team Is Ramping Up Usability Testing at WordCamp US

The Gutenberg Team will have a usability testing station set up at WordCamp US where attendees can participate in a round of pre-set tests that focus on the writing flow. Testers will answer a short survey that includes their prior WordPress experience level, age, and device used. Volunteers will get participants set up with a testing site and will start the screen recording app.

Testers will be asked to create a post based on the content shown in an image. There are three different images, which require the user to perform actions such as adding images, embedding media, creating unordered lists, adding quotes, and other basic content creation tasks. In order to segment results, the usability tests have been divided into beginner, intermediate, and advanced level images.

Advanced level task image for Gutenberg usability testing

After completing the test, participants will be asked to answer a few followup questions, such as “Did the task take longer or shorter than you expected?” and “Are you more or less likely to use the Gutenberg editor in the future?”

“This is the second round of usability testing scripts — we tried out the first batch of scripts at WordCamp Milano, and made some adjustments for clarity,” Gutenberg design lead Tammie Lister said. “As a result of testing, we moved the toolbar on blocks to not be fixed and back to the block. At Milano, we tested the tests.”

As the result of these tests and other prior feedback, Lister recommended the default position of the toolbar to be fixed to the block.

Anna Harrison, UX lead at Ephox (the makers of tinyMCE), has been instrumental in helping with the efforts around testing and writing scripts. She also offered feedback on the ticket, referencing comments from the previous discussion on the issue:

A fixed [docked to top] toolbar solution has several complications. Firstly, we break accessibility. I won’t reiterate the discussion, as it’s well articulated above. Secondly, we break things independent of accessibility – I ran user tests on something quite similar to this last year, and we discovered that disconnecting the toolbar from the point of action resulted in 100% user test fails.

Gutenberg version 1.8 will change the default back to displaying block actions on the block level, although the option to change it to a fixed toolbar at the top of the screen will still be available. This change is one example of how usability testing is shaping Gutenberg’s development. WordCamp US is an opportunity for the team to collect a host of new testing data in one place.

Lister said all the data that is collected will be processed by volunteers on the make/test team, but the team is still small and they could use more volunteers to work on this effort.

“The turnaround time on processing the data we collect really depends on how many volunteers are available to work on it,” Lister said. “It also depends on if it’s a bug reported – bugs are easier to get fixed right away. If the data indicates an area where we need to investigate more, we’ll do that. The results of the testing will be published on make.wordpress.org/test.”

Lister said the team is hoping to reach a wider variety of WordPress users at WCUS this year, from all backgrounds and careers. The testing booth offers an opportunity for anyone to contribute to the future of WordPress, regardless of your experience level or familiarity with the software. The team is also eager to broaden its testing field by recruiting non-WordPress users as well. If you can’t make it to WordCamp US, you can still contribute to Gutenberg by taking and administering usability tests on your own with the help of the instructions posted on the make.wordpress.org/test site.

Last Updated On Nov 27/28 Without Updates? Don’t Panic!

In the last 24 hours, a fair amount of plugins were “updated” because of the strings importer having an issue. Those had to be rerun in order to get the strings pulled in to be translated properly. This had the adverse impact of causing the “Last Updated” value to change.

Which scared people. Sorry about that.

If you’re worried, check your SVN changelog. If nothing was updated, then it was just us 🙂

Of course, if someone you don’t remember giving access to did your last commit, please DO email us at plugins@wordpress.org right away and we’ll help you out.

How to Turn Off PHP Errors in WordPress

Recently one of our readers asked how to turn off PHP errors in WordPress? PHP warnings and notices help developers debug issues with their code. However it looks extremely unprofessional when they are visible to all your website visitors. In this article, we will show you how to easily turn off PHP errors in WordPress.

How to turn off PHP errors in WordPress

Why and When You Should Turn Off PHP Errors in WordPress?

PHP errors that you can see on your WordPress site are usually warnings and notices. These are not like internal server error, syntax errors, or fatal errors, which stop your website from loading.

Notices and warnings are the kind of errors that do not stop WordPress from loading your website. See how WordPress actually works behind the scenes for more details.

PHP errors in WordPress admin area

The purpose of these errors are to help developers debug issues with their code. Plugin and theme developers need this information to check for compatibility and best practices.

However, if you are not developing a theme, plugin, or a custom website, then these errors should be hidden. Because if they appear on the front-end of your website to all your visitors, it looks extremely unprofessional.

WordPress warning errors on homepage

If you see an error like above on on your site, then you may want to inform the respective theme or plugin developer. They may release a fix that would make the error go away. Meanwhile, you can also turn these errors off.

Let’s take a look at how to easily turn off PHP errors, notices, and warnings in WordPress.

Turning off PHP Errors in WordPress

For this part, you will need to edit the wp-config.php file.

Inside your wp-config.php file, look for the following line:

define('WP_DEBUG', true);

It is also possible, that this line is already set to false. In that case, you’ll see the following code:

define('WP_DEBUG', false);

In either case, you need to replace this line with the following code:

ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Don’t forget to save your changes and upload your wp-config.php file back to the server.

You can now visit your website to confirm that the PHP errors, notices, and warnings have disappeared from your website.

Turning on PHP Errors in WordPress

If you are working on a website on local server or staging area, then you may want to turn on error reporting. In that case you need to edit your wp-config.php file and replace the code you added earlier with the following code:

define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

This code will allow WordPress to start displaying PHP errors, warnings, and notices again.

We hope this article helped you learn how to turn off php errors in WordPress. You may also want to see our list of the most common WordPress errors and how to fix them.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Turn Off PHP Errors in WordPress appeared first on WPBeginner.

25+ Business Scaling Mistakes Running a Large WordPress Website

Running a successful large WordPress website that generates hundreds of thousands or millions of page views a month comes with its own challenges. Business owners often become victims of various dangerous mistakes while scaling their online presence leading traffic to a platform that couldn’t handle the volume of users or content published on a regular basis.

WordPress Websites in a Nutshell

WordPress is a wonderful platform which currently powers over 29% of the top 1,000,000 websites. There’s are tens of thousands of themes and plugins available for blogs, small websites, business portals, magazines, membership platforms, eCommerce stores and everything in-between.

On top of that, there are thousands of tutorials that go through the installation process of WordPress in a few quick steps. Most hosting providers include an automated installer which could set up a new WordPress install within a matter of minutes, including a preselection of beautiful themes and several bundled plugins on top of that.

However, scaling WordPress requires some technical expertise. Spinning off a DIY project of your own or launching a minimum viable product with an off-the-shelf theme and numerous plugins on a yet another host may have a massive impact on the performance, stability, and security of your WordPress website.

WordPress is a Content Management System written in PHP and JavaScript, working on top of a MySQL database. The core application requires a web server such as Apache or nginx, running mod_php or php-fpm. This setup is often hosted on a Linux box (with alternatives available on a Microsoft stack with an IIS server).

While a simple website receiving just a few thousand views a month may be stable and reliable long enough, production experience with the full stack is required for scaling large WordPress applications.

The Role of a WordPress Development Company

Unlike non-technical business owners or site builders, professional WordPress developers and WordPress development companies profile in building scalable solutions on top of WordPress.

While business owners may mistakenly see WordPress as a software, experienced developers know that WordPress is a powerful application framework that could solve various problems for different business needs.

The difference is that WordPress, as a core CMS platform, includes a good number of features available by default to different audiences. The code base of WordPress is well over 300,000 lines of code partially executed across the different entry points of different requests – such as a front-end template view, an admin dashboard page, or an AJAX call. Along with the newly introduced WordPress REST API and the XML-RPC endpoints used by some services and mobile applications, the platform may be exposed to large traffic spikes or different activities that affect the standard flow of events.

A professional WordPress development company is intimately familiar with the common challenges of scaling a WordPress platform and handling the numerous challenges that occur in different events. Some of those problematic areas may be:

  1. Large volumes of data (hundreds of thousands, millions, or tens of millions of blog posts and various post types)
  2. Active communities of millions of users
  3. Highly functional platforms connecting to various 3rd party services and solutions
  4. Complex websites including dozens of custom-built plugins tailored to the user experience of customers and visitors
  5. eCommerce platforms handling thousands of concurrent users purchasing goods or services simultaneously
  6. Membership platforms streaming data on the fly across various platforms
  7. Extensive landing pages streaming live events handling hundreds of thousands of visitors daily

While this is not an extensive list, it illustrates common scenarios where a WordPress website needs professional development help in order to scale.

The Most Common Mistakes While Running a Large WordPress Website

Professional WordPress developers working on high-scale solutions carefully investigate the existing code base and tap into the hosting infrastructure in order to identify areas for improvement. There are various scenarios where WordPress developers may spend time on certain activities such as:

  • Implementing additional caching layers for a website
  • Refactoring existing plugins or frameworks for security and reliability
  • Offloading data management and processing to third-party services or external servers
  • Decoupling existing solutions to small, independent, and cohesive libraries or micro-applications for reliability
  • Refactoring some database queries in order to reduce the load to the MySQL database
  • Replacing existing plugins with lightweight alternatives that reduce the number of HTTP requests or database calls

Here are some of the most common mistakes reported by WordPress development teams when onboarding large businesses struggling with their existing WordPress websites.

WordPress Themes and Plugins

Common problems related to installing specific WordPress themes or plugins.

1. Bloated Multipurpose WordPress Themes

Multipurpose WordPress themes or complex premium themes often incorporate several sliders or galleries, introduce dozens of shortcodes, tons of widgets, and various scripts or styles for different purposes.

Complex WordPress themes try to provide a large subset of features for different industries. At the end of the day, business owners leveraging WordPress may utilize a small chunk of the features while inheriting the technical debt and complexity of the large theme. Using just 5% or 10% of the features provided by a premium theme will likely lead to stability issues, performance problems, or even security concerns for business owners.

Solution: Build a custom WordPress theme that is tailored to your business needs. Or use an established starter theme that is extremely lightweight and doesn’t include a ton of 3rd party scripts and styles that would increase the load times with several seconds.

2. Complex Slider Plugins

Some User Experience experts have discussed the usability concerns with sliders but they are still common and widely used across the web. However, sliders are complex components that require a lot of CSS for styling slides across different resolutions and with different effects and captions. All of that is handled through various scripts, some custom back-end logic handling the slide management, and media-related functions for scaling or cropping images on the fly.

Some popular sliders resemble Photoshop and other popular tools by introducing hundreds of different options for slide management. While this is acceptable for some small websites, this often has a massive impact on performance. Moreover, the large code base may lead to major security vulnerabilities as well.

Solution: Avoid large sliders and stick to a simple, custom-made slider whenever possible. Don’t include additional options for resizing images or handling dozens of different formats. Discuss that with your creative team and stick to your brand guidelines and the style guide that provides a limited set of image sizes and placements.

3. Visual Builders

Visual Builders provide non-technical marketers, content writers, and managers the ability to produce dynamic content with flexible layouts. However, many of the existing builders include dozens of available components and introduce a complex framework for handling data within your WordPress pages, posts, or custom post types.

As your WordPress website scales with time, a visual builder may impact the consistency of your data, affect the load times, or introduce regressions while updating your content. Different JavaScript errors introduced due to compatibility issues or ongoing updates may break your pages as well.

Solution: If possible, try to leverage a set of page templates that have a predefined number of sections and boxes for editing content in already defined locations. If a visual builder is a requirement, carefully assess the stability and reliability of the plugin before integrating it within your existing platform. The ongoing maintenance and management of your builder may require additional time and effort on a monthly basis in order to avoid regressions and scalability problems.

4. Multilingual Plugins

Multilingual plugins let website owners create content in several different languages. This is essential for large organizations serving different audiences across the globe.

However, different multilingual plugins solve various problems. Sometimes, an established plugin may handle a lot more than your web platform needs and affect the rendering cycle of a WordPress page. Moreover, handling multilingual content comes with various considerations when you account for multilingual menus or widgets, right-to-left languages, handling data for terms containing different results per language, displaying product details limited for different regions, handling geolocation and more.

Solution: Carefully discuss the right multilingual solution for your web application with your WordPress development team. Different multilingual plugins implement different strategies on a technical level. Some create additional database tables, others create new post entries for new languages. Some store all versions within the content area and handle it programmatically for each request. WordPress multisite is also a viable alternative for some businesses serving different content to different international audiences.

5. eCommerce Platforms

eCommerce platforms are essential for businesses selling goods or services online. There are various WordPress plugins and 3rd party services available on the market.

While there are no “right or wrong” choices out of the box, eCommerce platforms are extremely complex as they handle product management, orders, deliveries, payments and transactions, user management, shipping, among different options.

Some platforms like Easy Digital Downloads focus only on digital goods. This may be a suitable alternative if you don’t plan on selling physical items as your codebase won’t include all of the features dealing with product weights, quantities, international shipping, and more. However, platforms have developed different communities and add-on ecosystems. A powerful eCommerce store would likely need several additional add-ons in order to bring the right user experience to customers.

Solution: Conduct the right research on the best eCommerce platform for your store. Using a WordPress plugin within your main platform may be a good option if you’re integrating additional features available in your core website. Running a separate shop on a different install may be a viable alternative as well. There are third-party solutions that could be integrated into WordPress as well – depending on your business needs and performance considerations.

6. Membership Platforms

Membership platforms are another large vertical within the WordPress industry itself. There are plenty of ways to monetize a WordPress business and different exclusive access options are available for different plans.

By design, most of the popular membership plugins are large and complex. They have to deal with user management and roles, different payment plans, restricted content of some sort, protected directories and the like. A standard membership platform often relies on a number of 3rd party add-ons and extensions as well.

Solution: Introducing a new membership platform requires plenty of research upfront and deciding on the best option for the business model. There is a tool for every job and that depends on the rest of your WordPress architecture. Work along with your technical and product teams and analyze the roadmap carefully. There are different ways to incorporate a membership, community, LMS platform with a plugin that is suitable for your niche or plays well with other areas of your website – such as WordPress multisite, eCommerce, and the like.

7. Incompatible Plugins Activated Together

The WordPress plugin architecture is pretty solid, powerful, and extensible. That said, each and every plugin can tap into the pool of actions and filters and interfere with the standard WordPress core behavior.

As a result, it’s not uncommon for plugins to compete for the same hook and alter the life cycle in an unexpected manner. That’s especially common for several large and complex plugins active at the same time.

While this is partially something that plugin developers have to work on, there are plenty of realistic scenarios where plugins are implemented as they are supposed to and yet, there are discrepancies in the standard workflow.

Solution: Carefully designing the WordPress architecture is paramount. Avoid installing each and every plugin out there that could extend the feature set of your platform. Review new add-ons, extensions, and plugins together with your technical team. Test carefully and extensively on staging before pushing a new update on production.

WordPress Core Management

Various issues related to misusing the standard life cycle of the WordPress Core and missing some best practices for high-scale websites.

8. Useless Components Affecting the Life Cycle

There are certain plugin features that may impact the load times and interfere with the life cycle. Example being a contact form loading CSS and JavaScript across the entire site (including back-end) while being used in a single Contact Us page.

That may be the case with the WordPress Core itself, too. WordPress performs a certain number of checks or database requests for various purposes. A high-scale website may be affected by the additional back and forth in terms of performance and reliability.

Solution: Set up a vanilla WordPress install and carefully debug all of your main areas (the dashboard, the main front-end pages, some AJAX calls and external requests). Benchmark these as well. Compare that with your production system and see if you can exclude some of those components by removing callback functions, deleting options, replacing some heavy snippets with lightweight ones.

You may prevent some unnecessary calls checking for the currently active website language, the usage of comments, or the default generation of standard widgets.

9. Triggering Excessive AJAX Requests

Overusing AJAX may harm the overall user experience and hit the performance setup as well. Review the dynamic layers and see what part of those could be optimized accordingly.

This may be the case with sliders or parallax, galleries, lazy loading, refreshing data on the fly, internal validation or dynamically populated stock quantities in an eCommerce.

Solution: Keep an eye on your AJAX requests. Start a few sessions with anonymous and logged in users and monitor your ongoing requests. Consider a simplification or a better caching mechanism within your wp_ajax_* callback functions. See if a REST API callback would be suitable in some cases, extracting data in a separate data layer, or switching to a more streamlined solution which may be suitable when dealing with more data.

10. Phantom WP-Cron Calls

WordPress has a virtual cron job manager that is meant to execute scheduled jobs. It’s less reliable than a UNIX cron job since it’s dependent on the new requests toward the site (hence may be delayed or skipped in certain events). Moreover, different plugins may populate the pool of cron jobs and slow down your requests accordingly.

Solution: Review your existing scheduled jobs and keep an eye on plugins that may be populating these. In the event of a hiccup with your WP-Cron engine, you may end up with timeouts or even 500 requests due to slow queries or endless requests that can’t be processed for some reason.

11. Connecting to Widely Used Hooks

WordPress provides a large suite of hooks triggered in different parts of the life cycle. Some are isolated and available on specific screens or only when a component is fully loaded. Others are somewhat global and are available on numerous screens across your website – such as the entire admin dashboard or accessible on each and every request made to the website.

While certain components should be available everywhere, that’s not the case for many callbacks.

Solution: Based on your performance and stability reviews, consider excluding certain callback functions or moving them to the corresponding hooks. The WordPress life cycle is complex and it may take a while to identify the best filters or actions to leverage. Keep in mind cron jobs, AJAX callbacks or REST API endpoints. You can execute or dismiss various callbacks in order to optimize different requests across the site loaded from different services and applications.

12. Repetitive Internal Redirects

Internal redirects are commonly used for SEO purposes and often incorporated due to different activities across the website – ads, popups, dynamically fetched data. They could aim for the homepage of the website or an internal page – a lightweight request that still fetches a lot of data on the fly.

While some are inevitable, part of those requests can be avoided or at least cached for better performance, preventing security reports, and leading to a more stable workflow.

Solution: Inspect the number of internal redirects while rendering certain areas of your website. Try to decrease the number of required redirects or avoid them as a whole. Whenever internal redirects are required for some data processing reasons, make sure that caching is in place and you can leverage a valid data which is stored in the object cache or the page cache of your website.

13. Overusing WordPress APIs When Not Applicable

Leveraging the APIs provided by WordPress is usually a best practice and should be followed whenever that makes sense. Plugins are complying with the available WordPress APIs and can introduce additional behavior without extra programming.

However, WordPress is not designed to fit each and every use case out there. Large websites may be locked within the existing database architecture or the default admin interface for certain portions of their website – which may consecutively affect the overall performance.

Solution: Consider building certain layers of the website yourself. Stick to the WordPress architecture and API whenever possible and extend that when that would drastically improve the stability or performance. You can build micro-dashboards or separate pages leveraging the REST API for various sections of your website. Or create normalized database tables for data which doesn’t fit the standard schema designed in WordPress. Or build intermediate layers working beside your existing infrastructure.

Database Management

Various caveats when using the default WordPress database schema along with the way the WordPress Core works.

14. Default Content Management for Post Types/Taxonomies

Storing data in WordPress comes with certain best practices that are suitable in most use cases.

As discussed in the previous point, that’s not always the case for large websites that need to squeeze the best out of performance and stability.

For instance, WordPress post type entries are stored in the {prefix}_posts table and their meta data is populated in the {prefix}_postmeta table. Due to the nature of the schema, each meta field is stored as a separate row. That leads to growing the postmeta table immensely as your WordPress data grows as well.

Some plugins try to store metadata by serializing information within a single array and thus storing a single row. This makes the programmatic updates of serlialized data slower and more complex. Filtering in advanced search forms is even more challenging.

Solution: Consider extending the current database schema in a way that supports your business needs. You can create custom tables that store all of your required fields in one row – making it easier for searching, updating, filtering. Or introduce certain constraints in order to improve validation across different devices working with the same database. Don’t forget that this may require additional code for WP_Query calls or building your metaboxes in the dashboard.

15. Excessive Volume of Database Queries

This one is more common than not and could be caused by plugins, the theme, 3rd party services, and the WordPress core itself. A higher volume of database requests across the site impacts the stability and responsiveness of the database and serving database requests to different users.

Solution: Review the SQL queries generated by your WordPress plugins and your theme in different areas of your website. Some components may be disabled or moved to their corresponding pages. Other queries could be optimized. You can combine some queries by replacing them with more suitable ones and reduce the number of database requests as well.

Each business case is different. Object caching certainly helps (along with page caching) but that still impacts the first visitor after purging the cache. It also affects the database as a whole and adds on top of your dynamic, non-cached requests.

16. Storing Multimedia in the Database

For the most part, WordPress stores uploads and assets in the uploads/ folder within wp-content. Theme and plugin assets are usually served from within their corresponding folders or loaded externally.

Some document or video management solutions store data as BLOB entries in the database. While this makes sense in certain scenarios, it’s likely that this would have a massive impact on your overall load times within your database.

Solution: In case you’re storing data as BLOB entries, consider switching to an Amazon S3 bucket or another secure external storage with the right credentials and authentication for secure review and access. See if using a video hosting solution or another document management platform would fit into your WordPress architecture design, too.

17. Excessive Load of Autoloaded Options

WordPress stores various settings and options related to your website and config arguments from various plugins in the options table. Other than polluting the table if used improperly, the large volume of autoloaded options may impact the site speed and the database load when fetching tons of information that’s not widely used across the site.

The main idea of autoloaded options is running a single query that would pull the most widely used options across the website instead of a repetitive set of separate queries. The problem is that functions such as update_option for missing entries would create an option that is automatically loaded – thus frequently leading to hundreds of generic options stored in RAM.

Solution: Inspect the autoloaded options ran for every single page request. Update the ones that are not widely used or available only in the dashboard. Clean up the options table if some of those entries are no longer in use (deactivated plugins or upgrades).

Custom Code

Various issues related to programming new plugins and leveraging 3rd party solutions that are affecting the overall stability and productivity of the platform.

18. Omitting Established Design Patterns

PHP is a fairly flexible programming language that doesn’t necessarily define a tight set of best practices. There are different approaches to building a plugin or a framework and some are suitable for different use cases.

Given the WordPress Life Cycle and the variety of features that a website can incorporate, implementing some established design practices, sticking to the right WordPress APIs and deciding on the right approach for building a plugin’s architecture may be crucial for the long-term stability and reliability of your web application.

Solution: Always conduct an extensive code review of 3rd party plugins, libraries, and frameworks before incorporating in your platform. Carefully review the code produced by your WordPress team and refactor as needed.

19. Lack of Compliance with Scalability or Security

Custom WordPress plugins or themes may solve a multitude of problems for various industries. The best approach for building a large and scalable WordPress website is crafting custom-made solutions tailored to the business needs.

This results in a maintainable code base with less technical debt and overhead.

That is dependent on the technical team that has to pay attention at all times on stability and security. Implementing the best practices both in terms of WordPress standards and the business needs is of utmost importance. Always ensure that your application implements the right solutions and can scale without opening security leaks for non-authorized users.

Solution: Introduce some key indicators regarding speed and security for your application. When assessing a new solution, work along with a consulting company that specializes in penetration testing or at least utilize some of the available solutions on the market. Test your code base with a lot of production data in order to identify possible memory leaks. Run some load/stress tests in order to measure the resilience of your server environment.

20. Misusing the Default WordPress APIs

WordPress provides a set of APIs used by tens of millions of websites. WordPress developers may stick to the original design by adhering to the best practices when using the existing WordPress APIs.

There are several problems that could occur while building a new solution integrated in a new website.

  • Not using an API which would be a good fit for the application
  • Using the wrong functions or classes for an API that don’t utilize caching or would conflict with other available solutions (such as query_posts() vs. get_posts() vs. a new WP_Query object)
  • Overusing the WordPress APIs when a custom solution would be more applicable in terms of stability or scalability

Solution: Carefully revise the architectural decision when building a new component. Does a new admin page need the Settings API? Are custom fields suitable for the Metadata API or would rather require a new database table? Is running a custom database query for a subset of posts something that could be accomplished more efficiently with a WP_Query request?

21. Serializing Data During Filtering

Storing new information in the database could come in different shapes – utilizing the established APIs, serializing data, creating new database tables, offloading to 3rd party solutions.

There are certain scenarios where serializing data in order to prevent creating multiple new rows for a single entry may cause problems. Performing effective database queries dealing with advanced search or product filtering may be severely challenging for the database load and the overall website performance.

Solution: Decide on the right storage mechanism for your use case. Avoid polluting the database when it doesn’t make sense and make sure that features requiring filtering and advanced search can be implemented with effective database queries without a ton of internal processing or conversions.

22. Performing Custom Built Complex Search and Archive Queries

The standard database schema is overall effective in terms of populating new information and fetching standard archives or single views. Performing complex and conditional search and filtering queries may become a challenge for high-scale websites targeting customers who depend on a powerful search engine.

Certain solutions like Elasticsearch can be of help but they also depend on your original database storage.

Some themes may even affect strategic pages such as the homepage of the website. When fetching featured images for a list of popular posts or the published data, WordPress may trigger a separate query for each post instead of enumerating post IDs and fetching the entire data set in a query or two.

Solution: Complex queries, navigation, filtering, and search options should be discussed as early as possible. There are third party solutions and libraries that could ease the pressure from building a complex search engine within WordPress. Even standard requests require special attention. Benchmark your existing solution and decide on the best approach for building an effective engine that doesn’t perform slow queries or large sets of separate queries for the same type of problem.

23. Missing Minified and Combined Scripts and Styles

There is a limited number of parallel HTTP requests that a browser can make in order to render the full page. That includes the initial page load, images, CSS files, scripts, fonts, and 3rd party services.

Minifying the scripts and styles would reduce the size of those requests and speed up the load times (less bandwidth wasted during a request). Combining scripts and styles together will limit the number of consecutive requests performed by the browser while loading the page.

There are plenty of problems that may occur, though. Aligning scripts and styles in the right order is paramount – otherwise, you will break certain dynamic features or break the styling of a page due to overriding the wrong selectors. Some scripts should be added to the header while others have to stay in the footer – which may impact your decision, too.

Solution: Make the best out of minifying and combining scripts and styles for your WordPress website. Carefully test each and every feature in order to prevent regressions. Consider refactoring your code or extracting snippets from certain libraries that are carrying over plenty of unnecessary code base. Use precompilers for Sass or LESS in order to maintain your codebase in a more organized manner. Keep an eye when performing plugin updates which may affect the stability of your combined files. Test on different browsers that could report different issues for certain scripts.

24. Loading Fonts Offsite

Modern online businesses are no longer constrained to a limited subset of fonts for their digital presence. Which is why services such as Google Fonts or Typekit are that popular and widely distributed.

However, a default implementation or a wide range of fonts across the site may impact the load and render times and the look and feel of the site before loading all fonts.

Solution: Whenever possible, don’t load fonts from external resources. Typekit has occasional outages. All external resources may take a while to create a reliable connection and serve your fonts accordingly. At peak times, it’s possible that a paid fonts service may hit a limit and reject a request for fetching a certain font as well. Otherwise, make sure that you’re using suitable fallback fonts at all times.

Otherwise, make sure that you’re using suitable fallback fonts at all times. Switch to a very slow connection (such as GPRS tethering – could be triggered in some browsers) and see how your copy looks on different pages before the new fonts take effect.

3rd Party Services

Discussing the dependability and possible caveats whenever using 3rd party services.

Disclaimer: External services may be desirable in plenty of cases – but use them wisely and keep into account the possible repercussions.

25. Relying on Slow 3rd Party Services

A decent medium-sized or large/enterprise WordPress platform likely interacts with a number of 3rd party services – HubSpot or Salesforce, a number of analytics tools, an opt-in solution, a business-specific platform for car rentals, real estate listings, a job board integration and the like.

Different platforms are built in various ways. Some load JS scripts embedded on the site. Others have WordPress plugins that bridge the features accordingly. Some are implemented as iframes. Or require a set of REST/SOAP requests transferring data both ways.

While external solutions may reduce the impact on the database or the code triggered on the web server, it’s likely that the render times would be higher until all resources are loaded in their entirety. This may affect the load times and the customer experience whenever the page isn’t fully loaded and visitors see jumping boxes all over the place.

Solution: Always assess 3rd party services before integrating them in a WordPress platform. Consider the standard workflow. Review the required code base and what is the impact on the overall platform. Review all data stored in the WordPress database. See if the scripts required are loaded only in the designated areas. Consider the impact on loading a complete page and what is visible by customers in different scenarios. Keep in mind access control and rendering the right data to the right user roles if needed.

26. Hitting 3rd Party Limits

Working with 3rd party services may lead to reaching their limits. As a result, several things could happen – the 3rd party component may be disabled, an error may be displayed to your users, requests could be throttled thus slowing down your site – not to mention the surcharge that could follow. Consequences could vary dramatically depending on the case.

Solution: Carefully review the limitations of the service in use and ensure that the WordPress utilization sticks to the healthy limits. Build fallback handlers that would take care whenever those limits are reached. Moreover, protect yourself against downtime – third-party services could also face technical challenges and you don’t want to depend on these as a result.

27. Lack of Preprocessing Data Before Offloading

Sending data to a third-party is usually somewhat automated. However, dealing with large volumes of information in WordPress may lead to delays in processing a request, multiple queries to the same engine, or slower processing and filtering afterward.

This could be the case with lead generation or marketing automation tools, data analytics platforms and more.

Solution: Monitor your load times and the quality of the received data. Consider optimizing the outgoing data by preprocessing and filtering on the server side. If you control the external environment, consider packaging it up in a way that requires a single response and could serve the business needs without additional computation.

Note: the list will keep expanding with additional notes on SEO, media management, hosting, caching, security. Take a look at our Retainer plans if you’re interested in talking more.

The post 25+ Business Scaling Mistakes Running a Large WordPress Website appeared first on Mario Peshev.

Workarounds for the Page Template Bug in WordPress 4.9

WordPress 4.9 “Tipton” was released last week and although it’s largely trouble-free, there is one particular issue users and developers are running into that’s causing frustration. In 4.9, custom page templates that are created fail to display in the Template drop-down menu. The issue is related to changes made to the file editor.

Previous versions of WordPress listed files 2-levels deep in the editor. In 4.9, the entire directory tree for a theme is listed regardless of its depth. Caching was added to help limit the performance impacts of loading large WordPress themes. “An unintended side effect of the caching is that the same directory listing function get_files is used both for the theme editor and for gathering page templates,” Weston Ruter, Co-Release Lead for WordPress 4.9 said.

Within the trac ticket, developers suggests that a button be added that flushes all caches or disabling the cache if WP_DEBUG is set to true. Neither suggestion turned into a patch committed to core. Instead, Ruter has released a plugin as a workaround that flushes the template cache. Other workarounds include, bumping the theme’s version, running the wp cache flush command in WP CLI, or waiting 60 minutes for the cache to expire.

The ticket is marked as a high priority but because of the upcoming holidays in the US and WordCamp US next weekend, it could be at least a few weeks before WordPress 4.9.1 is released.

Tide Project Aims to Audit and Score WordPress Themes and Plugins based on Code Quality

Last week XWP dropped an intriguing preview of a new project called Tide that aims to improve code quality across the WordPress plugin and theme ecosystems. The company has been working with the support of Google, Automattic, and WP Engine, on creating a new service that will help users make better plugin decisions and assist developers in writing better code.

XWP’s marketing manager Rob Stinson summarized the project’s direction so far:

Tide is a service, consisting of an API, Audit Server, and Sync Server, working in tandem to run a series of automated tests against the WordPress.org plugin and theme directories. Through the Tide plugin, the results of these tests are delivered as an aggregated score in the WordPress admin that represents the overall code quality of the plugin or theme. A comprehensive report is generated, equipping developers to better understand how they can increase the quality of their code.

The XWP announcement also included a screenshot of how this data might be presented in the WordPress plugin directory:

XWP plans to unveil the service at WordCamp US in Nashville at the Google booth where they will be inviting the community to get involved. Naturally, a project with the potential to have this much impact on the plugin ecosystem raises many questions about who is behind the vision and what kind of metrics will be used.

I contacted Rob Stinson and Luke Carbis at XWP, who are both contributors to the project, to get an inside look at how it started and where they anticipate it going.

“Tide was started at XWP about 12 months ago when one of our service teams pulled together the idea, followed up by a proof of concept, of a tool that ran a series of code quality tests against a package of code (WordPress plugin) and returned the results via an API,” Stinson said. “We shortly after came up with the name Tide, inspired by the proverb ‘A rising tide lifts all boats,’ thinking that if a tool like this could lower the barrier of entry to good quality code for enough developers, it could lift the quality of code across the whole WordPress ecosystem.”

Stinson said XWP ramped up its efforts on Tide during the last few months after beginning to see its potential and sharing the vision with partners.

“Google, Automattic and WP Engine have all helped resource (funds, infrastructure, developer time, advice etc) the project recently as well,” Stinson said. “Their support has really helped us build momentum. Google have been a big part of this since about August. We had been working with them on other projects and when we shared with them the vision for Tide, they loved it and saw how in line it is with the vision they have for a better performant web.”

The Tide service is not currently active but a beta version will launch at WordCamp US with a WordPress plugin to follow shortly thereafter. Stinson said the team designed the first version to present the possibilities of Tide and encourage feedback and contribution from the community.

“We realize that Tide will be its best if its open sourced,” he said. “There are many moving parts to it and we recognize that the larger the input from the community, the better it will represent and solve the needs of the community around code quality.”

At this phase of the project, nothing has been set in stone. The Tide team is continuing to experiment with different ways of making the plugin audit data available, as well as refining how that data is weighed when delivering a Tide score.

“The star rating is just an idea we have been playing with,” Stinson said. “The purpose of it will be to aggregate the full report that is produced by Tide into a simple and easy to understand metric that WordPress users can refer to when making decisions about plugins and themes. We know we haven’t got this metric and how it is displayed quite right. We’ve had some great feedback from the community already.”

The service is not just designed to output scores but also to make it easy for developers to identify weaknesses in their code and learn how to fix them.

“Lowering the barrier of entry to writing good code was the original inspiration for the idea,” Stinson said.

Tide Project Team Plans to Refine Metrics Used for Audit Score based on Community Feedback

The Tide project website, wptide.org, will launch at WordCamp US and will provide developers with scores, including specifics like line numbers and descriptions of failed sniffs. Plugin developers will be able to use the site to improve their code and WordPress users will be able to quickly check the quality of a plugin. XWP product manager Luke Carbis explained how the Tide score is currently calculated.

“Right now, Tide runs a series of code sniffs across a plugin / theme, takes the results, applies some weighting (potential security issues are more important than tabs vs. spaces), and then averages the results per line of code,” Carbis said. “The output of this is a score out of 100, which is a great indicator of the quality of a plugin or theme. The ‘algorithm’ that determines the score is basically just a series of weightings.”

The weightings the service is currently using were selected as a starting point, but Carbis said the team hopes the WordPress community will help them to refine it.

“If it makes sense, maybe one day this score could be surfaced in the WordPress admin (on the add new plugin page),” Carbis said. “Or maybe it could influence the search results (higher rated plugins ranked first). Or maybe it just stays on wptide.org. That’s really up to the community to decide.”

In addition to running codesniffs, the Tide service will run two other scans. A Lighthouse scan, using Google’s open-source, automated tool for improving the quality of web pages, will be performed on themes, which Carbis says is a “huge technological accomplishment.”

“For every theme in the directory, we’re spinning up a temporary WordPress install, and running a Lighthouse audit in a headless chrome instance,” Carbis said. “This means we get a detailed report of the theme’s front end output quality, not just the code that powers it.”

The second scan Tide will perform measures PHP compatibility and will apply to both plugins and themes.

“Tide can tell which versions of PHP a plugin or theme will work with,” Carbis said. “For users, this means we could potentially hide results that we know won’t work with their WordPress install (or at least show a warning). For hosts, this means they can easily check the PHP compatibility before upgrading an install to PHP 7 (we think this will cause many more installs to be upgraded – the net effect being a noticeable speed increase, which we find really exciting and motivating).”

Carbis said that the team is currently working in the short term to get the PHP Compatibility piece into the WordPress.org API, which he says could start influencing search results without any changes to WordPress core.

“We’d also like to start engaging with the community to find out whether surfacing a Code Quality score to WordPress users is helpful, and if it is, what does that look like? (e.g. score out of 100, 5 star rating, A/B/C/D, etc.),” Carbis said. “We will release our suggestion for what this could look like as a plugin shortly after WordCamp US.”

More specific information about the metrics Tide is currently using and how it applies to plugins and themes will be available after the service launches in beta. If you are attending WordCamp US and have some suggestions or feedback to offer the team, make sure to stop by the Google sponsorship booth.

Ask Yoast: changing URL structure and rankings

If you started your website as a newbie to all things internet, chances are that your site’s URLs aren’t pretty. Perhaps the URLs contain the post-ID, or the date when it was first published. URLs like that don’t say much about the content of a page and look cluttered. If you want to change your URL structure for this reason, or whatever other reason, it could affect your rankings. In this Ask Yoast, I discuss to what extent changing your URL structure will have an impact on your rankings, and if it’s still worth the effort.

Chris asked us a question on this subject:

We are changing our URL structure to make it look cleaner (by leaving out numbers etc.). When we launch our new site, will this new URL structure negatively affect our existing Google rankings?

Watch the video or read the transcript further down the page for my answer!

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

The impact of changing your URL structure on rankings

Well, if you launch a new site and you have new URLs, you’ll need to redirect all the old URLs to the new URLs and it’ll take some time for Google to pick up that those URLs have changed. If you’re staying on the same domain name, your traffic will probably stay the same, but you will need to redirect all those URLs and it might take some time.

You might lose some traffic for a while, up to even six months and then after that everything should be fine. It’s probably worth it if your URLs look really bad though, so it’s a trade-off but I’d probably still go for it. Good luck!

Ask Yoast

In the series Ask Yoast we answer SEO questions from our readers. Have an SEO-related question? Let us help you out! Send an email to ask@yoast.com.
(note: please check our blog and knowledge base first, the answer to your question may already be out there! For urgent questions, for example about our plugin not working properly, we’d like to refer you to our support page.)

Read more: ‘The perfect WordPress SEO permalink structure’ »

The post Ask Yoast: changing URL structure and rankings appeared first on Yoast.

Consultants Are WordPress’ Boots on the Ground

A business can’t survive without strong sales & customer service, two competencies that are arguably the lifeblood of a company.

Many of you reading this fill that exact gap for the open source WordPress project. I don’t mean this as a slight to the thousands of wonderful people who build the software, document it, and support it in the forums, but that consultants (doing it right or wrong) are also fueling this locomotive too.

There are no official sales or customer service channels at WordPress.org and us consultants bear the brunt of it — for better or worse — and that’s where our job comes in. Just as you trust a core contributor to spot-check her code and ensure that we’ve sanitized all the things!

Consultants are the boots on the ground, and as you’ll see below in my feedback section, represent a disproportionate ratio of launching many more websites than an individual website owner. – Matt Medeiros

From The blue-collar WordPress worker and the 2,500+ websites built to grow the CMS.

WordPress 4.9 Released with Major Improvements to Customizer Workflow, Updated Code Editors, and New Core Gallery Widget

WordPress 4.9 “Tipton” was released today, named for Oklahoma-born jazz musician William Lee Tipton, a gifted pianist and saxophonist. This update introduces major improvements to the design and collaboration workflow in the Customizer, improves WordPress’ built-in code editor, and enhances core text and media widgets.

Draft, Schedule, and Preview Changes in the Customizer

Prior to 4.9, users could get a live preview of their sites in the Customizer but any changes they made would need to be saved immediately or discarded. This update makes it possible to draft and schedule changes in the Customizer, and even share a preview link to collaborate on changes before making them live. Users can now stage content, such as new pages, a new set of widgets, a different combination of menu items, and schedule it all to publish at a future date.

This release also brings the ability to search, browse, and preview themes directly in the Customizer. The search interface includes filters for subject, features, and layout, just like the ones on the “Add Themes” screen in wp-admin. It does not yet include the featured, popular, latest, or favorites tabs, so users will need to navigate back to the admin if they want to browse those categories.

The menu creation process has also been updated in the Customizer to be less confusing with a rethink of the UI and revised copy.

Syntax Highlighting and Error Checking Added to the Code Editors

WordPress 4.9 brings syntax highlighting, linting, and auto-completion to the built-in code editors by incorporating the CodeMirror library. These long-awaited improvements are now available in the theme and plugin editors as well as the custom HTML widget and additional CSS box in the Customizer. The feature comes with prominent warnings about directly editing themes and plugins and protection against saving code that would cause a fatal error.

New Core Gallery Widget and Support for Shortcodes and Embedded Media in the Text Widget

WordPress 4.9 adds a new gallery widget to the collection of core media widgets (audio, image, and video) that were introduced in 4.8. It brings the same gallery-creation features to widgets that have long been available in the post and page editors.

These incremental changes will help users get ready for Gutenberg’s block-based interface. The plan is to eventually transition widgets over to blocks after Gutenberg is in core and the plugin already has support for a gallery block, as well as a Custom HTML block.

As of 4.9, users can now embed media in the Text widget, including images, video, and audio by clicking the “Add Media” button. In order to make this possible, WordPress contributors also needed to add shortcode support to widgets, a feature that users have requested for nearly a decade. With this now built into core, hundreds of thousands of WordPress sites will no longer need additional code from plugins and themes to use shortcodes in widgets.

Widgets have also been improved to offer a better migration experience with updated logic for mapping widgets between two themes’ widget areas.

On Towards Gutenberg

WordPress 4.9 also includes a notice in the about.php page of the admin, inviting users to help test or contribute to Gutenberg. It is the first time a feature plugin has been highlighted so prominently on the page users see after they update to the latest version.

The Gutenberg project has been getting a lot of attention over the past few months as the WordPress community looks ahead to the 5.0 release that will introduce the new editor to the world. Meanwhile, contributors to 4.9 have been working in tandem to make significant improvements to existing features, enabling users to do more with widgets and overall site design than ever before. This release was led by Weston Ruter and Mel Choyce with help from 443 contributors, 42% (185) of them contributing to WordPress for the first time.

How to Fix Secure Connection Error in WordPress

Are you seeing ‘Unable to establish secure connection error’ in WordPress? It is a common WordPress error and usually occurs when you are trying to install or update a WordPress plugin or theme from official WordPress.org directory. In this article, we will show you why this error occurs and how to easily fix secure connection error in WordPress.

Fixing secure connection error in WordPress

What Causes Unable to Establish Secure Connection Error in WordPress?

WordPress comes with a built-in system to manage updates. This system regularly checks for updates and show notifications for you to install plugin / theme updates.

However, it needs to connect to the WordPress.org website in order to check for updates or install them. Due to some misconfiguration on your WordPress hosting server, your website may fail to connect with WordPress.org website.

This will result in a secure connection error, and you will see an error message like this:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /home/username/public_html/wp-admin/includes/update.php on line 122

Secure connection error in WordPress

That being said, let’s see how to easily fix secure connection error in WordPress.

Fixing Secure Connection Error in WordPress

There are multiple ways to fix the unexpected secure connection error in WordPress. You can try one of the following solutions based on your situation.

Hosting and Server Related Issues

If your shared hosting server is under DDoS attack, then it is likely that the connection to WordPress.org will timeout causing the secure connection error.

In that case, you can wait for a few minutes and try again. If the error persists, then you need to reach out to your web hosting company’s support team.

Cloud or VPS Server Connectivity Issue

If you are on a cloud or VPS hosting, then it is possible that your server is unable to connect to WordPress.org due to some DNS issues.

In that case, you can point your server directly to WordPress.org servers. You will need to connect to your server using SSH.

SSH is short for secure shell which is an encrypted protocol that allows you to connect to your server using command line tools.

Windows users can use a tool called PuTTy whereas Mac / Linux users can use the terminal app.

You will need login credentials for the account with shell access to your hosting account. You can get this information from your hosting account’s cPanel dashboard or ask your web hosting server provider.

In the terminal, you can connect to your server like this:

ssh username@example.com

Don’t forget to replace username with your own username and example.com with your own domain name.

Once connected, you need to run the following command:

sudo nano /etc/hosts

This will open a file, and you will need to add the following code at the bottom of the file: api.wordpress.org

You can now save your changes and exit the the editor. Visit your website to see if this resolved the error.

Fixing WordPress Secure Connection Error on Localhost

If you are running WordPress on your own computer (localhost), then you may not have cURL extension enabled for PHP. This extension is required to access WordPress.org for updates.

You will need to edit the php.ini file on your computer. This file is usually located in the PHP folder of your Mamp, Xampp, or WAMP folder.

If you are on a Windows computer, then look for the following line:


Mac and Linux users would have to look for this line:


Now you need to remove the semicolon before the text to enable the extension. Don’t forget to save your php.ini file.

Lastly, don’t forget to restart the Apache server for changes to take affect.

Check Open Ports in Firewall

If cURL extension is properly installed on your local server, then the next step is to check your internet connection firewall.

Your computer’s firewall may be blocking outgoing connections from local server to WordPress.org. If you are on Windows, then press the start button and search for Windows Firewall. Mac users can find firewall settings in System Preferences » Security & Privacy

You need to add Apache to your firewall’s allowed programs and allow both incoming and outgoing connections.

Firewall Apache

You will need to restart Apache for changes to take effect.

We hope this article helped you solve the WordPress secure connection error. You may also want to see our ultimate step by step WordPress security guide for beginners.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Fix Secure Connection Error in WordPress appeared first on WPBeginner.

How to Remove v=XXXX string from WordPress URLs

Are you seeing strange v=xxxx string in your WordPress URLs? Recently, one of our readers asked us how to get rid of v=xxxx string from their WordPress URLs. This string is made up of seemingly random letter and numbers added as a parameter to your permalinks. In this article, we will show you how to easily remove v=xxxx string from your WordPress URLs.

How to Remove v=xxxx string from WordPress URLs

Why Are You Seeing v=XXXX String in Your WordPress URLs?

This string appears on websites running an online store using WooCommerce. It is not a bug or an error, but an actual feature of the plugin.

String with letters and numbers added to WordPress URLs by WooCommerce

The purpose of this string is to help WooCommerce calculate tax and shipping based on a user’s geographic location. The string helps make the feature compatible with WordPress caching plugins like WP Super Cache or W3 Total Cache.

However, if you don’t need to calculate shipping and taxes based on different locations, then you probably accidentally enabled this feature.

Let’s take a look at how to easily disable it and remove the random v=xxxxxx strings from your WordPress URLs.

Removing v=xxxx String from WordPress URLs

First you need to login to your WordPress admin area and head over to the WooCommerce » Settings page.

Under the General tab, you need to scroll down to ‘Default customer location’ option.

Disable Geolocation

It would be set to ‘Geolocate (with page caching support)’. You need to change it to either ‘No location by default’ or ‘Shop base address’.

Don’t forget to click on the save changes button to store your settings.

If you are using a caching plugin, then you will need to clear your WordPress cache. After that you can visit your website, and the geolocation string will disappear from your WordPress URLs.


How to GeoLocate Default Location Without the URL String?

You can do that by selecting the ‘Geolocate’ option in the ‘Default customer location’ setting.

Geolocate without caching

However, this option is not compatible with static caching plugins, and it will show incorrect shipping and tax information to users due to previously cached page.

Running WooCommerce without caching is not recommended because it will slow down your site’s speed and performance.

If you must use Geolocate to calculate shipping and taxes on the fly, then for the time being you will have to tolerate the ugly v=xxxx string in your WordPress URLs.

We hope this article helped you learn how to remove v=xxxx string from your WordPress URLs. You may also want to see our ultimate list of the most common WordPress errors and how to fix them.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Remove v=XXXX string from WordPress URLs appeared first on WPBeginner.

Gutenberg Contributors Explore Alternative to Using iframes for Meta Boxes

The discussion surrounding the use of iframes for meta boxes in Gutenberg became more heated over the weekend, as concerned developers implored the team to consider the detriments of the current approach. Responses from Gutenberg’s leadership initially deflected concerns, presenting the iframe implementation as an experiment that “works ‘for now'” but isn’t what the team would ship.

Instead of getting a response to the specific concerns about performance and accessibility of the iframes approach, Kevin Hoffman was urged to think about the future of meta boxes and “the cases (if any) that would not be converted to blocks.” When the developer community is repeatedly asked to test and offer feedback but is met with deflection on issues that are critical to sites using WordPress as a CMS, the GitHub discussions begin to get more heated.

“People are worried, and getting frustrated and it seems to me that they have every right to do so because the perception is that the team working on Gutenberg has little understanding of how meta boxes are being used, little concern for what the impact will be, and is going to move forward with their vision no matter what,” Jimmy Smutek, lead developer at the office of external affairs at Johns Hopkins, said in response to a Gutenberg collaborators’ admission to having been dismissive of feedback.

After several rounds of developers joining the thread to debunk the notion that iframes for meta boxes “work for now,” Gutenberg lead developer Matias Ventura joined the discussion yesterday and confirmed that the experiment is likely to be dropped fairly soon.

“I’m glad the conversation refocused in the end to the topic’s issue: is the current approach to meta-boxes in an iframe viable? With the answer being no,” Ventura said. “The iframes are an implementation detail I think we can drop relatively easy. So let’s focus on that.”

He also addressed the popular opinion that WordPress should make iterative enhancements to the editor itself (and not the full page) before proceeding with overhauling meta boxes.

“What some people have called as the pragmatic approach is not concomitant with the design direction this project has had from the start — heading towards full site customization — and what has dictated our decisions so far,” Ventura said. “Nothing here has to be a final solution, we are exploring what is possible within the design premises and putting it out there for testing.”

Ventura said that not making changes to the other aspects of the edit screen would certainly be the simplest path for Gutenberg to take but that it “would not be fair to the goals of the project and the long term users of WordPress.”

WordPress developer Gary Jones contended that pursuing a more iterative approach would not change the goals of the project but would make it possible for more sites to come along during the process.

“Going one step at a time does not, in any way, compromise the goals of the project,” Jones said. “You can still head to full-size customization if that’s the goal, but by doing it in a stepped way, you’ll bring the rest of the developer community along with you.” Jones cited the Customizer as an example of a feature within WordPress with a concept that is being realized over time with many iterations.

Ventura responded with clarification on the Gutenberg team’s approach to iterating on the project, a paradigm shift that supports block-based content creation from the outset.

“We have proposed a staged approach, from Matt’s original new focuses post, it just considers the steps differently,” Ventura said. “There are generally three stages for the Gutenberg project: from the post editor, to page templates, to site building. What is primordial is that the paradigm is one where the content is a single area, with the block as the primary concept, and where the outcome can be visually represented with clarity and without excessive abstractions.”

Ventura also assured those following along on the discussion that the project will not be dropping support for meta boxes but needs more time to experiment with different interface options.

“WordPress always moves with the user, and we take the burden of figuring out development paths to ease transitions for our existing code,” he said. “As a project, we have said before that we were not dropping support for meta-boxes from WordPress, but also that we had to explore what interface decisions we would have to make within the new paradigm, including the possibility of loading the classic editor when we detect meta-boxes we cannot handle or that directly conflict with an editor that seeks to more clearly delineate what is content and what is meta-data.”

He also said the team plans to create more mechanisms to handle incompatibilities as well as “allowing more things to be opt-in (say if you are comfortable with your meta-boxes showing in Gutenberg you could declare support for it, or vice versa.”

A new approach to rendering meta boxes without using iframes is currently underway. Riad Benguella has created a pull request that attempts to undo the iframes and implement a suggestion that Tom Nowell offered during the discussion:

Instead of loading Gutenberg on a settings page, lets load it into the main classic editors page, load metaboxes in their native environment, then hoist their container DOM node into a component via JS.

We then use a different kind of toggle to make sure the classic editor can still be used. This way:

– we avoid the iframe nonsense
– metaboxes work as they always have done as far as registration is concerned
– the existing JS works as expected, and no hacks are necessary to make things work on the PHP end

The new approach has the advantage of no problems with links, modals, duplicate stylesheets, and the other drawbacks to using iframes.

The Gutenberg Team Needs a New Communication Strategy

The discussion regarding the long-term viability of using iframes for meta boxes has highlighted a lack of a unified message or communication strategy among Gutenberg leads. Collaborators on the project have grown impatient with the community for not grasping the vision, but communication is scattered across various blogs, comments, Slack channels, and GitHub discussions.

Morten Rand-Hendriksen has opened a new issue requesting a centralized resource that can serve as a plain language outline of Gutenberg’s scope, direction, and goals.

“My observation is the community is struggling to see the wider scope of the Gutenberg project due to lack of a single authoritative plain language resource containing this information,” Rand-Hendriksen said. “This creates a high degree of speculation, miscommunication, and frustration from all parties and the project suffers as a consequence.”

Gutenberg does have a documentation hub, but so far those documents are more technical and lack a practical roadmap for how the team is aiming to accomplish its goals. The FAQ section of the current docs is the closest thing to the plain language resource that Rand-Hendriksen is requesting in his ticket. The readme.txt files for both Gutenberg’s GitHub repository and the WordPress.org plugin give the impression that the project is simply updating the current editor to be block-based, not overhauling the entire editor screen.

“Due to the fractured nature of this information it is challenging for anyone to get a clear picture of the entire project, and though Matias and Matt’s posts do a good job at explaining the grand vision of the project, they lack concrete plain language breakdowns of the essentials the community need to get a firm understanding of what this project is and where it’s headed,” Rand-Hendriksen said. “They also exist as independent satellites of information circling the project rather than core parts of the project itself.”

The community is chiming in on the GitHub issue with questions they would like to see answered in a more transparent plain language product roadmap. A document like this might help the Gutenberg team to better communicate the goals of the project and avoid sending mixed messages that cause unnecessary confusion.

Thoughts on Gutenberg

There has been lots of discussion about the new WordPress "Gutenberg" project. Some people love it, some hate it, and most WP users probably have no idea about it. And that's too bad, because it means many changes will be required for thousands of WordPress plugins and themes. We're talking about MANY collective work hours to make it happen, even in a best-case rollout scenario.


How to Track User Engagement in WordPress with Google Analytics

Are you properly tracking user engagement on your WordPress site? User engagement is one of the most important metric to track because it helps you strategically plan for growth. In this article, we will show you how to track user engagement in WordPress with Google Analytics.

Tracking User Engagement

Why Track User Engagement with Google Analytics

Generally, website owners consider traffic and pageviews as the most important indicators of their website’s performance. They assume that higher traffic will result into more conversions and sales.

While that is true, you can get even better results by tracking and optimizing user engagement.

User engagement shows you what users do when they arrive on your website. It helps you identify patterns of highly engaged user behavior which leads to more conversions and sales.

For example, you may realize that users visiting a specific page are 10X more likely to make a purchase vs any other visitor on your website. You can use this insight to redirect more user’s attention to that page.

To track user engagement on our websites, we use Google Analytics in combination with the popular MonsterInsights plugin.

If you haven’t already signed up for Google Analytics, then you can follow the instructions in our guide on how to install Google Analytics in WordPress.

Next, you need to install and activate the MonsterInsights plugin. We recommend getting the Pro plan of this plugin.

Now most people ask us why install a plugin, when you can just paste the Google Analytics script in the footer of the website.

The reason is that by simply pasting a link in the footer, you miss out on key user engagement data. You won’t know which outbound links are users clicking, which forms have the highest conversions, which products in your online store has the best conversions, which affiliate links or ads are getting the most clicks, etc.

MonsterInsights plugin automatically handles all of that and more for you. It automates the process of pasting different analytics code and event tracking scripts in the footer, so you don’t have to deal with the hassle of code and configuration.

Once you have setup Google Analytics with MonsterInsights, let’s take a look at how to track different user engagement metrics for your site.

1. Tracking Your Most Popular Content

The first thing you want to figure out is which blog posts and pages are the most popular amongst your users? These are the pages and posts on your website getting the most traffic.

Figuring out what your users like on your site can help you plan a content strategy that expands on what’s already working.

MonsterInsights makes it really simple. You just need to visit Insights » Reports page in your WordPress admin area.

You will find your most popular content under the ‘Top posts and pages’ section.

Most popular content

Next to it, you’ll also see your top traffic sources. This gives you a general idea of where your traffic is coming from.

On most websites, 90% of their traffic goes to 10% of the top pages. Once you find these top pages, you can optimize them for maximum conversions by adding content upgrades or targeted lead magnets on these posts.

We find that by adding content upgrades can help you boost your conversions by as high as 845%. Our founder Syed Balkhi has a blog post sharing the case study results.

2. Tracking How Users Engage with Forms on Your Website

Most websites rely on contact forms to collect user leads and feedback. Sadly most contact form plugins don’t give you accurate tracking and conversions data.

MonsterInsights lets you leverage Google Analytics’ events tracking feature to see how many times your forms are viewed and submitted.

To enable forms tracking, you need to visit Insights » Addons page. On this page, you will need to install and activate the Forms addon.

Install Forms Addon for MonsterInsights

Once you have activated the Forms addon, MonsterInsights will automatically start tracking all forms on your website.

It automatically works with popular contact form plugins like WPForms, Ninja Forms, Formidable, and others. MonsterInsights also track your website comment form, user registration forms, and more.

To see how your forms are doing, you will need to visit your Google Analytics account. In the Google Analytics dashboard, click on Behavior » Events » Overview page and then under ‘Event Category’ click on ‘form’.

Form tracking in Google Analytics

Next, you need to click on the ‘Event Label’ to see stats for different forms on your website.

Sort by form label

From there, you can click on any form to see your impressions and conversions.

Form impressions and conversions

3. Tracking Ecommerce Stores in Google Analytics

Google Analytics offer many features specifically for eCommerce websites. However these features are not turned on by default, and most users don’t even know that they exist.

Enhanced Ecommerce tracking lets you see shopping behavior, checkout behavior, product lists performance, sales performance, and so much more. The best part is that you can combine this data with your overall website traffic to gather better insights.

MonsterInsights eCommerce tracking for WordPress works with both WooCommerce and Easy Digital Downloads.

First, you will need to enable eCommerce tracking in Google Analytics. Head over to your Google Analytics account and switch to the admin page.

Google Analytics admin

Next, you need to click on the ‘Ecommerce Settings’.

Ecommerce settings

Now click the slider under the first step, Enable Ecommerce, to turn it on. You need to click on the Next Step button to continue.

Enable eCommerce tracking

We also recommend that you turn on the Enhanced Ecommerce settings.

Enhanced ecommerce

Once you are done, click on the submit button to store your settings.

Next, you need to switch to your WordPress admin area. Go to Insights » Addons page and install and activate the ‘Ecommerce Addon’.

MonsterInsights ecommerce addon

After that you can head over to Insights » Settings page and click on the tracking tab. Next, click on the Ecommerce section to continue.

Enhanced eCommerce tracking

On this tab, you need to check the box next to ‘Use Enhanced eCommerce’ and then click on ‘Save changes’ button to store your settings.

To view your ecommerce tracking reports, you need to visit your Google Analytics account and go to Conversions » Ecommerce page.

Ecommerce tracking

Here are a few powerful reports you get by enabling Enhanced eCommerce tracking on your store:

  • Shopping Behavior
  • Checkout Behavior
  • Product Lists Performance
  • Sales Performance

For more details on each of these reports, see this article on adding Google Analytics enhanced ecommerce to your website.

4. Tracking Who’s Clicking on Your Ads with Google Analytics

Many websites rely on ads to make money online while creating useful content. Advertising platforms like Google AdSense provide you some reports on ad impressions and clicks.

However, with MonsterInsights and Google Analytics you can actually see how users interact with ads on your site. You’ll be able to:

  • Track how many clicks each ad is receiving
  • Discover which ads your audience are ignoring
  • Identify the most effective ad placements
  • And more…

First you will need to visit Insights » Addons page on your WordPress site. Now install and activate the ‘Ads Tracking’ addon.

Ads tracking addon

Next, you need to integrate Google Analytics to your Google Adsense account.

Head over to your Google Analytics dashboard and click on the ‘Admin’ button located at the bottom left corner of the screen.

Switch to the Google Analytics Admin section

On the admin page, click on ‘AdSense linking’ under the property column.

Linking AdSense

Next, you need to click the +New AdSense Link button and then select AdSense property that you want to link with your Analytics property.

Select and link AdSense property

After that, click on the continue button to move forward.

Next, you need to select the Analytics view in which you want your AdSense data to be available. Once you select that click Enable Link and then click Done.

Adsense link setup

After you have configured everything in Google Analytics, you need to head over to your WordPress site and go to Insights » Settings page. Switch to the ‘Tracking’ tab and then click on the Ads section.

You need to Enable Google Adsense tracking in MonsterInsights.

Enable Adsense tracking in Google Analytics with MonsterInsights

To view your AdSense performance reports, go to your Google Analytics account and visit Behavior » Publisher page.

Adsense reports

The overview report gives you a high-level summary of key AdSense metrics. You can also find the Publisher Pages and Publisher Referrers report in Google Analytics.

5. Tracking Your Affiliate Links in Google Analytics

Most affiliate marketers use plugins to manage and cloak affiliate links. This makes your affiliate links look more user-friendly. Here is an example of a cloaked affiliate link:


MonsterInsights allows you to track those affiliate links in Google Analytics. This helps you figure out which affiliate products are doing well, which pages are generating more affiliate revenue, and more.

To enable Affiliate link tracking, you need to visit Insights » Settings page. Switch to the tracking tab and then click on ‘Affiliate links’ section.

Affiliate link tracking in MonsterInsights

First you need to enter the slug you use for your affiliate links. After that, you need to provide a label you would like to use for those links in your Google Analytics reports.

Next, click on the save changes button to store your settings.

MonsterInsights lets you track affiliate clicks as events in Google Analytics.

To find an overview of your affiliate link clicks report, you can go to Behavior » Events » Overview page. Your affiliate link clicks will be shown with the label you chose earlier.

Affiliate link reports

For more detailed instructions, see our guide on how to track outbound links in WordPress.

Note: most WordPress affiliate plugins may promise to give you link stats. We have found most of those stats to be highly inaccurate because most WordPress based analytics tracking breaks due to caching. Google Analytics is the only way to properly track analytics.

6. Tracking Bounce Rate in Google Analytics

Bounce rate is the percentage of users who land on your website and decide to leave without going to a second page.

To check your website’s bounce rate, you need to login to your Google Analytics dashboard and then go to Audience » Overview page.

Checking bounce rate in Google Analytics

Want to see an individual page’s bounce rate? Head over to Behavior » Site Content » All Pages to see all pages from your website.

Checking bounce rate for individual pages

You can sort the pages by higher or lower bounce rate to see which pages are not performing.

Higher bounce rate indicates that you were unable to convince the user to visit other pages. Users can leave your website by clicking on the back button in their browser, clicking on an outgoing link, or by closing the window.

Bounce rates are completely normal. However higher bounce rates indicate problems with your website affecting user experience and causing low conversions / engagement.

What should be the acceptable bounce rate for your website?

Here is a general breakdown of bounce rate from good to bad.

An excellent bounce rate is between 30% and 50%. However, most websites fall between 50% and 70% bounce rate which is an acceptable average. Bounce rates higher than 70% are considered poor for most websites.

Not all websites are the same which means average bounce rate vary depending on different kind of websites.

Take a look at the chart below to see an average bounce rate by industry:

Bounce rate average by industry

For more on this topic, see this article with tips to reduce bounce rate on your website.

7. Tracking Time Spent on Your Website

Another indicator that shows user engagement is session duration or time users spend on your site.

If users are abandoning your site without spending enough time to look at it, then something is wrong that needs to be fixed.

Google Analytics can show you the average time users spend on your site per session. Simply go to Audience » Overview page, and you will see it among other stats.

Average time spend per session

It can also show you how much time users spend when viewing individual pages. You can check it by visiting Behavior » Site Content » All Pages page in Google Analytics.

Time spent on individual pages

To learn how to improve session durations, take a look at this article with practical tips to increase time users spend on your website.

8. Tracking Page Views Per Visit with Google Analytics

Page views per visit is another great indicator of how engaged your users are. More page views per session also increases time users spend on your site and decreases bounce rates.

Google Analytics will show you the total page views for a given period on Audience » Overview page. However, to track user engagement you also want to see page views per session.

Tracking page views in Google Analytics

You can also break down page views per session by source and channel by visiting Acquisation » All Traffic » Channels page.

Pages per session by channel

This helps you see which traffic channels are converting the best for your website, so you can focus your efforts on areas that are actually driving results.

We hope this article helped you track user engagement in WordPress with Google Analytics. You may also want to see our ultimate step by step WordPress SEO guide and email marketing 101 guide for beginners.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Track User Engagement in WordPress with Google Analytics appeared first on WPBeginner.

New WordPress Security Plugin: Host Header Injection Fix

[ HHIF (Host Header Injection Fix) ] Since version 2.3, WordPress has been vulnerable to a Host Header Injection attack in certain server environments. Over the years, there has been some discussion about fixing the vulnerability, but as of WP 4.9 (beta) nothing has been implemented. So to help those in the WP community who may be concerned (including myself), I developed a new security plugin that fixes the issue: Host Header Injection Fix (HHIF).

“Set it and forget it” security fix

How it works

The HHIF plugin enables you to choose the “From”, “Name”, and “Return-Path” headers for all WP notification emails. In doing so, it fixes a long-standing security vulnerability, whereby an attacker can intercept sensitive email notifications (like password reset, user registration, et al). More specifically, this simple plugin does three things:

  1. Sets custom From, Name, and Return-Path for WP notifications
  2. Fixes a security vulnerability in sending WP notifications
  3. Fixes a bug where invalid email addresses may be generated

To accomplish this, the plugin provides the following options:

  • Disable fix and let WordPress decide
  • Use “Email Address” from WP General Settings
  • Use a custom name and address

Plus there is an option to use the specified From address as the Return-Path header.

Here is a screenshot to give you a better idea:

[ HHIF Settings ]

As you can see, the plugin is very simple. Install, activate, choose your “fix”, and done. From there, you can relax knowing that your site no longer is vulnerable to the lingering host-header injection attack. HHIF works silently behind the scenes to make sure all WP email notifications are safe and secure.


The security issue fixed by this plugin has been known about since way back in WordPress version 2.3. There has been some talk about fixing, but nothing has been implemented. While the issue does not affect all sites, it does affect a good percentage of them, including some of my own projects. So, not wanting to get hacked, I decided to write my own solution. Hopefully this issue gets fixed in a future version of WordPress, and this plugin will become unnecessary.

As a bonus, setting an explicit From address resolves a long-standing bug whereby an invalid email address is generated under the following conditions:

  • A “From” address is not set,
  • And the $_SERVER['SERVER_NAME'] is empty

So by explicitly setting a “From” address, we prevent this bug from happening.

More infos

What is the security issue addressed by this plugin? Follows is a quick summary. To learn more in-depth, check out the resources linked in the next section.

  • WP uses $_SERVER['SERVER_NAME'] to set the “From” header in email notifications
  • This includes sensitive email notifications like password resets and user registration
  • In some cases, an attacker could modify the “From” header and intercept the email
  • Using the intercepted email, an attacker could gain access to your site

Again, this security vulnerability is well-known and has been around for a looong time. To learn more, check out these articles:

To learn more about the plugin and download, check out Host Header Injection Fix at the WordPress Plugin Directory.

Tip: If installing the plugin from inside of the WP Admin Area, try searching for “HHIF”, should be the first result :)

Concept: A Developer Dashboard

One of the ideas that came from WCEU was a centralized dashboard for plugin developers. A place they could go to see all their plugins, and the current status on these plugins. What follows is concept art of what that kind of dashboard may look like.

This is something I dreamed up in Nacin’s talk about the government. This idea has no code backing behind it.

So why am I posting it? I’d like to hear people’s thoughts on this. What do you think would work or won’t work? Too much automation or not enough? Do you actually already HAVE this code written and want to share? Here is a zip of the Balsamiq Mockup: WP-Developer-Dashboard.bmpr_.zip – You know the drill. Edits welcome!

Concept Art


  • Make a centralized location for developers to manage their plugins

That’s really it. Making this public means a question of moving the ‘advanced’ tab to this page, and would it be duplicating data unnecessarily? In a way, it would move the developer page here as well, leaving only that which is controlled by the readme left on the readme. But then again, jumping between urls could be a mess. I don’t know. That’s why it’s a concept.

Also it should be easier for a developer to contact the plugin team when they have issues. And yes, the communication would be public, unless a comment is flagged as ‘security.’ Again, no code at all exists to make this a reality.

What’s Missing

There’s no contact form for a closed plugin. There should be. But this is really just concept art and starting to get an idea of what may work.

There’s also a dearth of data on the main dashboard page. That could lift from plugins like WP Dev Dashboard or WP Developers Homepage to fill in data. That’s the same general concept of what we’d want on the Support page (which you’ll notice is also left missing).

Misc. Thoughts

One of the stated goals we have is to allow everyone to leave a review on a plugin, with regards to the reviews before approval. In doing so, those reviews and all discussions about a plugin would need to be public. This is not necessarily a bad thing, though it will lead to some developers thinking long and hard about how they address issues in public. My concerns are that people who continually make the same error or neglect to fix something will be publicly embarrassed, but also that a free-for-all with reviews would lead to developers not wanting to host code here due to public backlash.

However, it’s been pointed out to me that coddling developers as much as we do may be causing them more harm in the long run. We do spend an inordinate amount of time hand-holding people who don’t want to take the time to read and think through a debugging process. Certainly we don’t mind helping out people who are brand new, or who aren’t native English speakers. But they’re vastly the minority of people who act the goat in our emails. And generally, they’re very respectful and nice.

Right now, my gut feeling is that there should still be a private way to talk about security issues.

But behavioural ones? They can be handled in public. It may stop people from some of the name-calling.

Gutenberg Contributors Discuss the Drawbacks of Using iframes for Meta Boxes

photo credit: Closed square box, variation(license)

A lively and productive discussion regarding Gutenberg’s use of iframes for meta boxes is happening on GitHub. Yesterday, WordPress developer Kevin Hoffman created an issue titled “Are iframes a viable long-term solution for meta boxes?

Gutenberg 1.5 introduced initial support for meta boxes. Hoffman identified several issues with iframes that have been popping up as developers have begun testing the current meta box implementation. He did some performance testing that revealed Gutenberg’s use of iframes triples the number of asset requests, as it enqueues all of the CSS and JS assets in the parent window as well as in all the iframes.

image credit: Kevin Hoffman

“Generally speaking, iframes have been discouraged in web development for many years for reasons that are well-documented,” Hoffman said, before citing a litany of issues that plugin developers have already discovered in testing Gutenberg’s meta box support. “Can these issues be addressed without requiring modification of the theme or plugin that generates the meta box? We have to consider that third-party code that has powered meta boxes for years may not have the luxury of being updated in order to be compatible within an iframe.”

Gutenberg design lead Tammie Lister responded to Hoffman’s concerns, indicating that the current implementation of meta boxes is simply an experiment and not necessarily what would land in WordPress 5.0:

It’s good to think a little that what we have today for meta boxes in Gutenberg is an experiment, in many respects it’s a holding pattern as the project works out the direction to take. In saying that it’s one that works ‘for now’ but isn’t what we would ship with.

All the above said, I think it’s important to look at what in the future metaboxes will be used for. What are the cases (if any) that would not be converted to blocks? Do all metaboxes have to work on mobile? Is there even an alternative interface that we haven’t explored? I bet there is. Right now, it’s about looking at those possibilities and getting on a road that works for the state right now and the future state.

The presentation of this implementation as an experiment that “works for now” (but would not be shipped) comes as a surprise after Gutenberg 1.5 arrived with the announcement that “this release includes long awaited meta-boxes support (needs testing!)”

Hoffman contends that the iframe approach doesn’t even work ‘for now,’ as the issue was opened in order to cite several major ways where it is broken. If Gutenberg moves forward with the current approach, it would require many plugins to be modified in order to be compatible with WordPress 5.0, which Hoffman said would defeat the whole purpose of supporting legacy meta boxes.

“I have not seen any evidence to date that suggests meta boxes will continue working with Gutenberg,” Hoffman said. “If the answer is no, then we ought to stop pretending that 5.0 will be just another WordPress release and start being honest about breaking backwards compatibility.”

Edwin Cromley, a collaborator on the project, said that the team anticipates that certain themes and plugins will be broken and that it is not possible to accommodate every possible use case. He admitted that the iframe solution may not meet the project’s goals. Instead, he advocates creating the best experience for the vast majority of users.

However, the current approach would adversely affect many sites out there that use WordPress primarily as a CMS with meta boxes. WordPress core committer Scott Taylor expressed concerns about custom post types, many of which do not make use of the traditional “content” section in favor of meta boxes only.

“In this current iteration, meta box support is an add-on, when in many people’s reality, meta boxes ARE the UI, the API, the mechanism they use to compose their CMS,” Taylor said. “iframes are the gulag.

“And we are forgetting the values WP has been built on forever: I should be able to update to the latest version of WP, and have to rewrite nothing. I have so many projects in the wild on WP that I will never touch again. Can I be confident that some of them won’t break wildly with this change?”

Hoffman advocated scaling back the scope of the project to focus on the editor component, a popular opinion that many plugin developers share and one that was illustrated in detail in Yoast’s post proposing an alternative approach to Gutenberg. This approach stages out the changes to the edit screen, giving developers more time to update their plugins, as well as allowing the Gutenberg team to find an adequate solution for meta boxes.

“I think that goal would be a lot more achievable if Gutenberg stuck to overhauling the editor rather than taking over the entire page,” Hoffman said. “Then we could leave the existing hooks in place and meta boxes could continue to communicate with each other as they do now. Also, asset enqueuing would be a non-issue since it would work as it does today.

“I’m in strong agreement with this concept put forth by Yoast, which seems to me like it would maintain much of the work already done while scaling back the scope of the project to focus on the editor component.”

Gutenberg engineer Riad Benguella indicated the team is not too keen on working towards this concept.

“Reusing Gutenberg pieces to build this concept is relatively doable, but this is not the UX we want to optimize for, we want to build the best possible editor first and make it available for people without backwards compatibility concerns (fresh installs, no metaboxes…),” Benguella said.

“When we think the ideal vision of Gutenberg is ready to ship, we’ll have time to discuss upgrade path strategies, a concept like this one is an option for an upgrade path, but definitely not as the final product. Other upgrade paths are also possible.”

The WordPress developer community is not, however, in favor of delaying this discussion once again. Many are eager to finally answer the question of how meta boxes will fit into the context of the Gutenberg editor so they know how to prepare. Given the numerous issues with the iframes approach, rendering legacy PHP meta boxes under the new editor will require more experimentation and possibly an alternative solution.

“Why devote thousands of hours into developing the ideal editor if it cannot be made compatible with existing sites?” Hoffman said. “If the first impression is that it breaks the UI they depend on, users will never experience the ideal editor in the first place.”

“I think it may be a mistake to put this off too far,” WordPress core committer Aaron Jorbin said. “Especially since many organizations are going to need at least 1-2 quarters to prepare.”

Mark Kaplun suggests the Gutenberg team use a popular plugin as a gauge for the success of current and future meta box support experiments.

“My productive suggestion, is to not declare meta boxes ready, as long as Yoast SEO does not properly work in it,” Kaplun said. “It is both slightly complex in terms of interactions and it is installed on shit loads of sites. If Gutenberg cannot work with it, probably no one is going to use it.”

Greg Schoppe, who has tested and written extensively on Gutenberg’s ongoing development, joined the conversation to advocate for Yoast’s alternative approach to the project as well.

“I highly support Yoast’s view of Gutenberg,” Schoppe said. “It is unclear to me how ‘upgrade the visual editor’ was reinterpreted to be ‘replace the entire post edit interface’ by the Gutenberg team, but it seems directly at odds with the so-called ‘Ship of Theseus.’

“In this case, the lack of clear direction and support for the existing standard workflows is actively hurting developers now. How can I move forward building a project, without a trusted set of hooks and tools that I can rely on? It is unconscionable to think that such a large software project would entirely upend the standard workflow for developers in a single update. and it is insane that these conversations are just happening now, in November, when the plan is to have a merge approved at the beginning of the year.”

The discussion regarding the iframes approach to meta boxes was opened yesterday is still relatively new, but so far the Gutenberg team’s responses have failed to adequately address the concerns of the developer community in this thread. Finding an approach to meta boxes that preserves WordPress’ powerful CMS capabilities, without alienating users and developers, is one of the Gutenberg team’s greatest challenges. They are still aiming at producing a merge proposal early next year, but with meta boxes still in the experimentation stage, the team’s anticipated timetable continues to put the project at odds with the WordPress developer community.

Ask Yoast: how to get sitelinks

As a site owner, you want to come across as an authoritative result, as well as stand out in the search results. Even if you’re already ranking nr. 1. Sitelinks can help you achieve that. These links appear under the main search result, highlighting subpages of a website. Sitelinks can push down the pages of your competitors on the results pages, and provide potential visitors more options to navigate to your site and find what they’re looking for. Of course, this could be beneficial to your traffic. You’ve probably seen sitelinks in the search result pages at some point, but how do you get Google to add them to your site? As it happens, getting sitelinks isn’t for just anyone. In this Ask Yoast, we’ll get into that.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

Sergiu Tere sent us this question:

I see that some sites have sitelinks, but not from Google AdWords. How do they do that?

Watch the video or read the transcript further down the page for my answer!

Getting sitelinks

 Well, it’s very easy. Sitelinks are given to you. It’s not something that you can put in somewhere. Google will give you site links if it thinks you are very ‘authoritative’ for that query, so if you’re a very important result for that query. In that case, it will add site links from your site, based on how people browse your site and how they use your site.

So, it’s not something that you can change; it’s not something that you can opt in for, it’s not something that you can do specific SEO for. You just have to become very important for that specific query.
Good luck!

Ask Yoast

In the series Ask Yoast we answer SEO questions from our readers. Have an SEO-related question? Let us help you out! Send an email to ask@yoast.com.
(note: please check our blog and knowledge base first, the answer to your question may already be out there! For urgent questions, for example about our plugin not working properly, we’d like to refer you to our support page.)

Read more: ‘Google’s sitelinks searchbox & Yoast’ »

The post Ask Yoast: how to get sitelinks appeared first on Yoast.