search

joomla / jed-issues

Joomla! Extensions Directory - Issue Tracker
8 stars 2 forks source link

JED Checker CI - J4 and the New Joomla Coding practices #67

Open anibalsanchez opened 5 years ago

anibalsanchez commented 5 years ago

At this time, JED Checker is a classic extension that helps to check JED recommend practices:

https://extensions.joomla.org/extension/jedchecker/ https://github.com/joomla-extensions/jedchecker

The idea is to improve it to add new features to enforce new good practices and automation:

P.S. Thanks @dgrammatiko for the front-end recommendations

For more information about JED Extensions Checker CI:

C-Lodder commented 5 years ago
dgrammatiko commented 5 years ago

I also agree with @C-Lodder here. Especially the coding standards is a bit too much to ask...

mbabker commented 5 years ago
  • Don't allow 3rd party extensions to import a custom version of jquery

👎

Extensions (and this includes templates since a template is a Joomla extension, although for some reason everyone wants to treat them as something different) should not be mandated to only utilize the versions of scripts shipped with core.

anibalsanchez commented 5 years ago

@mbabker Restrict the rule to a custom version of jquery module? Plugin? To avoid modules loading multiple versions

dgrammatiko commented 5 years ago

should not be mandated to only utilize the versions of scripts shipped with core

There are 3 different ways this can happen, 2 of them are ok the other is not (I guess Charlie is referring to that one)

C-Lodder commented 5 years ago

@mbabker ok fair point. But if it's not done properly, you have 2 version of jQuery being imported.

If you override the jQuery file properly, this could cause B/C breaks, as different extensions may be built on 2 different major versions

C-Lodder commented 5 years ago

Dimitris, a namespaced version of jquery is the only viable solution

dgrammatiko commented 5 years ago

Basically, why are we even considering jQuery something that is essential for front end in 2019? Flag it as DEPRECATED script

C-Lodder commented 5 years ago

Because extension devs will import it.....fact

mbabker commented 5 years ago

Basically, why are we even considering jQuery something that is essential for front end in 2019?

jQuery is an example.

If the web asset API gets written correctly in 4.0 then the requirement should be "use the API to define a custom version and/or URI". As is with 3.x there is no practically enforceable rule IMO. Extensions such as jQuery Easy do not have a template they can put an override file in and the only way to change to a CDN is through one of those unset tricks. Yes, extensions should be encouraged to use the core asset; no, extensions should not be mandated that only the core asset can be used (in that case you basically mandate the namespaced version of *whatever library here* approach, nobody should be encouraging that because we don't need 2 or 3 versions of jQuery or Bootstrap or whatever home grown script was written because jQuery is evil).

C-Lodder commented 5 years ago

@mbabker I'll reword my initial comment then

Discourage 3rd party extensions importing a custom version of a script shipped in core

dgrammatiko commented 5 years ago

Because extension devs will import I

If you get a flag in your component maybe you'll rethink what crappy scripts you deliver in the front end. Bold move? Probably for most people in the community, but is a way forward...

C-Lodder commented 5 years ago

@dgrammatiko It's still being shipped in core, therefore (despite opinions) it will be used by some poeple out there.

Anyway, I'll say lets discourage it rather than blocking, but you get the gist.

mbabker commented 5 years ago

Going on a "jQuery and Bootstrap just need to die" rant every time those two keywords are mentioned honestly does nothing useful. You might be in a spot where you can deliver sites without use of those (or other "bloated" tools or "crappy scripts"), but not everyone is and speaking in disrespectful terms toward those who do use those "bloated" tools and "crappy scripts" to create deliverables doesn't help anyone.

C-Lodder commented 5 years ago

@mbabker Just had a thought....what about disallowing jQuery 1.x and 2.x as they pose known security vulnerabilities?

mbabker commented 5 years ago

I'd start with "discourage downgrading core scripts" and moving toward a more aggressive "flat out not allowed". Maybe start 4.0 rules with the not allowed bit, but that might be too aggressive for 3.x which really the project (and this bit includes all aspects of it, not just the handful on the CMS GitHub repo) should be spending less time supporting new work on and more time provisioning it for LTS with minimal interruption.

dgrammatiko commented 5 years ago

what about disallowing jQuery 1.x and 2.x

Joomla 3. is using jQuery 1.x

speaking in disrespectful terms toward those who do use those "bloated" tools and "crappy scripts"

Why everybody gets offended whenever I put the word crappy for any kind of code? Personally I consider most of my code crappy-happy 💩

mbabker commented 5 years ago

It’s more your tone than just crapping on everyone’s work. I never said my PHP or JavaScript was the gold standard, but it is a bit annoying to be told I shouldn’t write JavaScript because I use jQuery plugins to get things done where I don’t have the time or patience to write vanilla alternatives.

On Thu, Jan 10, 2019 at 8:25 AM dGrammatiko notifications@github.com wrote:

what about disallowing jQuery 1.x and 2.x

Joomla 3. is using jQuery 1.x

speaking in disrespectful terms toward those who do use those "bloated" tools and "crappy scripts"

Why everybody gets offended whenever I put the word crappy for any kind of code? Personally I consider most of my code crappy-happy 💩

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joomla/jed-issues/issues/67#issuecomment-453113125, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWfoakx9By-k6XnTKt57t5bjgkD91ETks5vB01BgaJpZM4Z5geF .

--

  • Michael Please pardon any errors, this message was sent from my iPhone.
kavadas commented 5 years ago

Just wanted to share my thoughts on the jQuery/library debate.

Third party extensions were/are loading their own jQuery instances because it was not included in the core when the JQuery “revolution” happened.

The core should include a JS library. Expecting third party developers to write plain JavaScript is an utopia. Most of them are not familiar with modern stacks. It’s sad but that’s the truth. Removing jQuery will take us back to the the mootools era and the multiple jQuery instances.

Personally I think that there should be no restriction on libraries loading. It’s a responsibility of the developer to build a quality extension.

To summarize, and stay in the topic the checker should encourage the use of the core library but not enforce anything related to assets loading.

dgrammatiko commented 5 years ago

@kavadas nobody proposed or even implied that jQuery should be removed. It shouldn't although it;'s totally useless. Whatever good script existed for jQuery already exists as plain js. Nevertheless the discussion here is all about exposing what technologies applications in the JED are utilising. And probably flag the best ones and penalise the ones with the less optimal front end. Also penalise those devs that are not using consistently the API... JED is Joomla extension directory, if someone wants to do their code ignoring the API then probably they shouldn't publish their apps there...

At least that's my personal opinion...

kavadas commented 5 years ago

@dgrammatiko I thought that this was the underlying meaning of your comments here :-)

I agree that the tool should encourage best practices.

Here are some «sci-fi» ideas for the tool:

  1. Check extensions with database tables for indexes/performance.
  2. If JED had templates then it could ask for a demo URL and then use the LightHouse API to evaluate it and display the score in the directory. A bit out of topic though since JED does not include templates.
dgrammatiko commented 5 years ago

use the LightHouse API to evaluate it

Hahaha I did that already for the best template clubs out there and wanted to do a YouTube video with the actual results. But then again I've already gathered too many enemies in the community due to my ideas about jQuery and the beloved Bootstrap (both deprecated for any modern website) so I skipped...

Llewellynvdm commented 5 years ago

Now I understand why WordPress has 54,260 components and Joomla hardly 10 000

Hey don't get me wrong... I hate it if people code in the dark, and do not really know how to do things right (because they are lazy). And yet who knows it all... But my real question, is the JED the place to deal with that. Will that not drive even more programmers away? If Jed is the place, are there not more productive ways, that will encourage improvement, instead of demanding conformity?

I know to build a WordPress plugin (what we call a component) only take one file and a comment, not even code... but they clearly have the market share. So do we really think flagging innovation/dumb code (*who knows) is the right approach? We don't always know if the developer is moving forward, when not using the API, or if he just does not know... and therefore coding in the dark.

I have spend hundreds of hours teaching other to understand the basics of the Joomla API, and approach. Which is what I think is the path to dealing with sloppy programming, teaching them. So instead of publicly wrapping them over the fingers... why not just give them this "feedback" privately as suggestions to improvements (if the issue seems like design freedom - code outside the Joomla approach).

So that there is a difference to serious bad practice and design freedom. I mean we do have freedom right...

dgrammatiko commented 5 years ago

@Llewellynvdm I don't think I quite agree here. JED is something like Apple Store or Google Play. Both have rules. I don't think that you can publish any app to Apple Store if you're not following their API. So nothing really new here. About WP. Yes WP artificially allows more freedom. By the way did you knew that Classic Press was never included in their Extensions Directory (whatever the name).

Anyways the idea is to expose which technologies every app is using and if it diverts from the API. How that will be translated to the actual JED page I have no clue BUT I'm sure that end users will appreciate knowing a bit more about their potential purchases beforehand.

About your fear that this will push devs away from Joomla: well as long as Joomla itself doesn't provide tools to make their life easier devs will continue escaping the platform... The problem is not few flags in the JED, it's the lack of serious tools for development in the platform...

My 2c

Llewellynvdm commented 5 years ago

@anibalsanchez first I am really working hard on this, I mean to give a tool to the Joomla Community to help developers build better more secure and stable components (that follow Joomla convention as close as I know how), it is called Joomla Component Builder and I am very open to any who can show me better paths and implementation so to help newbies and advance devs to get things done right.

Llewellynvdm commented 5 years ago

But we all know Joomla has advanced in to better implementation because some developers found better ways to do things, then the way Joomla's API at the time suggested. So innovation at times needs to prove to the rest who do not want to change, that there is a better way. Like the Unity theme in Ubuntu provoked change in Gnome, yet it took years...

So when you said

JED is Joomla extension directory, if someone wants to do their code ignoring the API then probably they shouldn't publish their apps there...

I just seriously just hope we don't lose the right to be innovative.

Llewellynvdm commented 5 years ago

So the very thing we are trying to do, I mean encourage developers to move forward to better scripts, libraries and stuff. Could be the very thing that trap them in our little world just like Apple has done... but what do I know.

dgrammatiko commented 5 years ago

@Llewellynvdm the suggestions here regarding the API are only for the assets, eg javascript and stylesheets files. And all and all this is more to act like a QA (quality assurance) rather than a firewall. I'm assuming you'll never buy an electric appliance if it didn't have the bare minimum of regulation conformity, right? The idea here is similar to that: provide a bare minimum set of rules for conformity.

I proposed the front end recommendation as these are the current best practices and the whole community will benefit if every dev was enforcing those.

And finally recommendations are not necessarily reasons to not include something in the JED...

anibalsanchez commented 5 years ago

Thank you for your feedback. I've updated the recommendations, and I think that we have enough to produce the next version.

In the new JED Checker version, we are going to have rules that are enforced in the directory and recommendations to improve the general coding.

I'll update the issue with the news.

laoneo commented 5 years ago

Please no forced coding standard on extensions!!

anibalsanchez commented 5 years ago

Removed from the list to avoid confusions.

diddipoeler commented 5 years ago

what is this or what can i do:

001 /sportsmanagement-master/admin/assets/icons/about-favicon.gif in line: 1

info code Pattern found#24 - PHP execution operator: backticks (``)

in a gif file ?

SniperSister commented 4 years ago

Discourage 3rd party extensions importing a custom version of a script shipped in core

That's in fact a requirement for WP plugins: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#13-plugins-must-use-wordpress-default-libraries

More suggestions for your list:

anibalsanchez commented 4 years ago

@SniperSister Great input!

About RIPS, I remember from our last conversation with the CEO that there are two main roadblocks (I've been also discussing these points with @HLeithner at FftF)

anibalsanchez commented 4 years ago

For more information about JED Extensions Checker CI:

hdouglassmith commented 4 years ago

@anibalsanchez regarding RIPS, to avoid both of your issues (wrapper of someone elses extension and pricing) could this be a service that a JED team run as part of the publishing process and where necessary reports sent back to the developer. I realise this is more work for the JED team, but it achieves the goals and desires of using RIPS, provides us with a new level of quality of extension and gives us control over costs and unscrupulous developers.

anibalsanchez commented 4 years ago

Following the idea of simplifying the development and processing of extensions on JED, the Checker CI is going to be a tool for a continuous integration pipeline. In some future, it could even be a command line. The main benefit is to provide guidance in the development. Once that the extension has the JED Checker CI OK, the extension can't be rejected due to technical reasons. Ideally, the reviewer would only review the commercial and license terms of the extension.

If we add more manual steps, we add more delays in the development and acceptance of the extensions. Right now, we are only a few processing extensions and we try our best to clear the queues in a 7-day window. I wouldn't go beyond the current time and workforce limitations now.

Back to the original scope of this project phase, let's create the next JED Checker, to guide in the developers in the creation of extensions with the best up-to-date practices for Joomla 3 and Joomla 4. After we complete the first phase, we can continue adding state-of-the-art technologies to JED Checker CI and/or add a manual security review of extensions. To analyze the impact of a JED4 Security Review in the context of the new system that we are developing, I've just created this ticket: #133

SniperSister commented 4 years ago

@SniperSister Great input!

  • Security Reports Disclosure: RIPS provides top-notch security reports. If JED provides a proxy to the RIPS service. Any developer can wrap PHP code inside an extension to check and use any PHP codebase via JED. For instance, given two competing extensions A and B, the developer of A could create a wrapper extension of extension B and check it for vulnerabilities; and then publish the report broadly as posts on social media.

Indeed that's an issue, that's why I suggested that the review of any RIPS findings should be a manual process by the JED team, just as suggested by @hdouglassmith. I realize that this will require rather big resources (that's why I already looked for volunteers that could help with that specific task), but for me it's very much worth that effort as it will help us reducing the amount of issues in 3rd party extensions, which are damaging the project's image.

* **Corporate Pricing / Subscriptions**: In the past, we checked that the project can afford the price of the service. At glance, it is free for our open source CMS, but since we are going to be submitting paid extensions multiple times (let's say 1,000 monthly checkups). It could easily scale beyond our original estimations.

As far as I know, that board has approved a budget for this.