Tribe Support

Tribe Support's Topics

Scott Crawford

Scott Crawford

3 weeks ago

User registration plugin

I'm trying this week to refactor a legacy registration plugin to be compliant with the 4.3.3 codebase; it had relied a bit on Joomla mainframe & other Joomla syntax.  Few questions:

  1. The plugin validations need to be performed prior to allowing the user to register, so is this best implemented as a 'system' plugin or a 'user' plugin ?
  2.  I see in the system/anahita.php plugin PlgAnahitaDefault class there are functions referenced for onAfterStoreUser and onBeforeDeleteUser ... is there one for onBeforeStoreUser already existing that can be accessed ?
  3. I had previously obtained the form variables using JRequest::getVar( 'variableName' ) syntax... how should these be picked up now that Joomla is removed ?
#plugin #events

1. I think a JQuery plugin or client side verification is still a best option in your case, since it is a legal agreement. You can use a template override, add a checkbox and prevent form submission if the checkbox isn't checked.
2. I am going to add those events before 4.3.4 release. Good reminder
3. it is done using KRequest::get('get.option', 'string', null); search for all instances of KRequest::get to find examples of it in the code.
Unkown Person liked this
Scott Crawford
Scott Crawford
3 weeks ago Permalink
I see the system/anahita.php plugin has been updated as well... so the idea then would be that any user-specific events would be handled just by the user/anahita.php plugin?

I see each of the events now tie in to the person object rather than the user object... would it be more 'correct' for the login / logout to be in relation to the user object, and the save / delete actions be in reference to the person object? Or, perhaps go even more generic i.e., should the save / delete actions be in reference to a generic actor object? I only have the one registration use scenario at the moment, but perhaps others' projects might benefit from these events being accessible for other actor types?
Why not? And yes there is no user object anymore. Viewer is the person object.

Although I like what the guys at Timble have done which is getting rid of plugins all together. All controllers have before and after calls for their actions.
Unkown Person liked this
Scott Crawford
Scott Crawford
2 weeks ago Permalink
I'd been wondering myself what purpose they serve, but some - like the Contentfilter and Storage plugins - I see as nice in that they can be activated or de-activated based on the project.

Authentication, Profile, System, and User each seem like they're naturally part of the base application or components to which they relate. I figured they were transitional holdovers from the legacy Joomla architecture.
Plugins are hooks to intercept the execution process and get some tasks done. Plugins such as the authentication allow alternative ways of authenticating such as checking with a company's user database. Although we can improve the overall architecture to support before and after calls for every action in a controller and also allow a component to inject behaviours to another component's controllers. This way we can gradually phase out the plugins and rely on components only.
Unkown Person liked this

Powered by Anahita