Hi Stephen, no isn’t exactly that. I mean to target scripts.
Don’t know if you are familiar to javascript or jquery, but I’m gonna make an example I just faced 2 days ago.
I use Chosen for my admin forms, is a very very popular script, used by many.
Personally I try to write the most clean and targeted code possible. Then if I customize that script (eg. it must be 200px wide on my forms), it will be affected ONLY in my forms.
While there’s plenty of plugins and themes (even by very popular authors) creating code that is affecting also others. I my case, I had this Chosen script interface totally ruined by that theme.
You can’t imagine how many tickets I receive because of this: great time loss for me and unhappy customers.
@LCweb Sorry! I think @Typps was talking about the same thing I was in his separate post above and we’ll still consider it as that’s worthwhile too.
With this one, you’re saying that you call Chosen using something like:
$(".your-element").chosen({width: "200px"});
which should only affect your element (I think, haven’t used Chosen much), but others are not doing the same. Ie they are calling Chosen in a way that affects your element too?
I can see that would be a major pain. It’s also going to be really hard to prevent, as every library will have different best practices and different ways that clashes could happen.
I guess we can consider adding a general principle that people should respect best practices for each library they use and try to code in a way that prevents clashes, but it probably won’t be possible to get into specifics for each library. We’ll consider this some more.
Here can be a lot of limitation (maybe I am wrong).
For example, I create a demo where I am using Some Slider only on “Home Page” and I am loading JS/CSS files only there. What if user want to use it also on “About” and on “Contact Page” but I don’t load JS/CSS files there?
Not about initialization: obviously script parameters are related to that specific instance.
I’m referring to scripts customization!
Author adds custom CSS affecting Chosen globally
Author adds custom JS doing the same (is a rare case though)
Is extremely simple to prevent this and is a normal practice: target everything with unique classes!
Wrap your Chosen with an XYX class and apply the CSS code to Chosen within that XYX.
Another super super frequent case is with jQuery UI elements: in these years I had my tabs ruined a zillion times!
Hope it is clear now, I know it could be a bit tricky if you’re not into it
I’m moving a payment processing code from Curl to wp_remore_post. However in order for code to work we need to user base64_encode , which is not allowed by the theme check plugin.
Code ex: ‘Authorization’ => 'Basic ’ . base64_encode( $clientId . ‘:’ . $clientSecret ),
Also based64_encode is used by many theme on import/export options features (a popular featured used by client when moving a site from devel domain to live domain).
Any advice about that ? Will you allow some exception or can you move this from Required to Warning ?
Please clarify what coding standards we should follow for JavaScript in plugin development. WordPress Plugin Requirements - JavaScript says: “Provided code needs to pass JSLint.”
Additionally, it’s extremely absurd that Envato would enforce syntax-related coding standards at all.
It’s not of any Envato’s concerns if a developer prefers camelCase or underscores - it’s not an internal organization nor is it a single project where the devs are part of “Envato Team”. Even wp.org doesn’t enforce it when they have the WordPress purists there.
Please re-evaluate the rules and limit the rules to those that would have tangible benefits. Having rules for the sake of rules never bodes well.
I follow the PSR instead of WPCS. Does this mean that I will get rejected? WordPress.org reviewers allow following any guide we want for code that is not intended to be included in WP core.
It’s not fair to enforce us to change our coding style and structure method.
Trust me, I used to write code that follows the WP recommendations and I noticed that I write slower because of all these spaces, underscores, slashes, etc.
The PSR-4 autoloader:
Naming the files with the class name makes easy to differentiate from files that contain code other than a single PHP class.
Here is the structure(similar to how it’s done in major frameworks like Laravel…):
I am not sure that is true. I tried to remove sidebar widgets from functions.php to functions plugin and when I checked theme with Envato check plugin there was requirement that theme needs to register sidebars with:
