Title: devc's Replies | WordPress.org

---

# devc

  [  ](https://wordpress.org/support/users/devc/)

 *   [Profile](https://wordpress.org/support/users/devc/)
 *   [Topics Started](https://wordpress.org/support/users/devc/topics/)
 *   [Replies Created](https://wordpress.org/support/users/devc/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/devc/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/devc/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/devc/engagements/)
 *   [Favorites](https://wordpress.org/support/users/devc/favorites/)

 Search replies:

## Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Yoast SEO - Advanced SEO with real-time guidance and built-in AI] Yoast banner ad in admin section](https://wordpress.org/support/topic/yoast-banner-ad-in-admin-section/)
 *  [devc](https://wordpress.org/support/users/devc/)
 * (@devc)
 * [6 years, 6 months ago](https://wordpress.org/support/topic/yoast-banner-ad-in-admin-section/page/2/#post-12186655)
 * 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_](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#developer-expectations):_“
      all users who officially support a plugin are expected to abide by the Directory
      Guidelines.”_
    - From [#7](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent):_“**
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      Advertising within the WordPress dashboard should be avoided, as it is generally
      ineffective.”_
    - From [#11](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent):_“
      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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Yoast SEO - Advanced SEO with real-time guidance and built-in AI] I did not consent to animated banner ads all over the wp-admin area](https://wordpress.org/support/topic/i-did-not-consent-to-animated-banner-ads-all-over-the-wp-admin-area/)
 *  [devc](https://wordpress.org/support/users/devc/)
 * (@devc)
 * [6 years, 6 months ago](https://wordpress.org/support/topic/i-did-not-consent-to-animated-banner-ads-all-over-the-wp-admin-area/#post-12186648)
 * 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_](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#developer-expectations):_“
      all users who officially support a plugin are expected to abide by the Directory
      Guidelines.”_
    - From [#7](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent):_“**
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      Advertising within the WordPress dashboard should be avoided, as it is generally
      ineffective.”_
    - From [#11](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#11-plugins-should-not-hijack-the-admin-dashboard):_“
      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](https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#7-plugins-may-not-track-users-without-their-consent):_“
      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.
 *   Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
   
   In reply to: [Modifying a theme to allow for Portals](https://wordpress.org/support/topic/modifying-a-theme-to-allow-for-portals/)
 *  Thread Starter [devc](https://wordpress.org/support/users/devc/)
 * (@devc)
 * [16 years, 3 months ago](https://wordpress.org/support/topic/modifying-a-theme-to-allow-for-portals/#post-1422027)
 * 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…
 *   Forum: [Themes and Templates](https://wordpress.org/support/forum/themes-and-templates/)
   
   In reply to: [Passing the_title variable or turning it into one](https://wordpress.org/support/topic/passing-the_title-variable-or-turning-it-into-one/)
 *  [devc](https://wordpress.org/support/users/devc/)
 * (@devc)
 * [17 years, 9 months ago](https://wordpress.org/support/topic/passing-the_title-variable-or-turning-it-into-one/#post-701579)
 * 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!
 *   Forum: [Installing WordPress](https://wordpress.org/support/forum/installation/)
   
   In reply to: [Permalinks postname tag not working](https://wordpress.org/support/topic/permalinks-postname-tag-not-working/)
 *  [devc](https://wordpress.org/support/users/devc/)
 * (@devc)
 * [20 years, 9 months ago](https://wordpress.org/support/topic/permalinks-postname-tag-not-working/#post-260558)
 * I don’t mean to be condescending, but have you tried taking away the last “/”
   in your structure?
 * Might be that,
    devc.

Viewing 5 replies - 1 through 5 (of 5 total)