devc

There are so many frustrating sides to this situation, and the issue has been magnified by the PR spin we’re receiving in response to (what sounds like) a well-expected response to an egregious marketing decision.

To start, it’s frustrating that me and my clients (whom my name is on the line for, having recommended Yoast) are being forced to play Duck Hunt when we login to our WP Dashboard.

But it’s incredibly frustrating that the Developer Guidelines are being co-opted as “guidelines, not rigid rules” in order to side-step responsibility.

Here are some relevant snippets from the Guidelines:

• From the first sentence of Developer Expectations: “all users who officially support a plugin are expected to abide by the Directory Guidelines.”
• From #7: “Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.”
• From #11: “Users prefer and expect plugins to feel like part of WordPress. Constant nags and overwhelming the admin dashboard with unnecessary alerts detract from this experience.”
• From #11: “Advertising within the WordPress dashboard should be avoided, as it is generally ineffective.”
• From #11: “Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements.”
• From #11: “Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements.”
• From #7: “In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent.“

I’m not here to split hairs over the definition of the word ‘guideline’, and/or ‘explicit consent’; if you’re willing to die on that hill, so be it. Not me.

The deeper issue is one of the ‘unwritten, but understood’ rules of Open-Source Software: Product comes first. Every time.

Decisions like the banner tell us the current hierarchy at Yoast HQ is marketing first, product after; without a re-structure (ie. internal decision-making changes so product, developers, and WordPress ecosystem come first, and the sales & marketing come after), and with the addition of intrusive banners, the plugin would lose its value for me.

And therein lies the problem; I have zero faith the same management team green-lighting forced Casino-style banner ads with difficult-to-click close buttons (“Oops! teehee, sorry peeps! We’re working on making it easier to opt out; here’s a workaround buried in the comments section of one of our support tickets!” doesn’t cut it); the same management team asking support staff to push back on well-predicted complaints from the community regarding obtrusive advertising, are in the right headspace to restructure their business in a direction that will decrease revenue in the short term (short term only, of course, but short-term decision-making is how they got themselves here in the first place). And that lack of faith gives me a sinking feeling.

Yoast’s SEO plugin has shifted in direction from becoming “bloaty, but more colourful and bubbly” to becoming a free advertising siphon: “Just add a straw and suck!”

For years, I’ve touted it as the single-most important plugin for any WordPress website to have… but there’s no way I can do that in good conscience now. Even if you right this wrong, change your tune, and back-peddle out of this successfully… The plugin’s trajectory has been tipped.

It won’t get better, it will get worse.

And so today I’ll frustratingly, and resentfully start moving all installs under my supervision away from Yoast’s SEO plugin. But (a) the decisions which leads to green lighting the banner, and (b) the response to the community’s complaints tell me everything I need to know about the next 2-5 years of Yoast SEO. It’s been a slice.

There are so many frustrating sides to this situation, and the issue has been magnified by the PR spin we’re receiving in response to (what sounds like) a well-expected response to an egregious marketing decision.

To start, it’s frustrating that me and my clients (whom my name is on the line for, having recommended Yoast) are being forced to play Duck Hunt when we login to our WP Dashboard.

But it’s incredibly frustrating that the Developer Guidelines are being co-opted as “guidelines, not rigid rules” in order to side-step responsibility.

Here are some relevant snippets from the Guidelines:

• From the first sentence of Developer Expectations: “all users who officially support a plugin are expected to abide by the Directory Guidelines.”
• From #7: “Documentation on how any user data is collected, and used, should be included in the plugin’s readme, preferably with a clearly stated privacy policy.”
• From #11: “Users prefer and expect plugins to feel like part of WordPress. Constant nags and overwhelming the admin dashboard with unnecessary alerts detract from this experience.”
• From #11: “Advertising within the WordPress dashboard should be avoided, as it is generally ineffective.”
• From #11: “Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements.”
• From #11: “Remember: tracking referrals via those ads is not permitted (see guideline 7) and most third-party systems do not permit back-end advertisements.”
• From #7: “In the interest of protecting user privacy, plugins may not contact external servers without explicit and authorized consent.“

I’m not here to split hairs over the definition of the word ‘guideline’, and/or ‘explicit consent’; if you’re willing to die on that hill, so be it. Not me.

The deeper issue is one of the ‘unwritten, but understood’ rules of Open-Source Software: Product comes first. Every time.

Decisions like the banner tell us the current heirarchy at Yoast HQ is marketing first, product after; without a re-structure (ie. internal decision-making changes so product, developers, and WordPress ecosystem come first, and the sales & marketing come after), and with the addition of intrusive banners, the plugin would lose its value for me.

And therein lies the problem; I have zero faith the same management team green-lighting forced Casino-style banner ads with difficult-to-click close buttons (“Oops! teehee, sorry peeps! We’re working on making it easier to opt out; here’s a workaround buried in the comments section of one of our support tickets!” doesn’t cut it); the same management team asking support staff to push back on well-predicted complaints from the community regarding obtrusive advertising, are in the right headspace to restructure their business in a direction that will decrease revenue in the short term (short term only, of course, but short-term decision-making is how they got themselves here in the first place). And that lack of faith gives me a sinking feeling.

Yoast’s SEO plugin has shifted in direction from becoming “bloaty, but more colourful and bubbly” to becoming a free advertising siphon: “Just add a straw and suck!”

For years, I’ve touted it as the single-most important plugin for any WordPress website to have… but there’s no way I can do tht in good conscience now. Even if you right this wrong, change your tune, and backpoeddle out of this successfully… The plugin’s trajectory has been tipped.

It won’t get better, it will get worse.

And so today I’ll frustratingly, and resentfully start moving all installs under my supervision away from Yoast’s SEO plugin. But (a) the decisions which leads to green lighting the banner, and (b) the response to the community’s complaints tell me everything I need to know about the next 2-5 years of Yoast SEO. It’s been a slice.

Sorry, I should mention the client will not be blogging. This is a fairly static site but will need to be updatable by the client, which is why I’m using WordPress. In this sense I don’t think there will ever be a huge number of pages, probably just the base 10 or 20 pages per Portal.

The idea to use Posts is just so that I have access to Categories, perhaps I’ll use the cat2page plugin and be able to do the same with Page’s?

If I end up hard-coding the navigation per portal, then there’s really no need to specify what portal is allowed to view what, I just need to identify what Portal the user is in and display the appropriate Header/Footer, no?

I’ve never used a PHP CONSTANT, but would that do the trick? And upon clicking the link to the other portal, I change the CONSTANT? Can anyone shed light on that? I’m off to read up about them…

Just wanted to say, 6 months after the fact that this totally saved me from a mental breakdown today. After 1.5 hours of scouring this site I found this, thought I’d document what I was trying to do and what I did to fix it.

First of all, I’m using WordPress as a CMS in this case, with no blog. Each page of the CMS uses a unique banner image, and I wanted to put this in my template to have it automated. Here’s what I originally started with:

<img src="images/<?php the_title(); ?>.jpg" alt=" <?php the_title(); ?> " />

which outputed:

<img src="images/Contact Us.jpg" alt=" Contact Us " />

This would work, but isn’t even close to being nice code, so I ended up going with:

<img src="images/banners/<?php
$title = get_the_title();
$loweredTitle = strtolower($title);
echo str_replace(" ", "_", $loweredTitle);
?>.jpg" alt=" <?php the_title(); ?> " />

which outputs:

<img src="media/images/banners/contact_us.jpg" alt=" Contact Us " />

Excellence! It turns out essentially how %postname% would, but because I had the option I used underscores (“_”) instead of dashes (“-“).

Thanks Kaf, and hopefully this extended documentation will help someone in the future!

I don’t mean to be condescending, but have you tried taking away the last “/” in your structure?

Might be that,
devc.