adrian

Take a look at this gist: https://gist.github.com/adrianbj/437e3945e9d774f5a67e Also, this thread: You may also want to consider these modules: http://modules.processwire.com/modules/media-library/ https://processwireshop.pw/plugins/media-manager/

Glad you like it Definitely part of my goal! And yes, I agree with you and @tpr - a subfolder is the way to go. Are you talking about this module: http://modules.processwire.com/modules/process-database-backups/ - what if users don't have it installed? At the moment it only stores the one version of the backup - it gets overwritten every time you run a new action. It would be no problem to store more backups, but I was worried that it might be tempting to restore an old backup which could take you back too far and you might lose some manually adjusted content etc. The idea of the automatic backup was to provide a quick recovery from an action that didn't do what you expected. I am definitely happy to revisit this though, so please everyone give me your ideas on this.

I like the idea - are you thinking that if all required options are passed it would be possible to run directly with no intermediate "Execute Action" button? Perhaps an additional url parameter: ?execute=true - without this, all options would be prefilled, but the user would still have the option to modify if needed before executing. Any thoughts? Yeah, I did think about it, but I think you're right, it is probably a good idea. I think you are being genuine and not sarcastic, but just wanted to clarify. I am actually wondering if maybe I should convert the config settings page to a DataTables layout (like how it is on the main module process page) - not sure how simple that would be to implement at this point, but might be nice if this starts to fill out with a lot of actions. Btw, in case you guys didn't realize, you can actually remove the superuser role from any actions you know you won't ever use so that you have a shorter list to choose/filter from when using the module.

Just to add to your testing, I can confirm that I have been using this awesome module with 3.x for probably 6 months now without any problems!

I wanted to store multidimensional data in the config settings of my new AdminActions module and I ended up taking the approach of hooking before saveModuleConfigData so that I could change the content of $event->arguments(1), which is the data array, before it is saved. https://github.com/adrianbj/ProcessAdminActions/blob/b3a82c308377f03c86ae4a2b8fc78e4cdc73b94e/ProcessAdminActions.module#L383-L390 I am not sure if that helps you or not, but thought I'd post just in case. PS - I feel like PW could benefit from a more standard way of storing multidimensional config data.

This functionality is now available as an action in my new Admin Actions module:

@netcarver and others, just wanted to let you know that the functionality of this module is now available as an action in my new Admin Actions module:

This functionality is now available via the "Delete Unused Fields" action in my new Admin Actions module:

Hi everyone, Here's a new module that I have been meaning to build for a long time. http://modules.processwire.com/modules/process-admin-actions/ https://github.com/adrianbj/ProcessAdminActions What does it do? Do you have a bunch of admin snippets laying around, or do you recreate from them from scratch every time you need them, or do you try to find where you saw them in the forums, or on the ProcessWire Recipes site? Admin Actions lets you quickly create actions in the admin that you can use over and over and even make available to your site editors (permissions for each action are assigned to roles separately so you have full control over who has access to which actions). Included Actions It comes bundled with several actions and I will be adding more over time (and hopefully I'll get some PRs from you guys too). You can browse and sort and if you have @tpr's Admin on Steroid's datatables filter feature, you can even filter based on the content of all columns. The headliner action included with the module is: PageTable To RepeaterMatrix which fully converts an existing (and populated) PageTable field to either a Repeater or RepeaterMatrix field. This is a huge timesaver if you have an existing site that makes heavy use of PageTable fields and you would like to give the clients the improved interface of RepeaterMatrix. Copy Content To Other Field This action copies the content from one field to another field on all pages that use the selected template. Copy Field Content To Other Page Copies the content from a field on one page to the same field on another page. Copy Repeater Items To Other Page Add the items from a Repeater field on one page to the same field on another page. Copy Table Field Rows To Other Page Add the rows from a Table field on one page to the same field on another page. Create Users Batcher Allows you to batch create users. This module requires the Email New User module and it should be configured to generate a password automatically. Delete Unused Fields Deletes fields that are not used by any templates. Delete Unused Templates Deletes templates that are not used by any pages. Email Batcher Lets you email multiple addresses at once. Field Set Or Search And Replace Set field values, or search and replace text in field values from a filtered selection of pages and fields. FTP Files to Page Add files/images from a folder to a selected page. Page Active Languages Batcher Lets you enable or disable active status of multiple languages on multiple pages at once. Page Manipulator Uses an InputfieldSelector to query pages and then allows batch actions on the matched pages. Page Table To Repeater Matrix Fully converts an existing (and populated) PageTable field to either a Repeater or RepeaterMatrix field. Template Fields Batcher Lets you add or remove multiple fields from multiple templates at once. Template Roles Batcher Lets you add or remove access permissions, for multiple roles and multiple templates at once. User Roles Permissions Batcher Lets you add or remove permissions for multiple roles, or roles for multiple users at once. Creating a New Action If you create a new action that you think others would find useful, please add it to the actions subfolder of this module and submit a PR. If you think it is only useful for you, place it in /site/templates/AdminActions/ so that it doesn't get lost on module updates. A new action file can be as simple as this: <?php namespace ProcessWire; class UnpublishAboutPage extends ProcessAdminActions { protected function executeAction() { $p = $this->pages->get('/about/'); $p->addStatus(Page::statusUnpublished); $p->save(); return true; } } Each action: class must extend "ProcessAdminActions" and the filename must match the class name and end in ".action.php" like: UnpublishAboutPage.action.php the action method must be: executeAction() As you can see there are only a few lines needed to wrap the actual API call, so it's really worth the small extra effort to make an action. Obviously that example action is not very useful. Here is another more useful one that is included with the module. It includes $description, $notes, and $author variables which are used in the module table selector interface. It also makes use of the defineOptions() method which builds the input fields used to gather the required options before running the action. <?php namespace ProcessWire; class DeleteUnusedFields extends ProcessAdminActions { protected $description = 'Deletes fields that are not used by any templates.'; protected $notes = 'Shows a list of unused fields with checkboxes to select those to delete.'; protected $author = 'Adrian Jones'; protected $authorLinks = array( 'pwforum' => '985-adrian', 'pwdirectory' => 'adrian-jones', 'github' => 'adrianbj', ); protected function defineOptions() { $fieldOptions = array(); foreach($this->fields as $field) { if ($field->flags & Field::flagSystem || $field->flags & Field::flagPermanent) continue; if(count($field->getFieldgroups()) === 0) $fieldOptions[$field->id] = $field->label ? $field->label . ' (' . $field->name . ')' : $field->name; } return array( array( 'name' => 'fields', 'label' => 'Fields', 'description' => 'Select the fields you want to delete', 'notes' => 'Note that all fields listed are not used by any templates and should therefore be safe to delete', 'type' => 'checkboxes', 'options' => $fieldOptions, 'required' => true ) ); } protected function executeAction($options) { $count = 0; foreach($options['fields'] as $field) { $f = $this->fields->get($field); $this->fields->delete($f); $count++; } $this->successMessage = $count . ' field' . _n('', 's', $count) . ' ' . _n('was', 'were', $count) . ' successfully deleted'; return true; } } This defineOptions() method builds input fields that look like this: Finally we use $options array in the executeAction() method to get the values entered into those options fields to run the API script to remove the checked fields. There is one additional method that I didn't outline called: checkRequirements() - you can see it in action in the PageTableToRepeaterMatrix action. You can use this to prevent the action from running if certain requirements are not met. At the end of the executeAction() method you can populate $this->successMessage, or $this->failureMessage which will be returned after the action has finished. Populating options via URL parameters You can also populate the option parameters via URL parameters. You should split multiple values with a “|” character. You can either just pre-populate options: http://mysite.dev/processwire/setup/admin-actions/options?action=TemplateFieldsBatcher&templates=29|56&fields=219&addOrRemove=add or you can execute immediately: http://mysite.dev/processwire/setup/admin-actions/execute?action=TemplateFieldsBatcher&templates=29|56&fields=219&addOrRemove=add Note the “options” vs “execute” as the last path before the parameters. Automatic Backup / Restore Before any action is executed, a full database backup is automatically made. You have a few options to run a restore if needed: Follow the Restore link that is presented after an action completes Use the "Restore" submenu: Setup > Admin Actions > Restore Move the restoredb.php file from the /site/assets/cache/AdminActions/ folder to the root of your site and load in the browser Manually restore using the AdminActionsBackup.sql file in the /site/assets/cache/AdminActions/ folder I think all these features make it very easy to create custom admin data manipulation methods that can be shared with others and executed using a simple interface without needing to build a full Process Module custom interface from scratch. I also hope it will reduce the barriers for new ProcessWire users to create custom admin functionality. Please let me know what you think, especially if you have ideas for improving the interface, or the way actions are defined.

Likely a PHP version difference. Try replacing: $this->page with: wire('page')

In case it helps, here is the current generated source of one page in the list: <div class="PageListItem PageListTemplate_course PageListID1018"><a href="#" title="/rock-climbing/basic-rock/" class="PageListPage label"><span data-pid="1018" class="label_title">Basic Rock</span></a><span class="PageListNumChildren detail"></span><ul class="PageListActions actions"><li class="PageListActionEdit"><a href="/admin/page/edit/?id=1018" class="pw-modal pw-modal-large pw-modal-longclick" data-buttons="#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button">Edit</a></li><li class="PageListActionView"><a href="http://sradev.skaharockclimbing.com/rock-climbing/basic-rock/" class="pw-modal pw-modal-large pw-modal-longclick">View</a></li><li class="PageListActionMove"><a href="#">Move</a></li><li class="PageListActionEdit"><a href="http://sradev.skaharockclimbing.com/admin/setup/template/edit?id=44" class="pw-modal pw-modal-large pw-modal-longclick" data-buttons="#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button">course</a></li><li class="PageListActionExtras ui-priority-secondary"><a href="#" class="clickExtras"><i class="fa fa-angle-right"></i></a></li></ul></div> Any chance it comes back to that span issue that was affecting the page ID being shown? Probably not - thinking a quick guess

@tpr is referring this option in the AOS config settings which lets you load additional CSS rules to the PW admin.

Hi @SamC - are you talking about a plain textarea field, rather than a text field? See my Github issue here: https://github.com/processwire/processwire-issues/issues/96 If there is something else I am missing, please feel free to comment on that issue.

Maybe I don't fully understand what you are actually trying to achieve. Can you show us the output you are getting and what you instead want to get?

For the title field you need: ProcessPageEdit::buildForm And remember (as I mentioned above) - no need for a module - just use my version in your site/init.php file.

This works for me: $pages->addHookAfter("ProcessPageEdit::buildFormContent", function($event) { if($event->object->getPage()->id !== 1016) return; $wrapper = $event->return; if(!$wrapper->has('body')) return; $wrapper->body->collapsed = Inputfield::collapsedHidden; }); I have included a check for the ID of the page being edited. So in this case it will only hide the "body" field on a page with ID 1016. Hopefully you can modify that for your needs. BTW, I just put that code in my site/init.php file - no need for a module for something so simple.

There is also: https://github.com/ryancramerdesign/ServicePages Also read from here (https://processwire.com/talk/topic/1654-pages-web-service-servicepages/?do=findComment&comment=132839) onwards to get it working with PW 3.x

Glad you like it Perhaps you'd consider adding your support to my feature request: https://github.com/processwire/processwire-requests/issues/54 As far as I can tell there is no way for me to control which languages are displayed at the moment. If Ryan can come up with a core solution that lets me hook and change the results returned by $languages then I think I will be able to incorporate your request into this module. My goal is to have a checkboxes field added to the page edit Settings tab that lets you determine which languages are enabled for the page/branch.

If you look at Example #2 : https://processwire.com/api/modules/markup-pager-nav/ you can see how to output pagination links exactly how you want.

Hi everyone, @Christophe was kind enough to notice that I had mis-spelled "Language" throughout the module, including the name of the repo on Github and the class name. I think I have everything updated correctly now, so if anyone has already installed it, you will unfortunately need to install again. Sorry about that!

Check out the new module for this functionality:

Hi everyone, Here's a new module that lets you control whether multi-language support is enabled at the page / branch level, rather than only per template. http://modules.processwire.com/modules/restrict-multi-language-branch/ https://github.com/adrianbj/RestrictMultiLanguageBranch This is ideal for a site with repeated branches using the same templates where only some need to be multi-language. I think it is confusing to provide multiple language inputs for fields when they are not required - it just bloats the admin interface for site editors. I am hoping to expand this module to allow selection of which languages are supported per page/branch, but I am waiting on @ryan's response to this request: https://github.com/processwire/processwire-requests/issues/54 - to me this would be even more powerful if you have a situation where certain branches need some languages and other branches need different languages. The module config settings shows a summary of the restrictions you have implemented, eg: This shows that we have started with the home page which disables multi-language on itself and all its children/grandchildren (because "This Page Only" is "False". Next we have the /report-cards/ page multi-language enabled, but no inheritance (because "This Page Only" is "True"). The only branch below this to have multi-language enabled is Guanabara Bay and all it's children etc will also be enabled. All other report card branches will be disabled because they will inherit directly from the config settings default status. The Settings tab for each page gives you three options: Inherit, Enabled, Disabled. The screenshots give you an idea of how the Inherit option works and the information it provides based on the status it is inheriting and from where. My goal for this site was to just enable multi-language support for the Guanabara Bay report card branch of the tree, as well as the home page and the /report-cards/ parent. All other branches have multi-language support disabled which makes content entry much cleaner. Hope you guys find a good use for it and I'll be sure to update with the ability to define which languages are available on which pages/branches if Ryan comes up with a core solution for changing the returned $languages. Please let me know if you have any problems / suggestions.

That doesn't seem to work for me - tested on default and reno. Also, please note that I expanded on the icons issues with the default theme in my last post - the "Always show page list actions" doesn't work for the parent of expanded branches on Default Admin Theme - works fine with Reno.

Thanks @tpr - unfortunately that still doesn't fix the Page IDs issue for me. Here's the generated source of one of this pages in the list. As you can see there is no <span> to start with, which is why that version I posted (https://processwire.com/talk/topic/13389-adminonsteroids/?do=findComment&comment=133085) adds the span. Maybe it's not the best approach, but unfortunately it doesn't work as is. <div class="PageListItem PageListTemplate_course PageListID1016 trashable"><a href="#" title="/rock-climbing/introduction-to-rock-climbing-rappelling/" class="PageListPage label">Introduction to Rock Climbing & Rappelling</a><span class="PageListNumChildren detail"></span><ul class="PageListActions actions"><li class="PageListActionEdit"><a href="/admin/page/edit/?id=1016" class="pw-modal pw-modal-large pw-modal-longclick" data-buttons="#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button">Edit</a></li><li class="PageListActionView"><a href="http://sradev.skaharockclimbing.com/rock-climbing/introduction-to-rock-climbing-rappelling/" class="pw-modal pw-modal-large pw-modal-longclick">View</a></li><li class="PageListActionMove"><a href="#">Move</a></li><li class="PageListActionEdit"><a href="http://sradev.skaharockclimbing.com/admin/setup/template/edit?id=44" class="pw-modal pw-modal-large pw-modal-longclick" data-buttons="#ProcessPageEdit > .Inputfields > .InputfieldSubmit .ui-button">course</a></li><li class="PageListActionExtras ui-priority-secondary"><a href="#" class="clickExtras"><i class="fa fa-angle-right fa-flip-horizontal"></i></a></li><li class="PageListActionExtra PageListActionUnpublish"><a class="PageListActionExtra PageListActionUnpublish" href="/admin/page/?action=unpub&id=1016" style="display: inline-block;">Unpub</a></li><li class="PageListActionExtra PageListActionHide"><a class="PageListActionExtra PageListActionHide" href="/admin/page/?action=hide&id=1016" style="display: inline-block;">Hide</a></li><li class="PageListActionExtra PageListActionLock"><a class="PageListActionExtra PageListActionLock" href="/admin/page/?action=lock&id=1016" style="display: inline-block;">Lock</a></li><li class="PageListActionExtra PageListActionDelete aos"><a class="PageListActionExtra PageListActionDelete aos" href="/admin/page/?action=delete&id=1016" style="display: inline-block;">Delete</a></li><li class="PageListActionExtra PageListActionTrash"><a class="PageListActionExtra PageListActionTrash" href="/admin/page/?action=trash&id=1016" style="display: inline-block;"><i class="fa fa-trash-o"></i> Trash</a></li></ul></div> One small request with the new icon page list actions - can we get title attributes so users can figure out what they are until they get used to them? Also, the "Always show page list actions" doesn't work for the parent of expanded branches (only tested on Default Admin Theme). Thanks heaps!

Firstly, try this module instead: http://modules.processwire.com/modules/markup-rssenhanced/ Secondly, don't edit lines in the module, try passing the options array to the render method so that updates to the module won't break the functionality.