make the plugin use the event system fully is my vote. Having a more real life scenario usage of com_ajax (I think only the stats plugin currently uses it) would also be a positive thing

I'm with george, event too

Suggest to remove it completely from core and provide it as a core supported extension.

Decoupling is on permanent hold for now for a variety of reasons discussed in the plt meeting minutes from Barcelona and Prague the year before

Until all these issues get solved (and maybe they will for J4 - I'm unsure at the moment) then we are going to stick with what we have

I'm not sure if this is even possible, and sorry for the RFC hijack, but what about we move the hits part to a plugin too?
IMHO many sites really don't need it and making update SQL queries on article load is rather performance costy.

Part of the issue with that (Robert's tried it) is with caching enabled
none of the component plugin events are triggered, which is why it's all
structured the way it is now. Otherwise I do think it'd be nice to have
that as a pluggable behavior that could be used for all extensions.

On Friday, October 7, 2016, andrepereiradasilva notifications@github.com
wrote:

I'm not sure if this is even possible, and sorry for the RFC hijac, but
what about we move the hits part to a plugin too?
IMHO many sites really don't need it and making update SQL queries on
article load is rather performance costy.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#12331 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoQF-7NzZrX5VtDOwzKoqxQCgCqyjks5qxkoqgaJpZM4KQgAs
.

with caching enabled

do you mean page caching?

Can't we add an ajax call with token and article id to make the hit?

No. Plain conservative caching will do it because of how JControllerLegacy::display() works (the component output gets cached so the view class never gets triggered).

Ajax would work for that too.

so we could have an hits plugin that inject an ajax script to the document onContentPrepare that calls an ajax URI (ex: components/com_ajax) ex : <script src="/media/system/js/hit.js?task=article.hit&id=[id]&[token]=1"></script>

I'd be OK with that.

Decoupling is on permanent hold for now for a variety of reasons discussed in the plt meeting minutes from Barcelona and Prague the year before

Can someone open a workspace to work through whatever the issues are of this instead of PLT deciding it's too hard (especially after Nic has been told to make his work a decoupled extension)? Seems like either the community should be figuring out this issue or we reverse course and we re-integrate weblinks into core and be done with the experiment.

Decoupling (Chris)

We still are committed to our decoupling program.

However the PLT still feel there are issues in terms of releasing and the logistics of maintaining and releasing components.

There has also been a problem with keeping track of open PR’s in the weblinks github - if we decouple most core components then we also will have a maintainability issue. As a result Chris D. is going to take charge of maintaining Weblinks.

Furthermore we feel that shipping core as empty would be a turnoff for people new to Joomla so the logistics of bundling some components when building the CMS (that could be uninstalled) is also something that needs investigating.

https://volunteers.joomla.org/leadership/production-leadership-team/reports/245-plt-meeting-after-j-and-beyond-2016

I found the notes, but they are vague at best. What are the issues with the release workflow or the maintenance of these decoupled solutions? The issue queues would be similar for the specific extensions whether they are part of core or not. The only thing that changes is the number of repositories one must make a change in to support new features, or someone finally making a decision about configuring our update systems correctly so that each extension package (general statement for both weblinks and languages now) does not require supporting back to 3.0.0.

As for the empty distro issue, there are ways to deal with that. https://github.com/JLite-POC/Framework is one idea (which is essentially the language install stuff converted over). Anything more "advanced" probably isn't practical as long as our entire install routines are based around static SQL dumps instead of proper use of the PHP APIs to load data.

Everyone and their mother had an opinion on things when we first started this process (and Composer) over two years ago. Surely there are more answers floating around if someone would open a workspace to address them.

Just to let now that make a PoC for the hits plugin (using com_ajax) andrepereiradasilva#94 . If anyone wants to check and comment there i would apreciate it.

PR - #12516

Reopening due to the PR now being in an unusable state.

Because of #11225 at a first review the only option to go forward IMO is to remove the plugin and integrate its functionality directly into com_content. The worse option is to rewrite the plugin to essentially overload com_content as there isn't a way to hook into the MVC layer to perform the added functionality from that PR.

We can consider reverting parts of that PR. For example displaying the columns with votes in could be revoked. Filtering by votes should still be possible in the plugin right? Because we should still call the prepareForm event on the filter xml form

The form can be hooked into but without query manipulation events or overloading the MVC layer what are you going to do with the data?

Looking through the comments, they are about how the function of voting will work.
I'd like to point out that once voting data is collected, more functionality needs to be available, such as sorting articles based on vote count (low/high) in all areas where article sorting is possible (list, blog, featured, etc.)

This is possible in 3.7 and why the previously referenced pull request splitting the functionality to be 100% plugin driven was closed.

Already tried once, this is going nowhere.