Leaderboard

After forgetting the class name of the wonderful AdminPageFieldEditLinks module for what feels like the 100th time I decided I needed to give my failing memory a helping hand... Autocomplete Module Class Name Provides class name autocomplete suggestions for the "Add Module From Directory" and "Add Module From URL" fields at Modules > New. Requires ProcessWire >= v3.0.16. Screencast Installation Install the Autocomplete Module Class Name module. Configuration Add Module From Directory Choose the type of autocomplete suggestions list: "Module class names from directory" or "Custom list of module class names". The latter could be useful if you regularly install some modules and would prefer a shorter list of autocomplete suggestions. The list of class names in the modules directory is generated when the Autocomplete Module Class Name module is installed. It doesn't update automatically (because the retrieval of the class names is quite slow), but you can use the button underneath when you want to retrieve an updated list of class names from the directory. Add Module From URL If you want to see autocomplete suggestions for the "Add Module From URL" field then enter them in the following format: [autocomplete suggestion] > [module ZIP url] Example: RepeaterImages > https://github.com/Toutouwai/RepeaterImages/archive/master.zip Awesomplete options The "fuzzy search" option uses custom filter and item functions for Awesomplete so that the characters you type just have to exist in the autocomplete suggestion item and occur after preceding matches but do not need to be contiguous. Uncheck this option if you prefer the standard Awesomplete matching. Custom settings for Awesomplete can be entered in the "Awesomplete options" field if needed. See the Awesomplete documentation for more information. https://github.com/Toutouwai/AutocompleteModuleClassName https://modules.processwire.com/modules/autocomplete-module-class-name/

Imho, This functionality really should be in the core Gideon

Anything that can be done with the API can be turned into an executable action with @adrian's Admin Actions module. And you can make an action available to non-superusers too. There's a built-in "Copy Field Content to Other Page" action that you can use as a starting point. This action doesn't work out-of-the-box for Files or Images fields but it wouldn't be difficult to get it working, especially now that you can use Pagefiles::add() with a Pagefile object so that descriptions and tags get copied over automatically. And if you update the action maybe submit a pull request to the module repo with your changes...?

That's because ultimately the references depend on the execution of the FieldtypePage::findReferences() method. This method has to be called for each page you want to get or count the references to. And so the number of references is not a simple value in the database that you can query in a $pages->find() selector the way a field value is. Enabling selectors that query or sort by the number of references is one of the motivations behind the Connect Page Fields module. If you use this module to create a two-way relationship between Page Reference fields then it's easy to write the selector you want. Note that you can set the visibility of a Page Reference field to hidden if you don't need to see it in Page Edit but only want to query it in selectors.

If using InnoDB, use transactions to batch the page creation and deletion. With Batch Child Editor and transactions, I am able to create 35,5k pages (with over a dozen fields) in 2min 44s on my local machine. So much faster than Bernhard's result.

This seems like a really nice ux update. I really like you improving existing functionality. Thanks!

TemplateFile::render does seem to be a good place to tweak the markup right before it goes into the MarkupRegions class. Is that one not working? Here is where the template is rendered: https://github.com/processwire/processwire/blob/master/wire/modules/PageRender.module#L514 Here is where the markup regions are populated: https://github.com/processwire/processwire/blob/master/wire/modules/PageRender.module#L524

I just want to share my findings from today when I wanted to create one million pages quickly: First, via Tracy Console: ini_set('max_execution_time', 150); $last = $pages->findOne("parent=/data,include=all,sort=-id"); $last = (int)$last->title ?: 0; for($i=$last+1;$i<$last+1000;$i++) { // create page $p = new Page(); $p->template = 'basic-page'; $p->parent = '/data'; $p->title = $i; $p->save(); l("saved page $i"); $pages->uncacheAll(); gc_collect_cycles(); } d('done'); It started at 23 pages per second: And at the end of the 150 seconds it was already down at 4 pages per second: Testing without logging: Memory usage also increased proportionally. Finally running a PHP script from the command line that bootstrapped PW worked well: <?php namespace ProcessWire; $time_pre = microtime(true); include("../../../index.php"); // bootstrap ProcessWire $last = $pages->findOne("parent=/data,sort=-id"); $i = (int)(string)$last->title ?: 0; // multilang quickfix convert to string // foreach($pages->find('parent=/data') as $p) { // $p->delete(); // echo "deleted $p\n"; // } // return; $i++; $num = 0; while($i <= 1000000) { // create page $p = new Page(); $p->template = 'basic-page'; $p->parent = '/data'; $p->title = $i; $p->save(); $pages->uncacheAll(); gc_collect_cycles(); $num++; echo "done: $num ($i)\n"; $i++; } function convert($size) { $unit=array('b','kb','mb','gb','tb','pb'); return @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i]; } $time_post = microtime(true); $t = $time_post - $time_pre; $m = memory_get_usage(); echo "created $num pages in " . round($t, 3) . "s, " . round($t/$num, 3) . "s per page, used " . convert($m) . " memory\n"; Benefits: quick runs in the background and does not lock the site direct feedback via echo without creating huge log files cancel via ctrl+c any time easy persistant saving of your scripts

Just to expand on this, having seperate methods for getting and setting are preferable because you can use typehints to declare argument and return types. This way, your methods become more robust (invalid arguments produce errors instead of propagating through your application and causing errors elsewhere), and your IDE / code editor can use them to provide better hints while using the methods. If you have just one method for both, you can't use a return typehints, because the function might return a string or an object. To expand on your two methods: public function setText(string $value): self { $this->text = trim($value); return $this; } public function getText(): string { return $this->text; } I'm looking forward to PHP 7.4 which will have typed class properties. Then we'll be able to get rid of the getText method altogether: public string $text; public function setText(string $value): self { $this->text = trim($value); return $this; }

A recent answer to a similar question:

This week I've been working on core 3.0.134 but am going to keep the version number at 3.0.133 for another week while I continue with updates there. Commit log. One of the updates already present that I'm finding quite useful is a nice upgrade to InputfieldSelector (like used by Lister and ListerPro) which simplifies the field selection process as there are no longer separate "Field" and "Field…" selections for fields that have subfields, and they are now bundled into one. This reduces the number of selectable fields and likewise speeds up the selecting/filtering process. I'll have more details on that next week, along with other updates. I'm going to be working remotely next week (not vacation) and do not yet know what the internet situation is going to be yet, so on the chance that I don't have good internet access, I may not have an update next week, but hopefully will. Have a great weekend!

Hi Robin + Adrian, thank you, will have a look and if I come up with something, will PR. cheers, Tom

As @Robin S mentioned, I'd be happy to accept a PR for this enhancement!

There has been a small update on this module thanks to @Jonathan Lahijani. @Jonathan Lahijani added: PHP files can have a comment called "Description" at the top of the file which will be displayed in the dropdown if it exists. Check this option to disable it.

I'll have a think. We'd want to preserve backward compatibility. In respect of the seat mapping, yes. However, you would need to do the frontend logic yourself, i.e. the JavaScript bit of a user making selections. However, using a module for something 'as simple' as that may be an overkill?

Recently I have been trying to improve the user friendliness of various page select fields, including single select and checkboxes. The issue comes down to the fact that if say for example you have a single checkbox, you can explain what the effect of checking that box is. But if you are using checkboxes on a page select field, there is no way to have any extended information about the option. An example of where something like this is already in use is on the Status field - each option has the title of the option, e.g. Unpublished, and then additional info, like "Not visible on site". Currently my solution is to use a custom inputfield that extends the primary inputfield, which extends the attributes for each option, and then use javascript for handling the display. On checkboxes, adding uk-tooltip to the checkbox labels with the data-description on the option becoming the tooltip content. (see screenshot below) On single selects, i have some JS replace the field description with the info about the selected option. (see screenshot). The reason i'm posting this here is to see if there is any simpler/better way to do this, e.g. hook into the creation of the options for any page field and add the custom attributes, without having to change the inputfield type. And i thought this could be a good candidate for AOS. To better illustrate how it works, i have included some screenshots and links to the repos for the select extended and checkboxes extended. Select Extended: nothing selected Option selected, with option's description showing: https://github.com/outflux3/InputfieldSelectExtended ----- Checkboxes Extended hovering over any option shows the option's description: https://github.com/outflux3/InputfieldCheckboxesExtended

$page->references() is a great addition - I can immediately see it being use for tagging systems. I would like to now if it is, or maybe will eventually be, possible to use 'references' within a selector. For example: // Find all the tags and sort them by the number of references to each tag. // When looping through the results, the tags are in order of the most references (ie, most used tags) first. $all_tags = $pages->find('template=tag, sort=-references.count');

Kind of pointing out the obvious here, but that could be asking for trouble. A number of modules (including core ones, such as Repeaters) perform cleanup etc. with hooks. Unless you're really careful, you could easily leave a ton of orphaned data behind with this method.

You can use wireshell as well. This is really handy. Just give the following command and grab a coffee wireshell page:emptytrash I'm not really sure if it will delete everything in one run, but I deleted 60k pages the other day without problems. Really fast too and the main advantage is that you are not tied to a PHP session.