Leaderboard

ProcessWire’s API is accessible through API variables and it provides multiple ways to access them. There are benefits and drawbacks to each approach and this post aims to cover them all. We also look at how to add your own API variables as well. https://processwire.com/blog/posts/api-variable-best-practices/

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

This is an inputfield module I made as a replacement for InputfieldPageListSelect, due to frustration with it not opening the page structure to the currently selected page. Please note the requirement of ProcessWire >= v3.0.248 when using it as an inputfield for a Page Reference field due to this now fixed core issue. The module doesn't make the PW version a strict requirement in case you just want to replace instances of InputfieldPageListSelect via the bundled ReplacePageListSelect module. Page Tree Select An inputfield for selecting a single page from the page tree. This inputfield is similar to the core InputfieldPageListSelect, but it has the following advantages: It automatically expands the tree to the currently selected page. This avoids having to drill down through the tree when you want to change the selection to a sibling or child of the currently selected page. This was the primary motivation for creating the module. It's faster to navigate through because the whole tree is rendered at once rather than branch by branch. It provides a filter feature to locate pages by title anywhere in the tree. When the tree is filtered you can hover a page title to see the breadcrumb path to the page in a tooltip. It provides buttons to clear the current selection, to restore a changed selection, and to scroll to the selected page. Configuration The following config options are available when using the module as an inputfield for a Page Reference field: Exclude admin pages: excludes pages from the tree that have the admin template (only affects superusers who can otherwise see pages with this template). Exclude pages by template: pages having any of the templates you select here will be excluded from the tree. Descendants of any excluded pages are also excluded. Limit for total pages in the tree: this limit is applied to the selector that finds pages for the tree (default is 5000). Limitations and considerations Performance seems to be reasonable when the tree consists of up to 5000 pages. Your mileage may vary and the module may not be suitable for sites with a very large number of pages (unless excluding pages by template in the inputfield configuration). Pages in the tree show their titles rather than any custom setting defined for the template "List of fields to display in the admin Page List". Page titles are only shown in the default language. The module does not reproduce some of the quirks/features of ProcessPageList such as excluding pages that are hidden and non-editable, and forcing the sort position of special pages like Admin and Trash. ProcessWire >= v3.0.248 is needed for the inputfield to appear as an option in Add Field due to this now fixed core issue. Replacing InputfieldPageListSelect in the ProcessWire admin An autoload module named ReplacePageListSelect is bundled with InputfieldPageTreeSelect. Install the module if you would like to replace all instances of InputfieldPageListSelect in the ProcessWire admin with InputfieldPageTreeSelect. For advanced use cases there are two hookable methods: ReplacePageListSelect::allowReplacement($inputfield): set the event return to false to disable replacement on particular instances of InputfieldPageListSelect. ReplacePageListSelect::getPageTreeSelect($inputfield): set excludeAdminPages, excludeTemplates and limitTotalPages properties on the event return InputfieldPageTreeSelect object when replacing particular instances of InputfieldPageListSelect. https://github.com/Toutouwai/InputfieldPageTreeSelect https://processwire.com/modules/inputfield-page-tree-select/

I can confirm that the code I posted still works.

Thank you @Juergen for the fixes. Sorry not to reply before but I have few free time. ^^ I found more issues: File upload is limited to 500 MB: $zipUpload->setRule('allowedFileSize', '524288000'); But I can add a file larger, the form is valid and the upload starts, but then the server is not happy: With module FrontendLoginRegister, in Account Settings I add Language field. I have 2 languages, french and english, french is default. The form displays the 2 languages only if user is actually using french, when using english, only english is listed in the Select field. If user selects english and save, it works. If user selects french it is not saved. I try to investigate the code quickly, only to find that in Select::___renderSelect(), when user is using english, $option->render() returns an empty string for french.

Thank you so much, you saved my day. Edit: My problem is resolved.

Yep, I confirm this still works today. However, the website in question is still using an earlier version of ProCache. 😄

@prestoav, thanks for the compliments 🙂 I forked AIOM primarily to fix issues I was facing, and then it somehow developed into the version with the caching options. I don't use minification of CSS/JS. I think it's enough to use simple preg_replace to remove blanks. It's painful to follow and track issues for all libraries now included in the module (voku html_min, simple_html_dom, symphony css selector, lessmin, cssmin, jsmin, ...). Not worth it for those few percentages. But hey, the module works, even on PHP 8.5. Did you try/test caching options? @David Karich, I didn't change the class name as I wanted to preserve its name and your contribution/authorship of the module. Thanks for the module! I'll PM you.

Maybe one of these?

Hello @Juergen, once more thank you very much for your superb support 🙂 In the meantime I found the "Multi-language" section in the documentation as well - sorry I have overlooked this. But the infos you provided above are much appreciated, I will dive into this later on today. Regarding the multi-page form - I need to reconsider this as implementing forms seems to be a challenge for me as a citizen web developer on its own.Maybe the Form Builder plugin can help to achieve this...

I have found the issue: This only happens if the ID and name attribute are exactly the same on a single upload field. If there is a difference, everything works as expected, so I have added an additional suffix to the ID attribute of a file upload field to prevent this behavior. display-change.MP4 Now everything should work fine! Module version is updated, so please test if everything works now as expected.

Hello @da² I have fixed the 2 bugs with the URL segments (fixes will be in the next update), but I have a question concerning the file upload issue in single upload fields. I have tested it with Firefox without any problems. Take a look at the video. Single file upload.MP4 In my case it works as expected. If I drag and drop more than 1 file only the last file will be taken and only 1 file will be submitted. What browser do you use? Maybe it could be a browser related issue. Best regards Jürgen

Off the top of my head, if you require all pages to utilize the unique status, ProcessWire can take care of this for you. You don't ever need to know the path, only the $page->name property, when creating links to pages. That will retain what your client seemingly wants. It may cause issues elsewhere though, if you actually need depth (potentially with URL hooks), or certain modules. I base my response from this short topic:

Hi, well, all this sounds quite normal, when starting an install process, if the htaccess file is named .htaccess the web site will try to work as if it were installed which is not the case in the contrary, wuen the install process is running/finished this file needs to be renamed as .htaccess with the starting period else it won't work as the server won't find it as a genuine .htaccess file il you have a look à the install.php file code, you'll see when the mutation takes place 🙂 have a nice day