[#13362] - Load contact plugins in the whole contact component
- Closed
- 8 May 2018
- Medium
- Build: staging
- # 13362
- Diff
- bembelimen:contact
- Success continuous-integration/drone/pr the build was successful Details
- Success continuous-integration/travis-ci/pr The Travis CI build passed Details
- Success continuous-integration/appveyor/pr AppVeyor build succeeded Details
- Error continuous-integration/jenkins/pr-merge This commit cannot be built Details
User tests: Successful: Unsuccessful:
Summary of Changes
At the moment you can create a contact plugin to handle the email sending by yourself. But this function makes (mostly) only sense if you add new fields. Adding new fields is only possible with content/system plugins, so you need at least two plugins or a system plugin. This makes the contact plugin a bit useless.
This patch loads the contact plugins within the whole component, so a contact plugin can adjust the form and handle the email stuff.
Testing Instructions
Here you need a contact plugin which e.g. change the form. Before: form is not changed, after: form is changed.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_contact Front End |
The other thing about it, while I'm thinking of it, is if you're using the models to do something (like saving a contact when another action happens), the model should be importing the required groups before it triggers events. With it this way, that wouldn't happen.
A completly other idea: perhaps we should deprecate and remove the contact group, because at the moment you can perform all the task, which add this patch, with a normal content plugin...so a contact group does not make any real sense here?
You don't need groups at all, it's just an artificial way to limit how many of the plugins are actually loaded into the system. I'd rather see the concept as a whole phased out in favor of better overall event management and registration, but the couple of people I've brought that up to groaned miserably.
Yes I know, it just matter, which plugin is loaded...I know, we could throw everything in system plugins and everything would work.
This patch is a try to stay B/C...
As we now have custom fields in the core is there really a need for this?
As a concept it's fine (there are events that fields aren't used with), the implementation though is wrong as I pointed out previously.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-05-08 22:13:27 |
| Closed_By | ⇒ | brianteeman |
Plugin groups are generally imported near where events get dispatched so this should be updated to do the same (yes, I realize that means the call is required in more places, but that prevents unneeded loading).