adrian

The admin user's email address suggests the developer is Greek. I won't share here, but if you're curious....

@SamC - please see ryan's response: https://github.com/processwire/processwire-issues/issues/96#issuecomment-264145798 Perhaps reply there if you want to discuss with him further.

Well you should get to work on one then Send me a PR with a new action and I can work on the ajax response to suit your needs and we'll take it from there!

SeaVuel | Hotel CMS / template : http://seavuel.com/ | http://demo.seavuel.com/ Whose handiwork is this? It looks ryan-esque to me

Ok, this functionality is ready, although please test carefully at this stage. You can populate the option parameters via URL parameters. You should split multiple values with a "|" character. There are two options: 1) You can either just pre-populate the options values, but still showing the options page where you can make changes via the options form GUI: http://mysite.dev/processwire/setup/admin-actions/options?action=TemplateFieldsBatcher&templates=29|56&fields=219&addOrRemove=add 2) or you can execute immediately with the passed options values: 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 segment before the parameters. Please try it out and let me know what you think. Do you think it might also be nice to have an option to redirect to another page after it has executed, rather than showing the results page? With your suggestion of linking from other places in the admin are you thinking about maybe an ajax call to an action, rather than loading the page? I haven't tested this yet, but it might be a nice option. I might even be able to return a JSON formatted response if called via ajax?

You can manually install it, like any other module - just copy the file into your site/modules/ directory, do a modules refresh and click install. You might want to check out @mr-fan' s version in that thread I linked to as I think he extended it to also work with file fields (not just image fields), which you will want for audio clips.

Looks like your field is returning an array of author options, so try: <?php echo $page->author->first()->fullname ?> You can also use: last(), or eq(n) The other approach is to foreach through each author: foreach($page->author as $author) { echo '<p>'.$author->firstname.'</p>; }

Ok, the optional author links are now available. These are the current options: protected $authorLinks = array( 'pwforum' => '985-adrian', 'pwdirectory' => 'adrian-jones', 'github' => 'adrianbj', );

Let me think about this a little more - even in a dev environment restoring to a really old backup could be disastrous if you're still developing the site. I guess that's the responsibility of the dev to be smart about things though. I like it - I think giving authors proper credit will hopefully promote more contributions. I have gone with PW developer directory link, PW forum profile, and also Github account, with linked icons. I could maybe provide the option for the author to fully customize their links, but don't want things getting too ugly. Any thoughts?

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.