adrian

Hi @sebr - firstly, I am really sorry about the issue you experienced. I am surprised that the data was reset after it hit the character limit of the text field - perhaps that's a PW core behavior, but not really sure without Ryan's input. Turns out I've had a similar issue before with my BatchChildEditor module: https://github.com/processwire/processwire-issues/issues/321 - as you will read, Ryan has good reasons for not wanting to change to mediumtext. But, making that change will be fine in terms of upgrading not breaking things. What I am curious about though is why the settings has become so large for you with the PageProtector module - are you making use of parent restrictions, rather than protecting all the individual child pages separately? That should dramatically reduce the size of the stored data.

Hi @Mike Rockett - not sure how this hasn't been reported before so it makes me wonder if I am missing something, but when using the "Templates without sitemap access" option, these exclusions are only applied to top level parent pages. To fix things, I added the in_array check to the $page->children loop, like this: // Check for children and include where possible. if ($page->hasChildren($selector)) { foreach ($page->children($selector) as $child) { if (in_array($child->template->name, $this->sitemap_exclude_templates)) { continue; } $this->addPagesFromRoot($child); } } Does it make sense to include there?

Regarding the DB backup - I need to switch that from using PW's backup methods to system backups, like Duplicator does: https://github.com/flydev-fr/Duplicator/blob/69d78a13bb77cc5b541e959e864480ad41a90a82/Classes/BackupDatabase.php#L159 Right now, I am not sure about the Repeater question - no time to investigate, but it might be an easy enough fix to support selecting repeater templates.

Hey @Pete - I've added an option to remove the frontend login form. Hope that works for you. Let me know if you have any questions or suggestions!

Regarding the required field, you are not only setting a value, but the first empty option also has a value. Try it like this: array( 'name' => 'content', 'label' => 'Content type', 'description' => 'What is this content for?', 'type' => 'select', 'required' => true, 'options' => array( '' => 'Choose One', '1' => 'category1', '2' => 'category2', '3' => 'category3', '4' => 'category4', '5' => 'category5' ) ) Regarding the memory errors - I don't think that can be specifically related to this module. As for outputting more content, so you output whatever you want by assigning the html to: $this->output = 'my HTML output';

Looks good here now too - thanks Ryan

Hi @fruid - it's because of the lowercase "s" in your class name. If you change it to "class SaveOrShow" it will work as expected. You will need to re-save the module settings to clear the cache, but after that it will work.

Sorry, I am a bit confused on what you're trying to do. For the admin the guest role won't have access at all anyway. But if you don't actually need that and you're only looking to get it to work for a superuser, then I am not sure what issue you are still having. Is it the error you noted about not having permission, or is it the out of memory error, or something else? If it's the out of memory error, then that isn't related to this module, but rather then code in your custom action. You might be able to get away with a ini_set('memory_limit', '-1'), or you might need to build in a way to do the action in batches. It's impossible to know without seeing what your action code is doing.

Those permissions only allow access to see the Setup > Admin Actions menu. In the other thread I mentioned that you need to give roles access to each specific action. I am still not clear if you have done that or not. I am referring to the interface below in the module's settings. Can you confirm you have given access to your custom action?

Hi @fruid - you need to assign roles to the action within the module settings interface.

Hi @ryan - all sounds very cool! I just upgraded by local sandbox install and now I am seeing: Error: Call to a member function isDefault() on bool in /wire/core/PagesLoaderCache.php:311 It seems to be coming from the $page->get('process=236') call, but you should see it if you have Tracy running with any of these panels open: Let me know if you have any troubles reproducing.

Thanks - I wasn't thinking about that Login option - yes, I think it is handy - much nicer that the core login dance :) Yeah, I suppose we could go with 41 or the first available superuser, but if I implement this, I think it would be better to use the user switcher and have the option to choose. Regarding having access to everything on the bar already - that's not quite true - I do also prevent access to Adminer in this situation. Whether I really have good justification for that or not is another question, but I do want to have a more thorough think through this moving forward to make sure I am not overlooking anything of concern.

Hi @bernhard - I don't know about a "Login as superuser" because you may have more than one superuser so how would you know which one to log in as. One possibility would be to allow the user switcher panel to always show for local dev and you could select the user from there, but I need to think about this a bit more because it would allow logging in as a superuser without having initially started a user switching setting as a superuser. I know it's local dev only and all, but it still makes me nervous. I have modified the user switching to work like the language switching - not double-click btw, just a single click is all that is needed. I'll commit this later. Not really sure what you mean here - which login button are you talking about?

Sorry, seems like I need to make the ajax call to saveUserActivity() myself. That seems to be working and updating status as expected. Now it's really just a matter of triggering that UserActivity popup alert instead of the PW warning. And of course have it triggered when an ajax triggered saveUserActivity() call is made from the frontend.

Hi @ryan, That is kinda what I tried already. From my testing, the first part of that code doesn't actually trigger the ajax updates. Of course the initial loading of the front end profile is logged by UserActivity by default anyway, so I don't need that for initial testing of the alert in the admin, but without it, it's not actually useful in the real world. Any ideas why the ajax wouldn't be working? The second part works as a notifier, but to be useful I think it really needs to trigger the same dialog that UserActivity normally displays. Unfortunately the core PW warning banner doesn't really work for this because if there is more than one alert, the rest are collapsed and editors aren't going to expand it to see the "User may be editing their profile right now" message. How can we trigger the user activity alert instead? Thanks!