Leaderboard

ProcessWire 3.0.197 resolves 9 issue reports and adds 3 feature requests. For details in resolved issues and feature requests, be sure to see the commit log. I'll cover a couple of my favorite feature requests that have been added this week: New $files->getCSV() method This comes by way of feature request #400 via @bernhard to add something to abstract away the redundant details of reading a CSV file into one simple method call. This simplifies the reading of a CSV file by abstracting file-open, get-header, get-rows and file-close operations into a single method call, where all those operations are handled internally. All you have to do is keep calling the $files->getCSV($filename) method until it returns false. This method will also skip over blank rows by default, unlike PHP’s fgetcsv() which will return a 1-column row with null value. Here's how you use it: Let's say we have this CSV file (first row is the header): Food,Type,Color Apple,Fruit,Red Banana,Fruit,Yellow Spinach,Vegetable,Green Here's how you'd use the new method: while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } There are also several $options supported, see the $files->getCSV() documentation page for more. There's also a new $files->getAllCSV() method that does the same thing but returns all the rows in the CSV file in one call. Improvement to InputfieldPageListSelectMultiple Next was feature request #339 that requested adding the enhancement developed by @Robin S (via the PageListSelectMultipleQuickly module) into the core. This enhancement keeps the selectable page list open for multiple selections rather than closing it for each selection. It also better indicates when an item is selected. While I ended up writing it in a different way than Robin S.'s module, the end result is nearly identical to Robin S.'s short GIF screencast below: Also added this week is a new "visibility" option for Inputfields: Open + Locked (not editable), along with some small hook documentation improvements in the Pages class. Thanks for reading and have a great weekend!

Natasha Marques is a desserts chef and chocolatier from Brazil with an international carreer. Now established in my hometown Porto, she's about to open a shop and already shipping her premium line of sweets and desserts. The website is my usual combo of PW with StencilJS frontend with a content blocks approach. Minimal stack of modules: SeoMaestro, WireMailSmtp, and my own block selector module which is a hacked version of FieldSelectFile. The site is only in portuguese, but have a look anyway: https://arbynatashamarques.com/

Very wild guess here. I'm just wondering what major thing changed between 3.0.184 and 3.0.192? When I read about the lazy loading issues here, I am just wondering if there is a connection. Just a very wild guess. @ErikMH, are you able to upload the code that is not working to some gist or here for us to play with? I haven't followed the whole of this thread so apologies if I have missed it.

Hi @Val_0x42, Yep, please ignore my suggestion or question. It is totally fine to use PWs user, maybe a role with only guest rights, but able to register and authenticate. With guest rights, they can see nothing in the backend. To the other points: I like to code old schooled. ? First send a complete form with checkboxes and submit button, so that it also will work without JS, or, more interesting today, when any early JS throws an error and it stops further execution. Then also a "modern page" maybe left unusable when the bound events cannot run, or even got not bound to the checkboxes, etc.. The next step for me would be to disable the submit button on DOMContentLoaded, collect all checkboxes and add a change event to them, for example: (code not tested, written in the browser) ... <form id='myForm'> <label for='i1234'><input id='i1234' type='checkbox' value='1234' /> YOUR CONTENT HERE </label> <label for='i1235'><input id='i1235' type='checkbox' value='1235' /> YOUR CONTENT HERE </label> <label for='i1236'><input id='i1236' type='checkbox' value='1236' /> YOUR CONTENT HERE </label> <label for='i1237'><input id='i1237' type='checkbox' value='1237' /> YOUR CONTENT HERE </label> <label for='i1238'><input id='i1238' type='checkbox' value='1238' /> YOUR CONTENT HERE </label> <input type="submit" name="submit" id="submit" value="SEND" /> </form> <script type='text/javascript'> document.addEventListener('DOMContentLoaded', function(event) { const myForm = document.getElementById('myForm'); myForm.getElementById('submit').style.display = 'none'; // or, for better A11y support, visibility = hidden, plus shrinking the sizes, or move it out of viewport const checkboxes = myForm.querySelectorAll('input[type="checkbox"]'); for(i = 0; i < checkboxes.length; i++) { // add on change event listener for each checkbox in the form: checkboxes[i].addEventListener('change', function(event) { // get the ID and the status (checked|unchecked) and send via AJAX to update the server. Done! :-) }); } }); </script> </body> </html> Hope that helps to get started. ?

or simply $config->debug = false; $config->moduleInstall('download', true);

Thanks for your interest, @kongondo! In fact, I was able right from the get-go to pin it down to the difference between 3.0.191 and 3.0.192; I mentioned 3.0.184 recently, though, because that’s the last master release before things break for me. Here are the 3.0.192 commits on GitHub, which I linked to above. @bernhard, I decided to go all in on your suggestion of a new project: I created a new server (“Ori”) running 3.0.191. There, I created two templates (“Parent” and “Child”), and set them up in their family tabs so that only “Child” could be the child of “Parent” and only “Parent” could be the parent of “Child.” I turned on page classes, and created ParentPage.php and ChildPage.php files in the site/classes/ directory, setting each up as a subclass of Page. I created a public function in each (identify()) which returns a small definition list that includes the template and the ID of $this. I then created a page of template type Parent, and gave it a child of template type Child; in each case, the template calls the page’s identify() function and echoes it into the HTML, and it checks whether its parent record has an identify() function and echoes its results out, too. As expected, when I load the parent page on the front-end, I see that its template is Parent and its ID is 43 — and no information is provided about its parent (which would be the home page, which doesn’t have an identify() function). Also as expected, when I load the child page on the front-end, I see that its template is Child and its ID is 44, and that its parent template is Parent with an ID of 43. So much for the “control” — it worked as expected. So then I cloned that entire “Ori” set-up as “Nori,” which I then upgraded (3.0.191 → 3.0.192), and loaded the same two pages. I had expected to see the same result for the Parent page, but only the Child information for the Child. Unfortunately for me (but probably fortunately for @ryan!), nothing broke in 3.0.192 on Nori: the Child page also (properly!) showed its parent’s information. So then I began installing each of the modules that I’m using one by one on Nori, and testing the results (still in 3.0.192). I have more modules than I thought! But none of them caused my 3.0.192 test to break the way it does to my system IRL. I guess my next step at this point would be to gradually change the config.php file to match my system, with tests after each change. And then, gosh, I guess gradually re-create the whole system until something breaks. I think I‘ll take this evening off before embarking on that tomorrow. I have no idea how I could create a gist to show this, but I‘d be very happy to give any of you access to a copy of my development system where everything works perfectly in 3.0.191 but not in 3.0.192. Please PM me if you‘d be willing; I‘ll treat you to a couple of beers if you can help me make headway on this!

This module for ProcessWire enables the debug mode to bypass the restriction to install modules. This is useful if you are tired to manually set the debug mode in the configuration. Note Please note that this module doesn't replace the real debug mode in the configuration file /site/config.php. With this module you will not receive any errors/notices/warnings like in the real debug mode. It serves only to bypass the restriction to install modules. Installation To install this module you have to enable the real debug mode. After installation you should deactivate debug mode again. To enable the real debug mode, download /site/config.php via FTP and open it in a text editor. Look for a line where you can find $config->debug = false; change it to $config->debug = true; save the file and upload it again. After module installation change it back to $config->debug = false;. For all future module installations, you just have to enable the debug mode in the module settings like described below. After module installation, you should deactivate it in the same way. Settings The settings for this module are located in the menu Modules=>Configure=>DebugModeSwitch. Enable or deactivate debug mode Set the checkmark (1) and click the submit button (2) will enable the debug mode (3). The debug mode can be also restricted for superusers only (4). Links ProcessWire module directory: https://processwire.com/modules/debug-mode-switch/ Github: https://github.com/techcnet/DebugModeSwitch

Hi @tcnet - firstly, I am sorry if I came across as criticizing the module - it was genuine question - I thought perhaps there was some other advantage I wasn't aware of. For example, sometimes I want to be able to access the "Database Queries", "Timers", and "Autoload" sections that are only available in Tracy when debug mode is on. I was wondering if perhaps this module allowed for that. Regarding the changes in 3.0.163 - I thought the ability to install modules being restricted to debug mode and the new $config->moduleInstall() options were both introduced in that version, but maybe I am wrong. I don't see any reason to remove the module - I was just hoping for some clarification so we all know its benefits. Thanks for the contribution!

That's why I was asking for a generic example. I'd not be happy if lazyLoading was disabled by default. It's imho much better to add one single setting to old installations when needed (and I have not had any issues until now) than to have ProcessWire not use it's full performance by default. And don't forget updating old setups is a one time thing. I don't know how this feature works internally but I'm sure Ryan has made that decision thoughtfully.

@AndZyk Thanks! ? but as I've mentioned above I would like to avoid those if/else and updating code everytime when I add/change something ? After some more testing it looks that the problem lies in my code. I'm using wrong method, childTemplates gives me ID of child template, while I should use childTemplates() - that returns array of templates objects, and it works with LazyLoading enabled. Working example: if ($item->hasChildren()) { $template = $item->template->childTemplates(); foreach($template as $child) { if (!empty($child->noChildren)) { $no_children = true; } } } @bernhard basically I couldn't access template object and it values, but this looks more like an edge case, and I couldn't find more generic example. You would need to have a similar setup (let say blog as parent template + child blog-post template that doesn't allow childrens) + code needs to lands in the _init.php and you have to be logged in. $parent = wire('pages')->get('template=blog'); $child = $parent->template->childTemplates; $template = wire('templates')->get($child); var_dump($template); With lazyLoading enabled this returns NULL instead of a template object (it ruturns object if you are on a child page). As I've mentioned it looks that I was using wrong method, but I think that question still remains if lazyLoading should be enabled by defalut, especially if it can bring some code breaking changes - also like @szabesz mentioned above.

Thanks @kongondo. Just enhanced and fixed a few bugs in the new 'in field' conversion feature in v0.0.10. I tried to use hyperscript to do this, given its purported 'compatibility' with htmx, but I came across the same problem with lazy-loaded fields as we had with htmx - i.e. it didn't trigger when used in a field inside a repeater matrix item. However, there didn't seem to be a similar ready fix for this, so I resorted to good old fashioned jQuery which seems to work OK ?

Thank you for your explanation. In this case I would just use an additional if-condition. if ($child->hasChildren() && $child->template->name !== "blog-post") { // Subnav } Maybe not elegant but simple. ?

Have you tried calling $modules->get('yourfieldtype') before using the API? To avoid that, you could turn Event and EventArray into autoload modules.

@7Studio I don't understand. Which property can you not access? Can you give a generic example?

Me to. Just recently I've read two PRO module forum posts where the PRO modules did not work properly with lazyLoading enabled. I am surprised that Ryan enabled it by default, as usually he does the opposite, like in the case of Markup Regions, Page Classes and Functions API. Why should useLazyLoading be en exception to this? Now I need to add $config->useLazyLoading = false; to all the configs of all "my" sites to be on the safe side.

Hi @AndZyk, Thanks for your reply! Maybe I wasn't clear enough, to explain this further - I would like to avoid including childrens as menu items even if they exist in some scenarios, for example hierarchy of my blog looks like this: blog page (blog template) article (blog-post template) article (blog-post template) ... In my case blog-post is a template that can't have children, but Your example will display every single blog article title as a child in menu, which of course I want to avoid. By checking a blog-post template settings (noChildren allowed value), I can skip articles from beeing rendered in a menu and for example adding "parent" CSS class to blog page menu item. I can do the same for other pages that follow same site structure, like portfolio -> portfolio item etc. while using template settings only. For menus I prefer to have a single function that is used to render all kind of menus, that simple helps me to limit code and usage of if/else checks for a specific templates while building menu. Anyway, since 3.0.194 I can't access these values any longer, (as long as I'm not on a blog post page). Lazy loading in this case limits my access to needed values, so I'm wondering what else can't be accessed and if that is not much to have it enabled by default, when PW in most cases is blazing fast (Just loud thinking) ?

You are not dreaming - this is already possible using RockMigrations: <?php $rm->migrate([ 'fields' => [ 'myfield1' => [ 'type' => 'text', 'label' => 'My field one', ], 'myfield2' => [ 'type' => 'text', 'label' => 'My field two', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'myfield1', 'myfield2', ], ], ], ]); If you don't like PHP arrays for whatever reason simply use json_decode( _your_fields_and_templates_as_json_string_ ) instead... I'll release a new version soon that makes it a lot easier to get started with RockMigrations though the API will 99% be the same as in the old module.

The reason for this is that you are setting the divisor and the probability after the execution of the garbage collector has already been decided (in other words, after the execution of session_start()). With Ubuntu your default value for the probability is 0, meaning it will never execute. You need to place those ini_set directives before the session is started. In ProcessWire one way to do this would be wire()->addHookBefore("Session::init", function() { ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100); }); You would need to place this inside an autoloading module though. Another way would be setting those inside your .htaccess with php_value session.gc_divisor 100 php_value session.gc_probability 1 (depending on your host, this might not work) Your last resort would be clearing them "manually" by adding this to your _init.php. Well basically you wouldn't even need a hook, you could just execute the code. wire()->addHookAfter("ProcessPageView::finished", function() { $prob = ini_get('session.gc_probability'); $div = ini_get('session.gc_divisor'); $path = ini_get('session.save_path'); $expire = ini_get('session.gc_maxlifetime'); if(rand(1,$div) <= $prob)) { foreach(glob($path.DIRECTORY_SEPARATOR."sess_*") as $file) { if(filemtime($file) <= time() - $expire) unlink($file); } } });