Joomla Modules with Permissions and Front-End Editing
•Download as PPTX, PDF•
1 like•4,943 views
This document discusses adding permissions and front-end editing capabilities for Joomla modules. It begins with an agenda and overview of the topics to be covered, including imagining permissions at the module manager, type, and instance levels. It then covers how modules are different than other Joomla elements in having types and parameter fields. The document outlines setting permissions through module actions and settings. It provides a status update that the author had working code for front-end editing involving a new component, library, and plugins. The author is refactoring the code to not require modifications and to allow configuration through a component. The presentation concludes by inviting interested parties to beta test and sign up to receive updates on the project.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Joomla Modules with Permissions and Front-End Editing
Similar to Joomla Modules with Permissions and Front-End Editing (20)
More from Randy Carey
Recently uploaded
Recently uploaded (20)
Joomla Modules with Permissions and Front-End Editing
- 1. Modules with Permissions & Front-End Editing Improving Website Management Randy Carey iCueProject.com
- 2. SlideShare viewers: My slide presentations are highly visual and illustrative, and since you can’t hear me narrate, I provide my narration in the notes section. Each slide includes some narration. To get the most out of this presentation, please open the notes section (below) and read the narration as you walk through the presentation.
- 3. Restaurant: Needs to announce holiday hours
- 4. Restaurant: Needs to announce holiday hours
- 5. Restaurant: Needs to announce holiday hours
- 6. Restaurant: Needs to adjust events listing
- 14. Modules with Permissions & Front-End Editing Improving Website Management Randy Carey iCueProject.com
- 15. iCueProject.com
- 16. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 17. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 18. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 19. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 20. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 21. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo iCueProject.com
- 22. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 23. Modules with Permissions and Front-End Editing
- 24. Modules with Permissions and Front-End Editing Joomla core does not anticipate this
- 25. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 39. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 40. If we have FEE, we need permissions on modules
- 44. Modules with Permissions: at three levels • Module Manager • Type of the Module • Instance of the Module
- 45. Modules with Permissions: three levels • Module Manager
- 46. Modules with Permissions: three levels • Module Manager eXtended
- 47. Modules with Permissions: three levels • Module Manager eXtended
- 48. Modules with Permissions: three levels • Module Type vs Instance
- 49. Modules with Permissions: three levels • Module Instance & FEE
- 53. Modules with Permissions: at three levels • Module Manager permissions: who can edit which modules • Module Type permissions: actions module settings • Module Instance permissions: set permissions per instance
- 54. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 55. DB
- 56. DB
- 57. DB Menu item
- 58. component
- 59. module
- 60. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 64. Modules with Permissions: Types of Modules modules types modules types modules types modules types list of items single item functional content-based
- 65. Modules with Permissions: Types of Modules List of items • category or categories • RSS feeds • Events • latest users • weblinks • showcase/ slideshow
- 66. Modules with Permissions: Types of Modules single item • banner • Breadcrumbs • menu • logo holder • header – image • footer • random image • statistics
- 67. Modules with Permissions: Types of Modules functional • search • login • syndication • language switcher
- 68. Modules with Permissions: Types of Modules content • Custom HTML
- 69. Modules with Permissions: Types of Module Fields
- 70. Modules with Permissions: Types of Module Fields Module’s existence
- 71. Modules with Permissions: Types of Module Fields Filtering
- 72. Modules with Permissions: Types of Module Fields Display – selecting what per item
- 73. Modules with Permissions: Types of Module Fields Display - formatting
- 74. Modules with Permissions: Types of Module Fields Functional login
- 75. Modules with Permissions: Types of Module Fields Content
- 76. Modules with Permissions: Types of Module Fields Content Search box login
- 77. Modules with Permissions: Types of Module Fields Advanced
- 78. Parameter fields for Articles Category Filtering • Featured articles • Count • Category Filtering Type • Category • Child Category Articles • Category Depth • Author Filter Type • Authors • Author Alias Filter Type • Author Aliases • Article IDs to Exclude • Date filtering • Date Range Field • Start Date Range • To Date Range • Relative Date Ordering • By article fld • Ordering direction Grouping • Article grouping • Direction • Month/year format Display • Heading level • Linked titles • Date • Date field • Date format • Category • Hits • Author • Introtext • Introtext limit • Show “ReadMore” • Title+ReadMore • “ReadMore” limit Advanced • Alternative Layout • Mod Suffix Class • Module Tag • Bootstrap Size • Header Tag • Header Class • Module Style
- 82. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo iCueProject.com
- 83. Status at JAB 2013 At the time this presentation was given at JAB 2013, I had working code for front-end editing. The code involve a new component, a new library file, and two plugins. Integration involved [1] touching the module’s XML file (to declare the module’s actions and to tag which fields belong to which action) and [2] overriding the module’s layout template (to inject a couple of simple calls to a couple of library functions). This has worked for every module type that I tried (including the desirable CustomHTML as well as functional modules like Login or Search). Considering how much work is handled by the library and plugins, the integration was relatively simple. But…
- 84. Summer 2013 But I have learned that a solution is valued much more if it can be deployed without requiring the site developer to touch code. So… My current work on this project is to refactor it into a self-contained solution that allows one to configure permissions and inject front-end editing through a component and with no requirement to touch code.
- 85. Summer 2013 I welcome your interest and will make the code available through the iCueProject website. iCueProject.com Please visit iCueProject.com and sign up to receive notices of this and future projects of iCue. Extensions will be distributed through this site.
- 86. Agenda : Modules with Permissions and Front-End Editing Beta testers ??? iCueProject.com Of course, I’ll be welcoming offers for beta testing.
- 87. Agenda : Modules with Permissions and Front-End Editing • Imagine… • Front-End Editing • ACL and Permissions • How Modules are Different • Actions & Module Settings • How to Implement • Demo
- 88. Modules with Permissions & Front-End Editing Improving Website Management Randy Carey iCueProject.com
Editor's Notes
- Imagine Joomla websites where those charged with maintaining it are able to edit modules on the front-end. Let me show you what it is like, and let me share some of the issues to be aware of as we provide this ability to our clients.
- Image how front-end editing of modules should work. In this case, image the manager of a restaurant who has a responsibility to manage the website to keep it up-to-date.
- We could give her access to the backend and train her to be a power user on Joomla. But she is mostly concerned with managing the store and the content on the store’s website. She has no need to learn a CMS nor the desire to invest time in that. She knows what content she needs to change, and (in her eyes) the CMS should not get in the way.
- Image that she merely logs in to the site and she sees edit buttons on the areas she can edit. If she wants to post a notice about holiday store hours… She clicks “Edit,” enters the text into the well-labeled box, and “saves” the changes. Immediately the this updates the content on the site. Imagine that.
- Now imaging the restaurant lists the artists performing in its side room. She wants to change how that information displays on the site.
- In this case, she wants to override the default “callout” module. Normally it displays the next event, but the restaurant has a special event coming up in two weeks, and this event should be promoted into the “call out” display, not whatever event happens to be next.
- Again, a click of “edit” allows her to see those settings and make the changes she needs.
- And perhaps she wants to change some details about how the whole list of upcoming events are displayed. Again, we don’t want to send her to the full-featured backend to navigate to this module and to identify only the fields she needs to change. Instead…
- She finds the section on the front-end that she wants to change. She see’s the edit button.
- A click of the edit button leads to a pop-up of options that are relevant for her to change on the front-end: how many items to display, what categories to include, what is the end date range, should each item include a link or show its hit count, should the event’s intro text be shown and how many words, etc.
- Other staff members have some responsibilities to maintain certain parts of the site. They, too, see the edit button when they log in.
- But each staff member sees only the settings that they are allowed to change. In this case, the staff member has access to just three of the eight fields that the manager can change.
- In this presentation I will demonstrate front-end editing of modules. I will discuss issues with front-end editing and present my solution.Isn’t this what web managers want? Isn’t this what we should be delivering to our clients?
- In my work with the iCue Project I explore the what-ifs about making website management more intuitive to those who manage websites. For instance, here is an example of the simplified role-based backend that I deliver to my web clients. It’s all done in Joomla, and it is tuned to the needs of those who need to manage the website – not a hand-me-down of what the developer needs for building the site.
- Here’s the agenda. I already had you imagine what the client experience would be like if we added permissions and front-end editing to modules.
- What is the value of Front-End Editing?
- What do we mean by “permissions” and how do they fit into Joomla’s ACL?
- Modules are different from components. What does this mean for permissions and front-end editing?
- Components have actions like “create,” “edit,” and “delete.” For front-end editing of modules, we need to discover and declare an appropriate set of actions per module type. How do we do that?
- I have built a system that allows one to create actions, assign permissions, and allow front-end editing of modules. Here I show how to add my code to your modules. This code is still being developed, and I encourage you to sign up at iCueProject.com for updates and access to the code.
- A demo of front-end editing of all types of modules – according to various permissions, of course.
- Before I continue, a few words… When I have given my “Role-Based ACL” talk I have shown this diagram of the ACL. I show that permissions (shown here in green) are deployed only within components. I state that there is no reason why we can’t use permissions on modules. So I decided to develop this talk to show how it can be done…
- As I started to implement permissions on modules I ran into the realization that the Joomla core currently does not anticipate that modules will use permissions nor that modules would offer front-end-editing. As a result, many of the conveniences of implementing permissions and front-end editing on components are not available to modules. That is a strong reason why modules have not been implementing permissions nor front-end-editing.I do not hack the core – I always “extend” the core. So to accomplish the implementation I wanted, I had to write a good amount of extra code. Fortunately, I am able to integrate my extended code with minimal work on your part.
- What is the value of Front-End Editing?
- [left] We as site builders understand all the details behind Joomla. [right] Our clients and their website managers do not. They see the website as a set of pages and as visual parts upon any given page.
- It is not wise to impose our “inside” and technical view of the CMS upon the client and content mangers.
- Rather, we should seek to offer our clients content management that matches their mental model of the site. They know how to navigate to a particular page and they know what on that page they want to change. We offer a better user experience if we can give them a way to edit according to their mental model of the site.
- We already have front-end editing of components. (Well, of the components that chose to implement front-end editing.)
- But try to tell the client that they can front-end edit only one piece on a webpage full of pieces. They want to be able to edit any part of a page – in other words, they want to be able to edit modules from the front end.
- This represents my ideal of front-end editing. When a user is logged-in to the front-end, all the parts he/she is able to edit will have some edit button showing. Click on the edit button, and just that bit of information that is relevant will be editable. In this example, the user can edit the phone number, the lead-in text for the category “Entrees,” and the price of each item on this restaurant’s menu. Now that is something that restaurant staff would find helpful, intuitive, and easy-to-do.
- A question that I’m not hearing anyone else ask: If we can edit _any_ thing on the front-end, should we make _every_ thing editable on the front-end?I take the cautious position that we should not. I feel that front-end editing helps if that type of content/editing corresponds to the user’s mental model of the site. But a lot of things clearly do not align with the front-end view of web pages. Let’s look at some types of editing and consider whether they are better served by front-end editing or by an “admin” type of screen…
- Content and the display of content (through components and modules) beg for front-end editing. As I said, they match the user’s mental model of the website. The user can “see” the item they are editing.
- But then there are lists of content items. Through these lists we categorize them, order them, toggled which are featured, search for an item among large lists, and manage which are published/unpublished/archived/trashed. Such tasks don’t really map to the front-end. They demand that the user has a “forest” view of all the items. At best, maybe we can reach a list view from the front-end, but the management of a list will probably work best with a screen similar to what we’ve come to expect.
- Some parts of a website are actually web applications. Consider a ecommerce application. One has to manage inventory, pricing, payments, orders, fulfillment, etc. These typically use some sort of dashboard that only a privileged few can access. Each task and workflow doesn’t really correspond to the mental model of a web page.
- Structural things like menu item management clearly requires an ”inside” or “backend” perspective. There are consequences to adding or changing structural parts of the website. Does the casual front-end user know what all these are (module assignments and the options for each, page types, access levels, language selection, etc)? What if a change is made that removes the page one is editing? Are we not opening a can-of-worms by allowing casual front-end editors to edit structural details of the site!?
- And then there are obvious administrative tasks: ACL, user management, global settings, etc. These are abstract have no obvious mapping to the front-end. Again, you can make these accessible on the front-end, but such management screens probably won’t be tied to the mental model of a website’s front-end.
- Clearly the real value of front-end editing comes from editing the visual parts of the front-end. This is because they match the user’s mental model of the website. In contrast, many details really don’t have a connection to this mental model, and if we do create front-end editing of these things, those screens probably won’t look much different from what we are accustomed to now.
- What do we mean by “permissions” and how do they fit into Joomla’s ACL?
- First. If we have front-end editing, we need to have permissions. We have to know who can edit which modules. And we need to know how much of any given module a person can edit. Before we can implement front-end editing of modules, we _have_ to implement at least some level of permissions.
- This is the diagram I use to explain Joomla’s ACL. Notice at the top are the “resources” in Joomla: components, modules, menu items, and plugins.
- The rounded box here shows what lies within the ACL system. The ACL controls groups and access levels. But when it comes to permissions, the ACL can only respond as to whether or not a particular user is allowed or denied to perform any given action on a given component. It is the component that has to declare which actions it will recognize. And it is the component’s responsibility to enforce the permission. The ACL cannot force a component to do this nor to do it correctly.
- Again, note that currently only components implement permissions. The ACL can’t force modules to implement them. And if we as developers or site implementers want permissions on modules, either the modules need to implement them …or we need to “wrap” them in an implementation that adds and manages permissions.
- When we talk of “permissions” in terms of “module,” what do we mean? Let’s look at each of the three perspectives of “module.”
- The Module Manager looks at the group of modules. Unfortunately, the closest we currently come to permissions and modules is that the Module Manager has an action to allow a user backend access to all modules or no access to any module. Permission is set on the manager of modules, not on the modules themselves. At this level, what we really want is to be able to declare which modules are accessible to any group of users.
- I am currently developing my solution to this. I have extended the Module Manager (using object orientation to extend the code), offering a new version of it without replacing or changing the core Module Manager. In this view, an added column that is available to those who can assign permissions per module.
- Click on the icon and you see a list of groups all on one screen. Check the groups that should have access. It’s that simple. Just check a box assign access for a group to any given module.(I do realize that this is not modeled exactly after the inherit/allow/deny scheme of the ACL. I’m experimenting!)
- The next thing to consider is “type” versus “instance.” As you can see here, the type of module can have multiple instances. Each instance can differ by its position, by the pages it is on, by access level, by language, and by any/all of the settings within that module. … So we need to think through as to how we apply permissions to modules – what things do we assign by type and what things do we assign to each instance of a module?
- After careful thought I have concluded that we should be placing the permission to edit (at least front-end editing) on the instance. It is the instance that has a particular place on the front-end, and thus it is the module’s instance (not its type) that matches the user’s mental model.
- Let’s think about how we set this up.First, remember that the ACL provides us the ability to create the groups and then assign users to groups.
- Then keep in mind that the component declares a set of “actions” that can be performed upon in. Typically we have the standard list as you see here.
- And when we assign permissions… we select a group and set the permission (inherit, allowed, denied) on that component’s action.Now, for modules… Likewise, we will need to declare the actions for each and we will need to store the permission settings.
- So this is how I feel it is best to set up modules with permissions. [1] The Module Manager allows us to set access to each module instance. [2] The module type is where we declare the actions that can be taken on the module instance.[3] We declare and enforce permissions upon each module instance.(There might be some value in assigning permissions on the module type – providing default settings. But ultimately, we need to allow permissions to be set independently per instance of a module.)
- Modules are different from components. What does this mean for permissions and front-end editing?
- Components involve content and write their content straight to a database table dedicated to that component. In contrast, the module stores information about how to display content and then pulls in the content from the component tables. IN CONTRAST… The module is mostly concerned about the view of whatever content they get from the database.
- So the component is about the CONTENT. The module is about the DISPLAY of content.This argues that front-end editing of the module should be mostly about the display of its content. Arguably, the editing of a component’s content should belong to the component - not to the module.
- You might protest and say that components are also about the display of content. To some extent this is true, but to a larger extent the display within a component’s position is from the menu item, and as with modules, the same component content can be displayed differently by the use of different menu items. So stated again… the component is more about content, and the module (and menu items) are more about the display of that content. These are two different types of concerns.
- This has strong implications of the actions we declare. Most components rely upon a core set of actions like configure, create, delete, edit, edit state.
- But modules, in contrast to components, are not about content. When it comes to modules, we need to rethink the set of actions we declare. They need to be tuned more to the display of data (not to the management of the data itself). Here are some examples: front-end editing, filtering, display, link settings, advanced (e.g., alternative template to use).Actions for a module are “cut from a different cloth” than are actions for components.
- Now that we realize that the actions we declare for modules are most likely different from those of components, we need to think about how we discover the actions that are appropriate for any given module type. How do we approach that task?
- We need to remember that we are setting permissions that involve the display of parts on a webpage. We need to think about what the staff person who is performing front-end editing probably wants to accomplish.
- We do this staff person no favor by giving them the entire slate of settings that comes with a component. Instead, we give them just the one or few settings that will change the display in ways they want, in ways they can visualize, and in terms they understand.
- So the task at hand is [left] to determine which of the module’s settings do we want to make available, and [right] how do we segment them into meaningful actions?
- As I reviewed dozens of modules, I recognized four groupings, each seeming to suggest certain actions…
- Modules that display a list can have meaningful actions like filtering, grouping, ordering, and count.
- And some module types refer to a single item. An action for modules of the “single” type can be the selection of the item, or formatting details about the item.
- Some modules exist only to provide a function. These often involve the edit of lead-in text or labels, display issues like the inclusion of a button or the width of a text box, or perhaps some variable within the function (e.g., to which page to send the user after logging in).
- And, of course, there is the content-centric module, Custom HTML. It’s all about the content to display, but arguably it can include formatting details to add to the displayed content.
- After looking at the types of modules, the next thing to look at are the types of settings within modules. (Shown are the fieldsets for “article categories.”)
- Every module has these fields, and *** I don’t think they should be included in front-end editing ***. These fields affect the location and very existence on the front-end. If a front-end editor changes one of these, the module might disappear (either going to a different position, a different page, or be removed altogether). This behavior is no longer intuitive to the front-end user and could cause serious problems. Arguably, if someone needs to change any of these settings, that person should be doing so from a “forest” view such as what we get in the backend.
- Filtering types of settings could lead to the same problem – the module might no longer have any items to display and in some cases a module will disappear along with its edit button. But filtering is a valuable feature for front-end editing, and these settings should be included as needed.(My current solution to prevent a module from disappearing is to not save the changes and warn the user that the requested settings would make the module disappear.)
- For each item to display, we can set what parts of that item should be displayed.
- And for the content pieces to be displayed, we may have formatting options that should be offered.
- Functional settings are more abstract, but they should be considered. Should we include links? Should we include a “read more” feature. What is the landing page for those login in or logging out?
- And, of course, there is the type of field that edits content. Not content from the component (remember, that is the component’s responsibility), but content that is held by the module. Yes, the html content of the “Custom HTML” module is stored within the module record. So this html/text should be available through the module for front-end editing.
- But don’t forget that any type of module can contain “content” that is stored by the module: such as labels and lead-in text. Think of this… we can edit any module’s XML file to add text and text box fields which will add content to the module – and thus allow us to provide front-end editable content to any module!
- Every module contains an “Advanced” set of fields. Some of these have questionable value for front-end editing. Others can open up some very interesting possibilities. …Imagine allowing a staff person to change the alternative layout for a module through front-end editing.
- So our task… We have to choose which settings on a module we will allow for front-end editing, and to group them into meaningful actions. Shown above is the set of settings for the Article Categories module. It is a sizable list, and our task requires some careful thought.
- Perhaps in many cases we create just one simple action that allows front-end editing, and then anyone who has that permission sees the same set for fields.
- In some cases we might want to break the module’s fields into multiple actions. This accommodates a rich role-based approach. Each person who can edit will see just those settings that are relevant to his or her role.
- However you split up the actions and the settings per action, remember that we provide front-end editing to accommodate the user’s mental model of the site and its content.
- My coded solution, and how to implement for any module…
- Our clients have real people with real and varied responsibilities for managing the business and the website’s content. Joomla’s ACL allows us to model these “roles” into website management.
- At this point during the live presentation I demo front-end editing. Eventually, I will have video demos available through iCueProject.com
- If you find my thoughts and approach interesting, please subscribe on the iCueProject website (iCueProject.com). Modules with permissions and front-end editing is just one of the issues being tackled here. The goal, of course, is iCue: Improving the CMS User Experience – though Joomla implementations.