Summary


Hi All,

With latest Joomla! release, super users can access module settings(back end) directly from front end.

But that can be done as front-end com_config does.

 

Along with this PR, I've created a system which can do almost all the essential settings for a module without switching to back end. Because of that, super user can see the changes easily.

 

PR: https://github.com/joomla/joomla-cms/pull/2521

Diff: https://github.com/joomla/joomla-cms/pull/2521.diff

 

Thank You !

 
Opened On:
15 Nov 2013, 5:41 by Buddhima Wijeweera
Closed On:
23 Aug 2014, 8:02
Status:
Closed

Responses

Posted on 15 Nov 2013, 6:12 by Tobias Zulauf

Hi Buddhima,

i move this here to pending since we have your pull request #2521.

But can you add Test Instructions and/or things that we can tested?

Thanks :)
Posted on 15 Nov 2013, 10:53 by Buddhima Wijeweera

Hi All,

Following are the test instructions for Front End Module Editing.

Test Instructions:

1. Apply the diff

2. Add any kind of modules you wish to test (from backend)

3. Make sure "Mouse-over edit icons for" in Global Configuration is set to Modules.

4. Goto front end and login as a super-user

5. Click the "Edit Module" icon on top left of modules (this appears when you move mouse over the module)

6. Change settings, expand accordions to view more settings

7. Click "Save" to save the changes.

8. View the changes :-)

 

Cheers!!!
Posted on 15 Nov 2013, 13:30 by Tobias Zulauf

Thanks! I have add the Test Instructions above :)

@test it looks very nice in protostar Only a very smal thing:

We have at the BE larger Yes/No Buttons (css: btn-group-yesno) is it possible to add it for the FE views too?

But can we add this for beez3 too? Since I can't see the button in a clean install from your branche. (Or i'm bad?)

Thanks and +1 for this PR/Feature!
Posted on 15 Nov 2013, 15:00 by Buddhima Wijeweera

Hi Tobias,

Thank you for testing.

Yes, "btn-group-yesno" is working, the best example is "Show Greeting" field in Login Form.

For me, this works fine in Beez3. I've attached a screenshot of that too. But in Beez3, btn-groups turn into radio button groups.

Thank You!
Posted on 15 Nov 2013, 15:36 by Thomas Hunziker

The accordion doesn't look right in IE11. It only uses the half width and the other half is cut and invisible.

Also it misses the tabs "Menu Assignment" and "Module Permissions" in frontend editing. And the "Advanced" tab has only a subset of the available parameters.
Posted on 15 Nov 2013, 20:09 by George Wilson

Personally I don't think we should have the full set of params available in the front end anyhow. The backend/frontend is a nice point of distinction - and actually permissions and menu assignments feel more backend orientated anyhow.

Agreed advanced should have all params tho.

(sorry for not testing this the other day buddihma i've been hit with an essay I'm slaving away at - will try and test as soon as possible)
Posted on 15 Nov 2013, 23:52 by Buddhima Wijeweera

Hi Thomas,

Thank you for testing this feature. I fixed the issue related to IE.

Yes, I intentionally leftout those fields. As George says, this front end module editing should not be a full substitution for back end module editing. Front end editing is focused to bring most essential settings, because Joomla has more complex back end with all params.

@  Thomas & George,

In front end Advanced section, it only displays fields mentioned in module's xml file (module_name.xml). In back end, another set of Advanced settings get added to it, which I believe not using frequently.

It's okay George, thank you in advance :-)

 
Posted on 16 Nov 2013, 1:20 by Jean-Marie Simonet

@test
As it is today, this works fine. All advanced params can be added indeed as George states.
To check: we now always load en-GB before another language

you may have to chnage from
$lang->load($module, $basePath, null, false, false)
+            ||    $lang->load($module, $basePath . '/modules/' . $module, null, false, false)
+            ||    $lang->load($module, $basePath, $lang->getDefault(), false, false)
+            ||    $lang->load($module, $basePath . '/modules/' . $module, $lang->getDefault(), false, false);
to
$lang->load($module, $basePath, null, false, true)
            ||    $lang->load($module, $basePath . '/modules/' . $module, null, false, true);
Posted on 16 Nov 2013, 1:52 by Buddhima Wijeweera

Thank You JM, I modified language loading.
Posted on 16 Nov 2013, 2:16 by Thomas Hunziker

Thanks for fixing the width of the accordion in IE, that works now.

An important thing is that frontend edit does not check out the module for editing. This needs to be added like in backend to avoid two people editing the same module and overwriting each others settings.

"Start Publishing" and "Finish Publishing" is missing in frontend as well.
I would add all available tabs and parameters to frontend editing. There is no reason to not show them and it would actually be a step backwards from the current functionality.

You could make the main parameters (title, position and this stuff) a tab as well so they hide if someone opens another tab.

The btn-group-yesno class should be added to ProtoStar as well so the Yes/No type buttons are the same width as the other input fields
Posted on 16 Nov 2013, 5:02 by Buddhima Wijeweera

Hi Thomas,

I've fixed the issue with checkout, Thanks for pointing it out.

 
Posted on 17 Nov 2013, 22:18 by Buddhima Wijeweera

Hi All,

Recently I added "Finish Publishing" field.

I advanced section I added missing fields (previously there were only the fields mentioned in module's xml. Now it contains fields get added by com_modules as well).

Moreover, it's obvious adding a field like "Start Publishing" doesn't make sense. (module is at the front end because it's already published).

As a conclusion, I think this feature will not be step back, but a step forward. Currently, after click Edit button on front end, user again need to login to backend. Alsouser need to refresh the front end separately. Because of this both those circumstances are eleminated.

Thank You!
Posted on 18 Nov 2013, 0:48 by Thomas Hunziker
Actually, "Start Publishing" can be usefull as well. Imagine someone publishing a module accidently to early, goes to frontend and sees "Ooops, that should only be visible starting tomorrow".

Personally I still like to see all tabs and options in frontend. Don't take away options from the users if there are no compelling reasons. This may be the case for menu assignments and permissions due to the way they are formatted.
Posted on 18 Nov 2013, 7:20 by Buddhima Wijeweera

Hi Thomas,

Thank you for your use-case, so I added "Start Publishing" field too. I do really appreciate your interest toward this feature.

Thinking about Menu Assignment and Permission is good, but it's not feasible at this stage. Those have more broader scope, since they are not restricted to modules only. Permission may require by number of front end components and Menu Assignment too (eg: Templates). Therfore some kind of generic solution would be appropriate.

Finally, I would be glad to hear about the test results on this with latest master.

Thank You!
Posted on 18 Nov 2013, 14:40 by Thomas Hunziker
Hi Buddhima

Testing looks good so far.

I found another missing parameter in the advanced tab: "Module Style".
Also is there a reason you have a different order of the parameters in that tab compared to the backend? I think having the same order would be helpful.

The "menu assignment" tab is only used by modules as far as I know, or do I miss something?
I can see your point with the "module permissions" tab.

I also commented on two lines directly on your PR where you make specific checks for a module. I'm not sure how this will work with similar 3rd party modules.
Posted on 19 Nov 2013, 11:28 by Buddhima Wijeweera

Hi Thomas,

I solved that parameter ordering issue, but it cost me a new xml file.

Module Style fields still can't be shown in the front end, so I eleminated it.

If you open a template (eg: protostar), you can see Menu Assignment is there.

I also answered for your inline comments. All those conditions are taken from backend view.

Thank You!

 
Posted on 19 Nov 2013, 12:47 by Thomas Hunziker

Ordering looks good now, thanks

Why can the module style field be shown? It should be a regular formfield "chromestyle" to my knowledge. Would be quite nice to have that actually as it affects the appearance of the module the most.

The template uses a completely different "Menu Assignment" tab. So there is not really an overlap. However I agree that a more generic solution would be nice here. I can live without that one on frontend.

As for the check for mod_custom, if it's also in the backend, I would leave it there. But I would remove the check for mod_login as it isn't necessary and only removes options from users for no reason.
Posted on 19 Nov 2013, 13:18 by Buddhima Wijeweera

Hi Thomas,

I've reomved that special condition to mod_login.

For module style, I'm getting following error:

"Fatal error: Class 'ModulesHelper' not found in C:\wamp\www\workspace\joomla-cms\libraries\cms\form\field\chromestyle.php on line 79"

You can also try by adding :

<field

name="style"

type="chromestyle"

label="COM_MODULES_FIELD_MODULE_STYLE_LABEL"

description="COM_MODULES_FIELD_MODULE_STYLE_DESC"

/>

 

as the last field in model/forms/modules_advanced.xml

 

If you will be able to make it working, please let me know.

 

Thank You!
Posted on 19 Nov 2013, 15:56 by Thomas Hunziker

Sounds like a bug in the formfield then. I can have a look at this tomorrow.
Posted on 19 Nov 2013, 21:00 by Buddhima Wijeweera

Hi Thomas,

It's actually not a bug as far as I can see. It  requires a helper file in com_modules, which is not available in the front end.

That file do databae query, but I can't add such a file to front end, because it breaks the whole purpose of front end com_config (using back end as a service and front end just to render).

Thank You!
Posted on 20 Nov 2013, 1:17 by Thomas Hunziker

The formfield shouldn't require the helper file to begin with. Or require_once it if it does. That's the bug :-)

You don't need to solve that in your feature, it has to fixed in the formfield.

I did a tracker and PR to solve this. If you have time to test it see:
Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32766
PR: https://github.com/joomla/joomla-cms/pull/2565

After that fix is applied, it should be possible to have the module style in your feature as well :)
Posted on 20 Nov 2013, 4:30 by Buddhima Wijeweera

Hi Thomas,

I tested and commented there.

Thank You for PR, I'll get that once it is added to master.

:-)
Posted on 25 Nov 2013, 7:13 by Buddhima Wijeweera

Hi All,

I fixed the issue with redirecting after accessing from template position mode.

Previously it was redirecting to just "/index.php". Now it redirects to "/index.php?tp=1" with the help of retrun parameter.

Thank You!
Posted on 26 Nov 2013, 11:49 by Buddhima Wijeweera

Hi All,

Recently I have added support for checkin. Thus, now this feature has following restrictions;

1. When module editing open in front end, checkin shows in the backend.

2. Only the same user can open, same module editing from both back end and front end.

3. No two users can access module editing from front end.

Thank You!
Posted on 27 Nov 2013, 21:40 by George Wilson

@test works as expected. Tested with a few core modules. One of my own 3rd party modules and all fields displayed as expected and changed the parameters fine. Also checked the checkin works. Really nice work Buddihma (and sorry my test is so late!)

There's a handful of good tests here. So I'm marking Ready For Review :)
Posted on 28 Nov 2013, 1:26 by Jean-Marie Simonet

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32766&start=0
has been merged.
Posted on 28 Nov 2013, 5:05 by Buddhima Wijeweera

Hi,

Thank you George for testing this and glad to hear that result.

Also I added "Module Style" field under Advanced section.

Thank You!
Posted on 20 Dec 2013, 4:44 by Jean-Marie Simonet

@test
I suggest to prevent change to the Menu Modules "Select Menu" field by setting it read-only when multilang is on. Otherwise it may create unwwanted results if all the menu items of a certain menu are set to another language than the module edited.
Also, would be good if the feature was available to user with com_modules full permissions. In default Joomla, tis means not only SuperUser but also administrator
Posted on 20 Dec 2013, 4:57 by Jean-Marie Simonet

And also Managers. :)
Suggest using this code:
public function render()
    {
        $user = JFactory::getUser();
        $this->userIsSuperAdmin = $user->authorise('core.admin', 'com_modules');
        $lang = JFactory::getApplication()->getLanguage();
        $lang->load('', JPATH_ADMINISTRATOR, $lang->getTag());
        $lang->load('com_modules', JPATH_ADMINISTRATOR, $lang->getTag());
        return parent::render();
    }
Posted on 21 Dec 2013, 14:50 by Buddhima Wijeweera

Hi JM,

Thank you very much for pointing the above facts. 

I disabled Select Menu option for multilanguage sites.

And, I also change authorise to check user against a perticular module ('core.edit').

Thank You!
Posted on 22 Dec 2013, 1:24 by Jean-Marie Simonet

@test
1. Multilang solved. Thanks.
2. I suggest to limit this feature to users with core.admin, com_modules for security reasons
As it is now in this code for example, an editor can edit a module (Weird default ACL btw in Joomla...) and change its state, the last one being forbidden in ACL but authorised to Publishers (Weird default too as Publishers have also no back-end access by default...).

I really think that by default we should reserve this to SuperUsers, Adminstrators, Managers as the are the ones by default to have com_admin access to the module manager.
Posted on 22 Dec 2013, 23:13 by Buddhima Wijeweera

Hi JM,

The reason behind checking permission for individual module is that, module should be editied according to the permission set with in the module.

Because of this, the user groups who can't access backend, can edit perticular modules' settings via frontend.

Example scenario: Teachers will be able to change content of html module ONLY via frontend, without changing other modules & without giving backend access.

Thank You!
Posted on 23 Dec 2013, 3:31 by Jean-Marie Simonet

@Budhima
I understand where you come from, but the fact is that default settings in joomla install let Editors and up edit any module, including menu modules. That may create real issues.
Posted on 24 Dec 2013, 3:23 by Buddhima Wijeweera

Hi JM,

Thank you for pointing out this potentional issuehere. Editors should not allowed to access by default settings.

According to my observations, ACL in Joomla! is designed considering frontend Content Editing in-mind. But we need to make progress on this frontend editing. Because the support for  frontend editing is something special in Joomla compared to others. And if we skip at this point, in future same issue will araise when making Menu Editing via frontend.

So, there are 2 solutions.

First is to put the responsibility on webmasters to Deny core.edit on Editors (in com_modules- component ACL) when this feature coms out.

Second option is to change sql files such that by default Editors, Publishers, Managers Denied to access modules through frontend.

So, I selected the second option, which will ease the webmasters life, and prevent mistakes.

Currently, I've update 3 joomla.sql files in installation, and looking forward to work with updates as well.

I hope you like this appraoach as well, since it solves the issue.

Thank You!

 
Posted on 24 Dec 2013, 4:18 by Jean-Marie Simonet

@Budhima
Let me disagree here. No one knows which custom ACLs have been implemented on existing sites.
I suggest this solution:
Use as permissions core.admin (or core.manage) (com_modules) && core.edit (module specific id).
Therefore a site administrator will be able to change existing ACLs for FE-only users by editing the com_modules permissions.
For example, if it is desired to let Publishers edit modules in front-end, one change only will be necessary: set Access Administration Interface to Allowed (if core.manage is the final solution) for Publishers.
A specifc user group can be created with no BE login, without any B/C problem.
Posted on 24 Dec 2013, 5:05 by Thomas Hunziker
I would fix the default ACL for com_modules in the installation sql files. That could be done independant from this PR as it's basically indeed a bug and doesn't make sense at all.

I wouldn't make a check for core.manage as the purpose of the (quite new) module ACL is to allow editing for single modules. Together with this PR this will allow you to give permissions to edit a single module to a usergroup which hasn't backend access at all.

What it needs to work without issues is a new parameter in the module manager (or global configuration) which allows to enable frontend editing. Default value has to be off. You can even add a notice in the tooltip which tells the user to check the permissions. If it's disabled by default, no harm will be done.
So don't use the current parameter to show the mouse-over icons (don't remember what your using currently).
Posted on 27 Dec 2013, 6:28 by Buddhima Wijeweera

Hi,

I implemented ACL with core.manage. Together 'core.manage' with 'core.edit' provides the frontend editing.

Since the implemented method is flexsible and can be catered with current access levels, I don't think that there's a need for a new access level.

Introducing a new access level wil affect Joomla in many ways.

1. Make Joomla ACL even more complex

2. If we introduced 'core.edit.frontend' , later day there may need to introduce 'core.edit.state.frontend' & 'core.create.frontend' , Which will create duplications of existing levels and make configuration unnecessarily complex.

3. Introducing new ACL will affect all components, so need to test across all.

My suggesstion is to make 'core.edit' + 'core.manage' introduce as permission to frontend administration interface. And take this in, because currently there's no ACL violations with this.

If there'll be a need for a special ACL, then it can be introduced as a new feature in future.

Thank You!
Posted on 10 Mar 2014, 10:36 by Tobias Zulauf

@test all ok see here:

http://issues.joomla.org/tracker/joomla-cms/2521
Posted on 23 Mar 2014, 10:05 by Niraj Pandey

@test

Tested in Joomla 3.2.3 Chrome Version 33.0.1750.152 on a Macbook and the patch works as expected! 
Posted on 14 Apr 2014, 10:26 by Lara Petersen

@test

Tested in Joomla! 3.2.4.dev and 3.3.0.beta2. Works as expected. 

Without patch: modules editable, opens in administrator backend instead of frontend, in new window.

With patch: modules editable, opens in frontend, in new window.
Posted on 17 Jun 2014, 13:23 by Thomas Jackson

Is this still planned for Joomla 3.4? If so, does it require further testing?
Posted on 17 Jun 2014, 14:14 by Thomas Hunziker

Imho, there is still the issue with the ACL which isn't solved. Other than that it works fine and doesn't really need testing.
Posted on 25 Jun 2014, 17:30 by Thomas Jackson

As this feature is highly desirable to many, what is the process for resolving the ACL issue? Are we still going to try to get this into Joomla 3.4?
Posted on 26 Jun 2014, 2:04 by Thomas Hunziker

The process is that either the original contributor fixes the outstanding issues or someone else forks his branch, fixes the issue and creates a new PR for it.

I can't say if it still can go into 3.4. It depends on when the PR is ready and tests are done and if the release manager for 3.4 wants to merge it. Otherwise it will have to wait for 3.5.
Posted on 28 Jun 2014, 4:37 by Buddhima Wijeweera

Hi All,

It seems people expecting a new permission level for this feature. Today I have added modules.edit.frontend, as the solution for this.

So, now webmaster has just to allow "Front End Editing" Action at Module Manager in Global Configurations. Then webmaster can Deny "Front End Editing" in item-level.

In here, I want to mention that it's still too early to introduce a new action at core level. Therefore this new modification is introduce with less impact on existing ACL system.

Thank You!
Posted on 12 Jul 2014, 6:45 by Sander Potjer

Hi Buddhima,

Thanks for the update.

I'm still not sure if adding a new action for frontend editing is the best way to go at this moment. As suggested in my comment on your pull request (https://github.com/joomla/joomla-cms/pull/2521#issuecomment-39603559) I think the most important thing is to keep the behaviour similair to other areas where we allow frontend editing, like the article manager. 

By introducing modules.edit.fontend we create different behaviour between the Article Manager and Module Manager, which can be very confusing for end users. 

I certainly see benifits of having it as a seperate action, but maybe your pull request should follow the concept of the Article Manager for now. Once added to the core we can look into adding the core.edit.frontend action in general in Joomla, and apply it to both the module and article manager.

Thanks anyway! Sander
Posted on 23 Aug 2014, 8:02 by Brian Teeman

Thank you for your contribution. We have now moved our tracking process to http://issues.joomla.org/ so please do not update the issue here. The link on the new tracker for this issue is  http://issues.joomla.org/tracker/joomla-cms/2521