Recently Browsing 0 members
- No registered users viewing this page.
By John W.
Hi, have a site where I set up a news category, then under that I have different regions where editors in those regions can add news stories. I'm trying to figure out how to allow each editor to only add/edit stories in their region, and not allow editors from other regions to edit them.
Washington County (template:news-region)
My First News Story for Washington County by Editor 1 (template:news-article)
Jefferson County (template:news-region)
A News Story by the jefferson county editor (template:news-article)
Taylor County (template:news-region)
A news story by a Taylor county editor (template:news-article)
I really don't want to create 3 different news-region templates along with 3 different news-article variations, and 3 different types of Editor roles.
Is there a way / module that will let me say, "jane which is an editor can only add and edit to Washington County" and "bill which is an editor can only add or edit to Taylor County", etc? Also, it would be nice to allow the "home office" editor to add/delete/modify contents created by the other editors, a "Super Editor" if you will.
I'm using hook for retrieving data from image metadata (IPTC) after image upload and filling them to some fields. When I choose server-side image resize, everything works well. But when I use client-side resize (which si much faster and client comfortable - it uses PWImageResizer.js) image metadata are lost during resizing - I have downloaded the file after resize and checked for EXIF, IPTC etc. and they are not present. Using PW 3.0.165. Tried to look into PWImageResizer.js but uhh it's too javascreepy to me:)
This post is related to
but is a different way of tackling the problem.
The idea is to use the JqueryUI.module in the front end to present a restricted access admin page in a modal (class pw-modal). However the JqueryUI module doesn't seem to work properly in the front end (I have it working in the back end OK). I'm guessing that this is because the front end page has not loaded all the .js that is needed (that would normally be loaded in the back end). My _main.php loads the following from the core at the moment:
'wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/uikit.min.js' 'wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/uikit-icons.min.js' 'wire/modules/Jquery/JqueryCore/JqueryCore.js' 'wire/modules/Jquery/JqueryUI/JqueryUI.js' Any ideas what else I need, or have I got hold of the wrong end of the stick?
I've decided to get brave and start my first delayed output profile for a remake of my knowledge sharing profile. It went all.good so far but I decided to make it multilingual as to fit the users needs.
For starters, added a field named: image_single and limited the input to one image as this would be used for the logo. Added.the markup to allow the front end editing (method D or direct edit tag to the <img>. After double clicking on the image, I see the pop-up showing up for a second and then closes. As far as there are no errors in the logs, I am a bit stuck to find the reason. I've read earlier that some users had issues with multilingual fields but could not find anything to point me to the right direction. Any ideas or suggestions?
I recently posted in this topic, but I decided to start my own thread because while I believe my issue is related to the one in that thread, they are not exactly the same:
I have created a custom User Template in the method outlined in the docs. I am creating a directory, so it made sense that every page in the directory was a Directory Member, so they could log in and edit their own information while also keeping the entire directory protected behind a login wall.
So the new user type is created: "directory-member".
I then created two new roles: "member" and "directory-admin":
The "member" only has the ability to View directory-member pages, and "profile-edit", which allows them to manage their own information. The "directory-admin" has the ability to edit any directory-member pages, and administer users. Some Directory Members are both, but all have at least the "member" role.
The first hint that something was wrong was when I was testing a "member" user and I could not add a new item to a repeater on that profile. The url for the profile edit (this will be important shortly) is site.dev/admin/profile. The repeater is set up to load new items through AJAX. If this option is turned off, the rest of this issue is no longer completely valid. But as I have found what I believe to be a pretty large issue in the Processwire codebase, I thought it worth bringing up.
See, every page (even a user) has a $page->editUrl() method, and it returns a URL like this: site.dev/admin/access/users/edit/?id=2096. That's all good and fine for users that have page-edit permissions, but if they don't, that link will resolve to the admin's equivalent of a 404.
So the way that Processwire currently gets around this is by creating a specific editing area for a user to interact with only their profile: /admin/profile. And that works pretty nicely, except for the fact that nowhere is editUrl() ever made aware of the difference. editUrl() is not hookable, and whether or not a page is editable is based on the PagePermissions module.
On top of that, there are several core modules that hardcode a search-and-replace (see InputfieldRepeater.module:627) where the editing screen is for Users. This doesn't allow for a huge degree of flexibility that is offered in other places throughout Processwire. If line 627 of InputfieldRepeater is changed from this:
$editorUrl = str_replace('/access/users/edit/', '/page/edit/', $editorUrl); to this:
$editorUrl = str_replace('/access/users/edit/', '/profile/', $editorUrl); ...the AJAX repeaters work. It's maddening!
As is brought up in the thread I attached above, a lot of the features of page editing are missing within /admin/profile/, and it just makes for an altogether strange editing experience. A user who has "page-edit" permissions for templates other than directory-member, but does have "profile-edit" permissions, will see their user in the Page List, but cannot edit their Page unless they hover over the wrench and click the "Profile" link. It just seems - off.
I think what this hinges on for me is that the editUrl() of the user should be "/admin/profile/" if that user is logged in (and their page should be editable from the Page List), or the "/admin/access/users/edit/" url; regardless of the URL, both links should resolve to the Page Edit screen, as the Profile Edit screen seems to be a unnecessarily neutered version of Page Edit.