Wrong and dangerous review requirement for WordPress Themes and WordPress and PHP Plugins

I write this topic to demand an immediate review of the following reviewers’ requirement:

No inline CSS. All CSS must be separated into an external stylesheet.

This requirement, when it forces to remove all inline styles, is blatantly wrong under all points:

  1. When some style is created to be applied only to a single HTML element, in such cases insert it into an external CSS file cause only confusion and more code. Anyway in this case is not a big issue, but it’s just non-sense.

  2. When some style is created dynamically from user input, to be applied only to a single HTML element, in such cases insert it into an external CSS file causes only problems, this time more relevants and dangerous:

  • There is the need for a server-side code that creates a CSS class with the dynamic style inside it.
  • There is the need for a server-side code that write and save the .css file
  • There is the need for a server-side code that is able to link the CSS classes created to the correct HTML elements
  • You must load an external CSS file for no reason, this is a downgrade of performance (file size and 1 more HTTP request)
  • In many cases, where the dynamic codes are just one or two, the problems are startling clears: you must create a file of ex. 800bytes with 2 lines of code, and load it as external files. Totally nonsense.

Real use-case:

Imagine a scenario where a user wants to upload an image and use it as a background in an HTML element. With old rule is just style="background-image:URL()". with the new rule some code must create and save an external file, with just the code style="background-image:URL()", create a CSS class for it, write it in the HTML component, load this CSS file with just one line of code. Totally nonsense. Consider also that this operation must be done every time the user updates the image.

Final result of this requirement

  • Worst performance due to 1 more HTTP request and large, complex, server-side codes.
  • Wasting hours of time for authors to develop something that is not only useless but also creates real problems.
  • Min one more file
  • Worst readability/comprehensibility of the code because a user must check the HTML and than find the CSS code of the linked CSS class to see the value of the style.
  • Greater exposure to bugs. More a code is complex more are chances of bugs. The server-side codes above are very complex in comparison to the simplicity of the task they do. I already see customers complaining of broken styles due to file permissions issues or wrong class assignments.

More proofs this practice is nonsense:

All major websites and companies, including Google and SEO websites, use inline styles when required, for obvious reasons.

Why this?

I wonder who is the Envato member that published this requirement because any good developer in the world knows that’s it is deeply wrong and causes only problems. Anyway anyone makes mistakes, I just hope that they will understand the mistake and will correct it, making the requirement non-mandatory for all inline styles. There must be exceptions. Styles dynamically generated in relation to the user input like user images and custom colors must be excluded.

style="background-image:URL()"

Is still allowed. I got a theme approved recently and there was no issue with that. Not allowing such use case would be a total nonsense.

1 Like

Mate, I’ve been chewing the end of the rope for quite some time now, about some of the stupid requirements.

  • Don’t use __ and _e, you need to escape, blah blah. I mean if the documentation of __ doesn’t say anything about escaping, why do you even make it required? https://developer.wordpress.org/reference/functions/__/
  • You need to escape every variable; read the damn code and see for your self that the variable had been escaped prior of using it. ex:
    $myVar = absint( get_post_meta( … ) );
    <input value="<?php echo $myvar; ?>"

I have a long list of rants, but sTaNdArDs ExIsT, so please listen to this, and try to not think about it much.

Ok good do know. I asked for confirmation :wink:

I am ok with the inline CSS stuff, but I got a list of things with issues that are not present in my plugin, are these reviewers even checking the files?

Very wired!

You don’t need to put all cSS into an external file, just not directly inline. For dynamic CSS use wp_add_inline_style() | Function | WordPress Developer Resources

Regarding background images, consider object-fit | CSS-Tricks – it’s better for SEO too

__( and _e( need contextually escaping, there’s even specific versions of the functions for that directly like esc_html_e(

All variables should be escaped at the point they’re echoed into the markup, it’s just good practice.

1 Like

Hi, sorry but all your statements are wrong, or what is marked as not allowed is actually allowed:

  1. wp_add_inline_style just print the styles on the page, you still need all server-side code mentioned above, apart from the part that saves the file, but another problem is that wp_add_inline_style add inline styles (like the name of the function suggests…) which is not allowed, so you are no more allowed to use wp_add_inline_style.

  2. object-fit has nothing to do with the background image link of an image, this statement is totally wrong.

  3. Not all variables should be escaped in the point of echo, in many cases it is non-sense, also this statement is totally wrong.

Regards

1.) I’ve used wp_add_inline_style in my latest theme and there was no problem on reviewer side

2.) this is something new for me, but I guess it allows you to use IMG tags in a similar way as background-image, which if true, is surely better for SEO, but again, background-image in inline CSS is definitely allowed so no problem there

3.) there are instances when you want to allow users to print some HTML, in that case, just use wp_kses

While I agree that Envato’s requirements can sometimes feel way too punishing and unnecessary, but from my own experience I can tell that you can definitely abide them without too much headache. My latest theme contains a lot of complex coding stuff and I had no problem to make everything by the book (as per Envato’s requirements)

You’re more than welcome to call me wrong without actually looking into or thinking about what I stated, but as someone with over 70 accepted themes in my time, I’m pretty sure I know what I’m talking about, so take the advice or not, doesn’t really make any difference to me.

  1. I hope you’re right. I’m asking for clarification because if it is allowed they should change this statement " No inline CSS. All CSS must be separated into an external stylesheet.*

  2. No, object-fit is just the same as background-size. It has nothing to do with providing the link to the image.

  3. While this is true, it just another useless code that adds complexity and reduces performance without reason. If you understand how servers and coding works, you should understand that escaping a variable in a code like this is nonsense: $x = “123”; echo $x; This is also confirmed by the fact that all major software in the world and the best developers in the world do not do this.

I looking into it and I provided you explanation for most of them. It looks like it is you that are ignoring the facts and are not looking into what you’re writing.

Again:

  1. I clearly explained this, and again, you’re wrong. Using wp_add_inline_style() doesn’t remove the need to create a code that creates a CSS class with the dynamic style inside and that is able to link the CSS classes created to the correct HTML element. Are you really stating that I’m wrong?

  2. Object-fit is just the same as background-size. It has nothing to do with providing the link to the image. Are you really stating that I’m wrong?

  3. If you understand how servers and coding works, you should understand that escaping a variable in a code like this is nonsense: $x = “123”; echo $x; This is also confirmed by the fact that all major software in the world and the best developers in the world do not do this. Are you really stating that I’m wrong?

About your experience, I already know you’re a good developer and your themes are great, but if you want to put it under this point my portfolio shows you that I’m an expert like you.

Understand that my replies are here to help you get your theme approved, I have no interest in arguing with someone who is clearly on a rant. This is why I stopped offering help in the forums generally, but sure, once more:

  1. You’re wrong. You’re not allowed inline (on element) CSS, so don’t even try to use it. Use wp_add_inline_style() | Function | WordPress Developer Resources which will print your CSS to the head, if you’re worried about performance, cache plugins can grab CSS from the head and combine it. Direct on element CSS is not performant in this regard.
  2. Object fit recommendation was based on your worry about being accepted with background-image inline (on element) CSS. Object fit requires you use a direct IMG tag which means that the user picked image will not need to be added inline on the parent element, also object-fit is better for SEO (alt tag not available on inline CSS) and also supports native loading=“lazy” so again, is better for performance.
  3. Yes, you’re wrong. If you want to be accepted in Themeforest or WordPress.org then you need to escape all variables (i.e user input) as late as possible, e.g during the echo to the page. Data Sanitization/Escaping | Theme Developer Handbook | WordPress Developer Resources – “Output escaping should occur as late as possible.”

Like I said, feel free to argue with me, but if you follow the above you won’t be rejected for these reasons.

Thanks for the clarifications, my post is not for being accepted or not, I already follow these rules because as you stated it is the only way to get approved.

My post is to highlight that these requirements are clearly wrong and should be removed or adjusted.

So my points are still all valid. About object-fit, I understand now your point, it’s like a workaround to avoid the reviewer rejection, but in many cases, background-image is the best option, and forcing everyone to don’t use it is clearly wrong.

Anyway good, we clarified, your one was just advice to help get approved not a statement claiming what I wrote was wrong. Regards

Yes, agree, doesn’t make sense to not use inline styles where they fit the most. External stylesheet is extra request, maybe they should then force to place all CSS in internal stylesheet? /sarcasm

All the ‘critical’ issues they are finding in our items are not really critical. I’d say these should be recommendations at most. Another favorite is to update third-party libraries. Bro, they work as expected now and if I update I can have lot of compatibility issues (when you use a lot of modules) resulting in big pain in the arse. Or forcing three symbol prefixes. Changing prefix you already use across 100 files in plugin, good luck debugging and testing all use cases. Such a big entropy.

Forcing unnecessary unwanted changes on established items is a bad idea during the times of marketplaces decline. Potentially weeks of extra work to comply with ‘standards’ instead of developing business logic that adds value? Much wow. We are authors since 2014 and we make really critical changes when needed otherwise we wouldn’t reach top 20, right?

We already gave this feedback in conversations with Quality and Author Help teams but let it be stated here also. Hear me out, Envato, please fix your marketing part (looking at you, this year sales) or it make less and less sense to pay your fees. Now all your forcing of standards will be backlashed

1 Like

You understand exactly the basic problem and what I want to communicate.
Also, your new points are all correct:

  1. forcing three symbol prefixes when my prefix is actually 6+ symbols. Ex. they force me to use another prefix with functions like sb_woocommerce_function_name where the actual prefix is sb_woocommerce_

  2. Forcing the update of external scripts creates exactly the problems you mentioned.

Again, you understood exactly the basic problem and what I want to communicate. Such limitations and requirements have the only result of creating the worst software for the user while frustrating the developers and causing them dozens of hours of wasted time.

NB I must also acknowledge that the reviewer’s work is very difficult and there are many unexpert authors who publish themes and plugins with very bad codes and find solutions valid for all is problematic (maybe they should give more control to expert authors like us, you can easily verify it by checking the source code and design, the overall users rating and sales number). Envato in general is great and the only company that allows me to do this incredible work so this post is really meant for helping to improve the review process.

You realize that you’re escaping a translation not a variable right?

Mate I’m facing the same issue, here. I mean I haven’t checked yet it the new version of a library is compatible with the plugin, but as it is right now it’s working with the latest version of WordPress. Now you may not know me, but I’m the main developer behind Dex Multilayer Parallax plugin, and some other themes. Today I got a message that we need to make some quality changes to the plugin and I find almost all of the quality changes dumb.
Anyways back to the issue, the plugin doesn’t really sell, so I’m not really getting a cut out of anything, and now I’m forced to update the plugin, spend my time and money on something that doesn’t produce any revenue or their going to delete it. Wtf are these crap requirements? And meanwhile other badly written/performing plugins, are kept as they are…

Believe it or not, yes I do realise that, and a translation is subject to user input and so is possible to abuse. You do realise that means that escaping is required right? Otherwise it’s a potential security issue.

Likewise, keep your plugins and libraries up to date otherwise you’re giving potential security issues to your users, there’s nothing “expert” about deciding not to update 3rd party libraries in your products.

I hate to say it, but there’s a lot of laziness in this thread.

1 Like

I agree about the translations, you’re right. It’s user input and should be escaped.

I agree only partially about 3rd party libraries, we as authors have the responsibility to keep our software safe and this sometimes involves update 3rd party software, but not always, and for sure not JavaScript scripts because they are client-side code and are never security issues for the site or server.

It is actually the inverse in most cases, newbies and not-experts updates everything blindly just because they read somewhere that is best practice to do it.

I sometimes receive support requests for problems caused by updating my own plugin and software or external plugins. I ask why did you update? The answer is always the same: because I read that is a good thing to do it.

This is wrong! I reply that they should not update the plugin if there is not a security update or a new feature/fix they need.

Why it is not good to blindly update everything?

Of course in an ideal world, it is better to keep everything updated but in the real world, this causes conflict and problems. Because 99% of updates do not have any security-related update, in 99% of cases the user updated something for no reasons but only exposing his website to bugs and new security issues. The same logic apply to us authors.

In my opinion, such “best practices” cause more problems than benefits because most users don’t understand them properly.
It happens many times, another example are the Google Page Speed, GTMetrix, etc… Most users believe that they measure the performance and speed of a website while they are not, they get low scores and think their site is slow… In reality, you can have an empty page that took 5 minutes to load and that have a 100% score and a super fast page with low scores.

What user input are you talking about? The only interaction is via translated text. Which is either translated by the admin of the site, or by translator, that being said, when someone adds the translation to the site, they check each translation if its correct, and displayed correctly. Anyways you do as you please, I do as I please. By these standards I should escape even hardcoded variable/markup/any code.
Let’s say I have the following code:

_e( 'Please remember to use the big red button to do something.', 'textdomain' );

Now let’s say the owner wants to underline that THE BIG RED BUTTON is important. So he then translates the text as follows:

Please remember to use the <strong>big red button</strong> to do something.

In this case it will work perfectly. Now add esc_html_e() to that translation. What do you think will happen? Everything is escaped, thus he can’t underline that big red button text, thus he may result to hacking the theme(either removes the esc_html_e, or simply deletes the translation and hardcodes the text himself), thus having problems in the future updating the theme/plugin.
And believe me I’ve seen and done similar things, cause clients don’t care about code, they care about what they see on the screen.

So if my code/library is working correctly with every update that comes, I still have to bother to update it? Have you ever heared of the phrase if it ain’t broke, don’t fix it. For example I have an old version of pupunzi / jquery.mb.YTPlayer, which works perfectly. If I update it, not only everything is broken, it even grows in size, with no real functionality or performance gained for my use case.

Yes I’m lazy, I don’t like to work unnecessarily, with nothing to gain.

Let me tell you a little story.

I was doing a work for a client. He didn’t want to wait a week to do a room viewer of paintings for WooCommerce. We found a plugin for his need case Woocommerce Products View in a Room Popup by Go-Web | CodeCanyon, the price for it would have been equal to the 1 week wait time. After he bought it, almost nothing was working. The author didn’t want to refund the plugin. So lil`ol me fixed the mess of a code that that plugin had, which took around 1 day or so. After that other problems arouse, like for example if you had 1000 room pictures, a useless markup/js would be generated for those 1000 rooms, that wouldn’t be even used, and create a page load you wouldn’t even imagine. So after I fixed everything up, I was left with a pile of crap, that was goodish, with extra fees for the client, delay on the project that was higher than the original quoted time to do the plugin from scratch. My main point is if their so harsh on the review process, why is that plugin such a mess, and still not disabled or updated? Why isn’t the review process harsh on already existing plugins on Envato?

Let’s take another look at another plugin. WooCommerce Upload Files by vanquish | CodeCanyon
A client wanted a WooCommerce shop to upload images. He wanted it fast, he agreed that this plugin would be ok for him. After he bought it, and the site was up and running in a week, in the next few days/week problems kept occurring with lost images on orders, uploading problems, unresponsive page for 100+ images uploaded, payed orders didn’t have any images in them. So after 2 frustrating weeks, I decided to make a plugin from scratch for free, because the plugin wasn’t working properly, and we didn’t want to deal with being dragged to court or something similar. It took me like 2 weeks, and after I switched to the new plugin, up till this day, never heard any problem from that site again. Again, I actually lost money on this project, and for what? Cause we only want quality items, but we keep items that sell as they are since their making us money, and we don’t care about anything else. And just for giggles, here is the link to that plugin, which I even made available for free on WP repository. Uploads for WooCommerce – WordPress plugin | WordPress.org

  1. Haha, yes that’s the exact case why you’re disallowed to use it like so :slight_smile:

  2. It broke as new standards were being implied by new libraries, so yeah, you’d need to fix that :slight_smile:

  3. This is a good point. If your item made $10 during last 3 months, well yes, you don’t have an interest in fixing it, which is the core idea behind it all. Remove old and unmaintained items and replace them with new ones (not necessarily better)

Still @tommusrhodus just showed you the way as he understands it a bit better.

Cheers!