Leaderboard

PR done! Feel free to review. It doesn't check whether the items are checked or not, just toggles items on/off.

A little self promotion here BatchChildEditor gives you an alternate interface that allows for very quick deletion of multiple pages. It may or may not suit your needs. Those delete buttons are toggles that mark the page for deletion, but the user still has to click Save to process the deletions, so this makes it pretty good at preventing accidental deletions.

This module facilitates quick batch creation (titles only or CSV import for other fields), editing, sorting, deletion, and CSV export of all children under a given page. You can even provide an alternate parent page which allows for editing of an external page tree. http://modules.processwire.com/modules/batch-child-editor/ https://github.com/adrianbj/BatchChildEditor The interface can be added to the Children Tab, or in a new dedicated tab, or placed inline with other fields in the Content tab. Various modes allow you to: Lister - Embeds a customized Lister interface. Installation of ListerPro will allow inline ajax editing of displayed fields. Edit - This allows you to rename existing child pages and add new child pages. It is non-destructive and so could be used on child pages that have their own children or other content fields (not just title). It includes the ability to quickly sort and delete pages and change page templates. Also allows full editing of each page via a modal dialog by clicking on the page name link. This is my preferred default setup - see how it replaces the default Children/Subpages with an easily addable/editable/sortable/renamable/deletable list. Note that the edit links open each child page in a modal for quick editing of all fields. Add - adds newly entered page titles as child pages to the list of existing siblings. You could create a list of pages in Word or whatever and just paste them in here and viola! This screenshot shows the editor in its own tab (name is configurable) and shows some of the CSV creation options. Update and Replace modes look fairly similar but show existing page titles. Update - Updates the titles (and any other fields if you enter CSV data) for the existing pages and adds any additionally entered pages. Replace - Works similarly to Add, but replaces all the existing children. There are checks that prevent this method working if there are any child pages with their own children or other content fields that are not empty. This check can be disabled in the module config settings, but please be very careful with this. Export to CSV - Generates a CSV file containing the fields for all child pages. Fields to be exported can to fixed or customizable by the user. Also includes an API export method. Populating fields on new pages In Add, Update, and Replace modes you can enter CSV formatted rows to populate all text/numeric fields, making for an extremely quick way of creating new pages and populating their content fields. Predefined Field Pairings Like the field connections setup from Ryan's CSV Importer, but defined ahead of time so the dev controls what columns from the CSV pair with which PW fields. This is especially powerful in Update mode giving editors the ability to periodically import a CSV file to update only certain fields on a entire set of child pages. These pairings also allow for importing fieldtypes with subfields - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. Access permission This module requires a new permission: "batch-child-editor". This permission is created automatically on install and is added to the superuser role, but it is up to the developer to add the permission to other roles as required. Config Settings This module is HIGHLY configurable down to setting up custom descriptions and notes for your editors. You define one config globally for the site and then optionally you can define completely custom configurations for each page tree parent on your site. There are too many settings to bother showing here - you really just need to look through all the options and play around with them!

I just wanted to share a small module I just made, that can inherit values from pages, that are higher up in the page tree. This inheritance will only show for formatted output, so for example in listers or in the frontend. When using the unformatted value one will see, if a field is really set or not. <?php class FieldtypeInheritInteger extends FieldtypeInteger { public static function getModuleInfo() { return array( 'title' => 'Inherit Integer', 'version' => 101, 'summary' => 'If empty tries to get values of the same field from further above the pagetree. This does only work for formatted values so empty values won\'t ne overwritten by editing a page.' ); } public function ___formatValue(Page $page, Field $field, $value) { if(!$this->isEmptyValue($field, $value)) return $value; $parent = $page->parent("$field!=''"); if($parent->id) return $parent->getFormatted($field); else return $value; } public function ___markupValue(Page $page, Field $field, $value = null, $property = '') { return $this->___formatValue($page, $field, $value); } }

Hi wishbone, Yes, you are correct that css doesn't limit the number of items per row, but it will allow you to display however many items that will fit on each row depending upon the width of the display, if that is your intent. As far as the programming is concerned, php uses either the keyword OR or the characters || (two pipe characters) to designate this type of comparison. I personally prefer the keyword simply because it is easier for me to read, and becomes more readily apparent when there is a misspelling. And here is what your conditional statement says: If the number of boxes is less than 3 OR the number of boxes is greater than 3 then ... render the box content. ... else if the number of boxes does equal 3 then ... start an new line. Three issues with this structure: Going back to css, the DIV elements you use as a container are by default block-level elements, which means each DIV will be rendered on a new line, unless you change that behavior through css. If you want to bypass css, then I would recommend you render your content within a table. The count function returns the total number of items -- it will not change within your for-each loop. You will need to set a counter and increment that counter at each iteration in order to obtain the desired value. Since you are only concerned about the count equal to 3, you could rewrite your conditional statement like so: $box_count = 0; for each $boxes as $box { if ( $box_count == 3 ) { // start a new line $box_count = 0; } else { //render box content $box_count = $box_count + 1; } } Regarding the actual ProcessWire method of obtaining those boxes, I will leave to the more knowledgeable members.

thanks kixe and adrian! While creating the site, as a superuser I always use this module, http://modules.processwire.com/modules/process-batcher/ Congrats Adrian!! that one looks great too and makes sense for the editor role and batch delete. I haven't tried the cronjobEmptyTrash module, always try to keep the modules to a minimum but I will certainly have a look at that one too. thanks!

Hi guys, This is a bug. It should work if you add $this->initPDF() before this line: https://github.com/wanze/Pages2Pdf/blob/master/WirePDF.module#L91 I will fix it and update the module. Cheers

So I've updated mine - these are essential to my current projects: TemplateDataProviders TemplateTwigReplace MarkupSitemapXML Blick VersionControl (ProDrafts looks awesome, though) And, of course, for migrations: Jumplinks

really great module! you got several new likes 3 little bugs i think: don't know if the shift-click bug is related to this module or should be reported at github? https://processwire.com/blog/posts/processwire-core-updates-2.5.24/#shift-click-with-multi-checkbox-fields (maybe interesting for you tpr)

$box is not countable, it's just a page/repeater object. Also why don't you just use css for that job? flex-wrap and flex-basis should be enough for the job and you don't need any <br>'s.

I sometimes use the code below (include doesn't loose context). <?php // Allow to cache to a variable function getPartial($path_to_file) { ob_start(); include($path_to_file); return ob_get_clean(); } $partial = getPartial($config->urls->templates . 'partials/myfile.php');

Have you tried this? $packages = $pages->get('template=packages, currency='.$page->currency->id); Perhaps you can leave the last "->id" part too. If you are using this regularly, create a getPackages function in _func.php that accepts $page as parameter and returns the snippet I wrote above. Thus you could use getPackages($page) when you need it.

how are you getting that partial=true, i can't see how the render method takes any arguments, at least not here: http://cheatsheet.processwire.com/page/built-in-methods-reference/page-render/ perhaps you could use wireRenderFile, or wireIncludeFile

If I may interject, here is an MW skin that uses Foundation: https://www.mediawiki.org/wiki/Skin:Foreground Only v4 though.. maybe they will go straight to v6 when it hits.

Mentioned in today's weekly, thanks! (I'm glad I made some important changes a few days earlier )

I do think this is a great project, and there are many great ideas submitted by everyone. Based on my 'past-life' experience as a tech-writer, there are two approaches to this issue. One is from the target audience point of view, the other is from the product capability point of view. Since there are numerous entries in this topic where "I do it this way..." and "I do it that way...", let's set aside the point of view of the end user, and concentrate on the functionality. To do that, each entry should have at least the following things defined: The description of what the function does, The proper syntax for its use, The parameters defined, The return values defined, A simple example of each combination, And a link to the source code. I hate to admit it, but I really like the completeness of wordpress docs... https://codex.wordpress.org/Function_Reference/add_action It makes is very easy for any skill level to quickly obtain the necessary information to move forward. I also think it would be advantageous to use ProcessWire to present this information. Eating our own dogfood, kind of thing. I would like to participate on this team too, if I may.

Zero setup page rendering with caching, with simple replacements. Useful if you have complicated templates (or a large number of less complicated ones), where you often need to do a small number of adjustments. In this case, caching on the template level doesn't completely make sense — because it either uses cache, or doesn't. This module solves this problem by using markup cache all the time, but allowing us to modify the output by replacement of simple strings. - On GitHub - On modules.processwire.com Edit: Also, small thanks to Tom Reno for testing what single language install return for $user->language

Ok, just pushed a new version to dev that adds support for choosing an alternate Parent. This allows you to bring in child pages from any other parent in the page tree (like I mentioned in my previous post above). It's a new option under the Content / Deletion / Protection tab - obviously only available for page specific config settings. Also added an option to determine whether Filters/Columns/Actions are available in Lister mode - checkbox under the Lister mode settings tab. This version might require a little extra testing regarding allowed templates for editing/adding pages. Please let me know how it goes.

Sorry for the stream of updates, but you can now embed BCE into the flow of fields within the Content Tab. This makes for even easier access to inline ajax editing of child pages. It probably only makes sense for Lister, Edit, and Export modes. Just pushed this option to the dev branch.

Thanks @mr-fan! I just put together another screenshot showing how you can use BCE as the equivalent of an inline PageTable field interface. Obviously these are just child pages and are not callable from a field, but it provides an excellent editing interface in a dedicated tab along with all the filtering options of lister. It also doesn't have any of the problems with a PageTable field regarding editing the content page directly and not having new pages automatically added, etc. The inline ajax editing is also a great bonus over the popup modal editing. Of course, this inline editing requires ListerPro, but I think it is worth it

Just added some new features and a couple of bug fixes to the dev branch. Fixes for export mode with certain complex field types Added support for AJAX loading of BCE - especially useful if you are using the "New Tab" position option - requires PW 2.6.11+. This will make Page -> Edit load much quicker when you have lots of child pages. New Lister mode - this allows you to view (and configure the default columns/filters) all children under the current page. If you have ListerPro installed you can also use the Actions on the children. This also supports inline editing which makes for a very quick and easy way to edit the key fields on each child page. Please let me know how the new AJAX load and Lister mode features work for you - I think I need some wider testing before pushing this to the master branch. You can define the Lister config settings sitewide, and then provide overrides for each parent page that has been enabled under "Configurable Pages" This screenshot shows the new Lister mode configured to show a predefined set of columns - a great way to preview the page content of child pages. This shows the Lister Inline Edit mode - making for very quick editing of key fields in child pages.

I'm not sure how deep this issue goes, but fixing the pagination module issue can be quite easy. $pa = new PageArray(); $pa->setTotal($total)->setLimit($limit)->setStart($start); $pager = $this->modules->get('MarkupPagerNav'); $pager->baseUrl = $baseUrl; $pager->render($pa);

Thanks SiNNuT - I really appreciate you letting me know that you're finding it so useful.! I hope you'll also like the next little enhancement Edit mode now has hidden and unpublished checkboxes:

Sorry for all the quick updates, but am using this to populate a huge site and finding new needs so implementing as I go. You can now change the template of each child page in the Edit mode. Because this change happens without warnings, it is controlled by the new "Allow template changes" setting in the module config. Of course the ability to change templates is also additionally controlled by the user's "page-template" permission. Note - you might potentially only want to enable "Allow template changes" while your site is in development and disable once it is live to avoid any disasters. TIP: If you want to change the template for all child pages at once and there are lots of pages, this could still be a little tedious. So instead, use the "Replace" mode, choose the "Child Template" at the top and click Save. This will delete and recreate all child pages with the selected template. This is super fast if the pages don't have any content yet (or child pages of their own), which can often be the case early in development when you are still figuring out which pages will have which templates!

Another major new feature! I have added an Export to CSV mode which generates a CSV file containing the fields for all child pages. It currently supports most field types, including: Text/Textarea/Integer/Date fields Page fields - exports the "Title" if available, or "Name" if not (eg user template), rather than just the page ID File/Images - exports the filenames Profields Textareas - automatically converts field into multiple columns - one for each subfield Profields Multiplier - separates values with a customizable separator - you can choose a line break if you want which is nice when opening the CSV in Excel. This same customizable separator is available for other multiple fields like Page fields, File/Image etc It does not support Profields Table, PageTable or Repeaters as these would get very messy. Note if you want to provide an export for specific Table fields, don't forget to check out: Table CSV Import/Export Fields to be exported can be predefined or customized by the user. Also includes an API export method: //export as CSV if csv_export=1 is in url if($input->get->csv_export==1){ $modules->get('ProcessChildrenCsvExport'); //load helper module //delimiter, enclosure, file extension, names in first row, multiple field separator, array of field names $page->exportCsv(',', '"', 'csv', true, "\r", array('title','images','textarea_test')); //$page->exportCsv() - this version uses the defaults from the module or page specific settings } // display content of template with link to same page with appended csv_export=1 else{ include("./head.inc"); echo "<a href='./?csv_export=1'>Export Table as CSV</a>"; //link to initiate export include("./foot.inc"); } Like the rest of this module, everything is configurable at various levels, so you can include this functionality as a separate tab, or part of the Children tab. You can predefine all settings so the user only has a simple Export button - whatever works best for you. Please let me know how this new functionality works out for you and if you have any suggestions for improvements.

Ok, all new features have now been merged to the master branch. I have changed the release state from Stable to Beta for this release. Really just as a precaution for the Update mode options until I have had more feedback on this. Please let me know how this new version works out for everyone. It will probably take you a while to go through all the new configuration options, but I think it's worth the effort. You can use this module as a simple replacement for the Children/Subpages section of the Children tab (which allows for much quicker editing of child pages), all the way through to a fully customizable CSV import tool for site site editors to create and update pages. Feel free to send through any other ideas along with any issues you come across.

Another new option added to the dev branch! The old "Overwrite" edit mode is now called "Replace" and there is a new Overwrite mode that updates the content of fields of existing pages. An example use case would be to allow editors to periodically upload a CSV file to update certain fields in all child pages while leaving other fields intact. To make this happen you would utilize the Field Pairings option so their import would only edit the specified fields.

Major feature enhancements currently available on dev branch - https://github.com/adrianbj/BatchChildEditor/tree/dev The new config settings rely on the new "OR" options for inputfield dependencies, so this new version requires the dev branch of PW. Please test carefully and let me know if you have any problems or suggestions! Thanks to ideas, testing and feedback from @mr-fan this module now supports the following new features which mostly focus on enhanced, customized CSV importing for page creation: Custom configurations on a page by page basis (on the Settings tab) - you can set up a default config in the module settings, but override these for any parent page. Ability to set up custom titles, descriptions, and notes so the interface can be tailored to the exact needs of your editors with page/template specific examples. Option to have editing tools in a new tab, rather than in the Children Tab. Alternatively, you can now replace the current Children/Subpages list in the Children tab. CSV upload and link to external URL, in addition to the existing textarea manual / paste entry. Ability to predefine "field pairings". This means that editors can upload/link to CSV files that may contain more fields than you want to import, or there are fields in your template that are not included in the CSV. Think of it as a predefined version of the "Connect the Fields" functionality in Ryan's "Import Pages from CSV Files" module. This makes complex imports foolproof for non-tech site editors. I think in most cases this could now replace the need for custom scripts for editor friendly, regular CSV importing. Despite the added options, it should be just as simple to setup as before if you don't need any of the extra features. Here are some screenshots to give you an idea. Shows a very simple, restricted CSV upload setup with custom title, description, and notes fields. Note that it is in a custom labeled new tab, rather than under the Children tab. All the new parent page specific config settings. Note in particular the "Field Pairings" section where you define CSV column numbers to match PW field names. The only thing I am having some issues with is persistence of some error messages - if you have setup some options that conflict or otherwise cause a specific error to be sent, you may need to save the settings a couple of extra times to make the message go away - not sure if this is a PW bug or what at the moment, but it shouldn't affect functionality.

Another significant update which should be a huge timesaver. You can now populate all the text/numeric fields on newly created child pages (Add & Overwrite modes) from CSV formatted rows. This allows easy creation and population of all page content, for example you could populate an entire page tree of country details by pasting in CSV formatted content like: "Bolivia, Plurinational State of",BO,"BOLIVIA, PLURINATIONAL STATE OF",BOL,68 "Bonaire, Saint Eustatius and Saba",BQ,"BONAIRE, SAINT EUSTATIUS AND SABA",BES,535 etc etc Hope you guys will find this as useful as I am As always, let me know if you have any problems or suggestions for improvements!