Jump to content

MarkE

Members
  • Posts

    992
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by MarkE

  1. Interesting module. Historically, I have achieved a similar result by hijacking TextformatterHannaCode, but this looks like it might be a better way.
  2. Until it is in the modules library, you can get it here https://github.com/MetaTunes/AdminInModal EDIT: Now in the library, Also I have released v0.3.0 which allows the defaults to be configurable.
  3. No. You have to click the close box. It will reload the launching page (configurable). I could look at adding that.
  4. I thought I would share this as I am finding it increasingly useful and am often using it to replace the standard PW modal. It allows display and customisation of admin page in front end as well as back end via a modal. In the modules library at https://processwire.com/modules/admin-in-modal/ . Also here https://github.com/MetaTunes/AdminInModal This module provides a Page hook method ($page->aim($array)) for front-end use and a similar Inputfield hook (for back-end use) to render a link to a lightbox modal containing an admin page. Optionally, class styling can be passed, otherwise default button styling is supplied. Full list of options and defaults for the array is : 'href' => null, // the url for the linked page (including any required GET params) 'text' => '##', // the text that will appear in the link 'class' => "uk-button uk-button-primary", // any suitable styling for an <a> tag 'width' => '90%', // size for iframe 'height' => '95%', 'header-text' => 'Save required changes before closing -->', // Text to appear above top left of modal 'save-head-button' => '1', // Adds a save button at the top of the modal. Set to '0' to omit. 'suppress-notices' => 'messages', // e.g. null/[]: no suppression, 'messages': suppress messages, 'warnings messages': suppress warnings & messages, 'errors': suppress errors 'close-button' => '1', // set to '0' to remove close button (but you'd better be sure you know how the modal will be closed!) 'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress) (From v0.3.0, these defaults can be configured in the module settings). For front-end use, the lightbox will only be rendered if the page is editable by the current user. Configure editability of the page by calling a hook after User::hasPagePermission The lightbox is provided by the Magnific popup, which is in the PW core. Although I have used it quite a lot, I cannot say that it has been fully tested, so is alpha at this stage and should be used with care. It is the user's responsibility to check that it suits their needs. Because it allows access to the admin back-end, particular care should be taken to restrict page-edit access.
  5. Absolutely. I have one app where I have separaate sites for the public website and the admin website. I did it this way because the confusion of templates and fields would be too great otherwise, but the two sites need to interact (booking availability for holiday lettings). However I encountered a number of problems as a consequence and a neater way of doing it would be great, as well as fitting in with the suggested move to a more (or even more) 'app-capable' approach.
  6. Hmm. I have a lot of sympathy with this, having created a number of quite complex apps, but wonder whether it can be done while maintaining what currently makes ProcessWire so distinctive. Would it lead to a more direct comparison with competitor “full frameworks” and possible future compromises? I have managed to accomplish quite a bit of @Robin S’s objectives using process modules and my AdminInModal module. A more core way of doing it would be nice, however.
  7. See https://github.com/MetaTunes/GoCardlessConfig I built this little module to hold some API keys for GoCardless as I wanted them to be accessible by superuser but without having access to underlying files and code. I'd be interested in views regarding the security of this approach. I realise that there are more secure ways of holding API keys, but a balance has to be struck between usability and security. To avoid inadvertent disclosure or amendment, it requires the superuser to re-enter their password to access the keys. It could easily be amended to hold other types of keys, if that is useful to anyone. Any improvements are also welcome!
  8. This is not really a question or a tutorial, but merely an observation in case it helps anyone else. I have a site which I built before the custom page classes became available in the core, using a similar approach to this: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ To achieve this, I set the pageClass property of the relevant templates to be the same as the template name. I have now refactored the site to use the core custom page class functionality. I didn't change the pageClass property. Until then, I hadn't realised that $template->pageClass and $template->getPageClass() would yield different results, but they do. For instance, if the template name is 'Collection' and the pageClass property is set on the system tab to be 'Collection': $template->pageClass is 'Collection' $template->getPageClass() is: 'Collection' if that class exists (this was the case in my initial implementation - hence why I didn't realise the difference between pageClass and getPageClass() ) 'Page' if the Collection class does not exist and $config->usePageClasses is not set 'CollectionPage' if that class exists, the Collection class does not exist and $config->usePageClasses = true 'Page' if the Collection and CollectionPage classes do not exist and $config->usePageClasses = true In the last two cases, getPageClass() will output a warning "Template '$template' page class '$pageClass' is not available" Removing the pageClass property from the template results in: $template->pageClass is '' $template->getPageClass() is: 'Page' if $config->usePageClasses is not set 'CollectionPage' if that class exists and $config->usePageClasses = true 'Page' if the CollectionPage class does not exist and $config->usePageClasses = true In this case, no warnings are output. Bottom line: if you are migrating from the 'old' approach to the use of core custom page classes, beware of any instances of $template->pageClass as you may need to change them to $template->getPageClass().
  9. Thanks @BitPoet. I can't get that to work, but this does work: $this->wire()->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { $form = $event->return; foreach($form->getAll() as $f) { // Check if this is the repeater field you want to modify if($f instanceof InputfieldRepeater && $f->name == 'motif_image_component') { foreach($f->value() as $repeaterItem) { $toggleField = $repeaterItem->getField('motif_toggle_position'); $value = $repeaterItem->motif_toggle_position; if($toggleField) { $yesLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->yesLabel; $noLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->noLabel; $otherLabel = $repeaterItem->fieldgroup->getField($toggleField, true)->otherLabel; $toggleField->set('yesLabel', $yesLabel); $toggleField->set('noLabel', $noLabel); $toggleField->set('otherLabel', $otherLabel); } } } } }); I guess it would be nice to make it generic - which your hook tries to be. I can't see how to do that with a buildForm hook. However, I wonder whether it is worth raising an issue here, since surely all labels for a repeater field should be in the repeater field template context?
  10. That's exactly what I've now done and it works fine. It was a bit of a hassle refactoring it, but worth it. Thanks to all ?
  11. That's pretty much exactly what I am doing. I thought the permission would only apply to the page as well, but it seems that I am wrong. That doesn't work as it needs the permission to load the module with noPermissionCheck ?. It just results in "You do not have permission to execute this module..." without even any debugging! ?but it was a bit late last night Yeah I thought about that, but it was going to be a bit of a hassle compared with my little hack. Undoubtedly this is the right answer given that I (together with@Robin S, so I am in good company) was wrong in my assumption as to how the permissions work. I note that 'Process module king' @bernharddid a little module "RockHitCounter" where he adopted this approach, presumably for the same reason - so that the page is in a separate Process module with the permission, which is installed by the main module which has no permission.
  12. Perhaps I should have elaborated more: the methods (and static functions) are entirely called within the API from Page Class scripts, so the requests are not coming directly from the front end. Perhaps that gives me a clue - to assign the permission before making the calls? EDIT: So I added this around the main include script for the rendering using the module and it seems to work well without having to manually set (or save) permissions: //Assign the required permission to access the ProcessMotif module temporarily $guest = $roles->get('guest'); $guest->addPermission('admin'); $guest->addPermission('admin-motif'); // NB the permissions are not saved include_once(wire('config')->paths->siteModules . 'ProcessMotif/include/_motif_include.php'); //Remove the temporary permission to access the ProcessMotif module $guest->removePermission('admin-motif'); $guest->removePermission('admin');
  13. I have built a custom page-builder module 'ProcessMotif' (to be released if I ever get it working to my satisfaction!) and have hit a small snag with permissions. The module is a process module and has a page that I want to appear on the main menu and be available to certain roles. The only way I can seem to get it to appear like that is to set the permission 'admin-motif' in the module info and assign it to the relevant roles. Without that permission set, the page is only visible to superusers. However, the module also has a whole bunch of methods that need to be executed by guest and other users to navigate the site. If I give the module a permission, then I need to assign that permission to the guest role otherwise they can't see anything. I don't want to have to do that. I get the feeling that I'm missing something obvious and basic here, but I've read all the stuff about process modules (especially the excellent stuff by @bernhard here and here) but am none the wiser on this point. Anyone got any ideas? Ta.
  14. Repeater fields allow you to customise the labels - eg '#n {title}' where title is a field within the repeater field. One of my repeaters includes a (3 position) toggle field 'motif_toggle_position': the base field has just 'Yes', 'No' and 'Other' labels for the three positions, but I have modifield this in the repeater field template context to be 'Left', 'Centre' and 'Right'. It is those context-dependent labels that I want to appear in my repeater field labels. '#n {motif_toggle_position}' gives me the base field labels, not the context-dependent labels; how do I achieve that? My friendly AI suggests using a hook on ProcessPageEdit::buildForm (hooks with subtle syntactical errors seem to be its solution to most problems ?) but I was hoping there would be a more 'natural' way. In fact, given that the repeater label is within the repeater field template context, I don't understand why the base field labels are given in preference to the context ones anyway.
  15. At the moment it is for my own use, but if I like it I will probably tidy it up and release it.
  16. Another issue for anyone else using this module: Line 625 of ProcessEmailToPage.module has $attachment['filename'] = $this->sanitizer->pageName($attachment['filename'], true); I don't know why the pageName sanitizer is being used to sanitize a file name, but this gives an incorrect result if the file name has brackets in it. In my version, I have changed pageName to fileName.
  17. Hi @joshua. I'm developing a little Matomo module myself, which will also have a 'dashboard' in PW to embed various widgets. The plan is to do it so that it is GDPR compliant without any 'unnecessary' cookies. Your code is very similar to what I have done so far. I hope it's OK to borrow some of your code (with credits!). ?
  18. That’s great @ryan. You may call it a “simple” module, but it think it will be an important addition to ProcessWire’s capabilities.
  19. Thanks @adrian. There's so much in Tracy that I still haven't fully explored. That actually seems a really useful feature. Now I understand why it's called 16 times - because my site has 16 roles (which needs a bit of rationalisation, I think!).
  20. Sorry - maybe I confused things by providing the context: that was just an explanation as to why I added a bd to the hook (to try and understand how it was being triggered). I was then puzzled that Tracy appears to call it multiple times - in my case 16 exact same repetitions. Try this in ready.php wire()->addHookBefore('Page::moveable', function(HookEvent $event) { $page = $event->object; bd($page, 'page'); bd(Debug::backtrace(), 'backtrace'); }); Then open the page tree. Tracy appears to call the hook multiple times for page id 3 ('page'), but I don't understand why. In my case I got 16 of the dumps illustrated in my OP.
  21. I'm puzzled. Last night I thought I had a nice working pair of hooks - see here: Today it is not working. I put a bd in the hook before Page::moveable and I get 18 instances of the page being 'page' when viewing the page tree. I put in a bd(Debug::backtrace(), 'backtrace'); and I get another 18 instances of this: so the hook seems to be called (only) by Tracy. What is going on?
  22. Thanks @Robin S. I also need to prevent changing the parent by moving in the page tree, which I had previously sorted here - The combination of your hook with my second hook in that link seems to work well.
  23. An alternative approach here is to use an idea from @Robin S here to prevent access to the settings tab thus preventing changing the parent there, then the hook on Page::moveable covers the interaction in the page tree, in which case no need for the slightly complex first hook in my OP.
  24. I want to lock a page from all but superusers doing the following: changing ID, name, title, parent or template deleting the page But I want them (or, at least, users with the appropriate access set at the template level) to be able to edit other fields on the page. The description on the settings tab makes it look like setting 'system' status will achieve this: "System: Non-deletable and locked ID, name, template, parent" However setting system status disables ALL editing by non-superusers, even when all the correct permissions are given, so that description seems misleading. (a) Am I misunderstanding something? (b) Is there a simple way of achieving my objective?
  25. Only just saw this @flydev. Meanwhile I solved the problem as shown here: Your suggestion is absolutely spot on! But at least I worked out exactly why it is necessary. Many many thanks for your persistence in helping me to solve this problem. I have learned a whole lot more about ProcessWire along the way!
×
×
  • Create New...