[#25591] - [4.0] Update CodeMirror paths
- Fixed in Code Base
- 25 Jan 2020
- Medium
- Build: 4.0-dev
- # 25591
- Diff
- SharkyKZ:j4/codemirrorPaths
- Pending Hound Hound is busy sniffing around... Details
- Pending continuous-integration/drone/pr Build is pending Details
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
This removes CodeMirror paths from plugin configuration .
Testing Instructions
Save CodeMirror plugin at least once.
Edit files in template manager.
Expected result
CodeMirror appears.
Actual result
Basic text field appears.
Documentation Changes Required
Base path and mode path are now passed to onCodeMirrorBeforeInit as separate arguments. Plugins that used to modify basePath or modePath params will need to be updated from:
public function onCodeMirrorBeforeInit(&$params)
{
$params->set('basePath', 'path/to/codemirror/');
$params->set('modePath', 'path/to/modes/%N/%N');
}
to:
public function onCodeMirrorBeforeInit(&$params, &$basePath, &$modePath)
{
$basePath = 'path/to/codemirror/';
$modePath = 'path/to/modes/%N/%N';
}
If someone wants to do it, CodeMirror events can be documented here https://docs.joomla.org/Plugin/Events.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Front End Plugins |
Here's some background about why hidden path parameters were added in the first place #5863 (comment). To me it doesn't make much sense either.
Well, hidden is one thing, that might be ok. Visible and so editable (without hacks) is another thing. Not sure if that is good, but who knows, maybe someone has another code mirror instance he wants to use. Anyway, we have so much configurable stuff in the backend, having 1 or 2 things more or less of which 99% of the users will not know what it is good for, that does not make a big difference ;-)
I think I'd rather keep them hidden please. For no reason other than I don't really see the use case for them to most users so no need to add more params to the interface
We need more params in backend to fill up the space gained by the new backend template
@SharyKZ The more I think it over, the more I agree with George: They should be still hidden.
I have not tested this item.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
I have not tested this item.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
Just changing the default value won't fix the problem though. Old value is already saved on 3.x sites.
We could remove these options from manifest files completely. If anyone's actually using this feature, they should really be using onCodeMirrorBeforeInit event to alter the parameters instead of altering the form with onContentPrepareForm to make the field editable and then modifying the value manually.
| Labels |
Added:
?
?
|
||
We could remove these options from manifest files completely. If anyone's actually using this feature, they should really be using onCodeMirrorBeforeInit event to alter the parameters instead of altering the form with onContentPrepareForm to make the field editable and then modifying the value manually.
If that works using onCodeMirrorBeforeInit to achieve this then I'm happy doing that
| Category | Administration Language & Strings Front End Plugins | ⇒ | Front End Plugins |
Fields removed.
If it makes any difference, we could also add class variables for paths to the plugin and pass these to onCodeMirrorBeforeInit instead of modifying hidden params. This way the feature would be less obscure.
| Labels |
Removed:
?
|
||
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
I have tested this item
Test OK
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
| Labels |
Added:
?
|
||
@HLeithner are you asking about not requiring 3.x users to save plugin configuration?
@SharkyKZ after Upgrading from 3.10 to 4.0 it would wouldn't be realistic to request the site owner to go the "each" (we maybe find more of such things) plugin and click save.
I'm reference to this comment
Just changing the default value won't fix the problem though. Old value is already saved on 3.x sites.
Or is this solve when we remove the parameters from the xml file?
| Status | Ready to Commit | ⇒ | Pending |
No, it's not solved. Will have to implement #25591 (comment) to solve upgrades.
good that was my request, if you have time for it ;-)
| Labels |
Removed:
?
|
||
PR and description updated. @richard67 @JazParkyn @anibalsanchez please test again.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.
| Labels |
Added:
?
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-01-25 23:49:52 |
| Closed_By | ⇒ | wilsonge |
Thanks! Adding a docs required tag for this one
I have tested this item✅ successfully on 46266cb
Worsk as described and fixes the error descibed in this PR.
I don't know if it is a good or a bad idea to make the paths configurable, but this shall someone else decide.
For me it is ok.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25591.