Leaderboard

https://github.com/processwire/processwire-issues/issues/1516 https://github.com/processwire/processwire-issues/issues/1823

This seems to be because the XHR request that gets the live results as JSON requests the same URL and headers as a normal visit to the search page, so the browser gives you its cached version. You can also observe it the other way around: If you head to https://processwire.com/search/?q=hello and then use the search box for the same keyword, the browser console will show a JSON parse error because the live search got the full page instead of JSON. I imagine this could be fixed by sending the ol’ X-Requested-With: XMLHttpRequest header. Or by using the appropriate content negotiation header (I think “Accept: application/json”?).

$wire->addHookBefore('Inputfield::render', function (HookEvent $event) { $inputfield = $event->object; // Proceed only for 'yourField' if ($inputfield->name !== 'yourField') { return; } // Get the associated page if (!($page = $inputfield->hasPage)) { return; } // Check if the page is part of the yourPageArrayField on page with id 1 // (or whatever the ID of the page with your pageArraField is) $productPages = pages()->get(1)->yourPageArrayField; if ($productPages->has($page)) { $inputfield->attr(['checked' => 'checked', 'value' => 1]); } });

Boy howdy, you're on FIRE! Nice work!

I installed the new RockForms version 2.0.0 and now everything works: The DataPage is displayed in the page tree and the form submissions are saved as child pages of the DataPage. Filtering via the ProcessWire Find and Bookmarks feature also works like a charm. (I also installed RockGrid (1.0.2), but when trying to create a new Grid, there was an error message (RockGrid::refresh does not exist or is not callable in this context), so I postponed the test until later, when I finished my current project 🙂) Thanks @bernhard !

Hey @nurkka just had a look and totally forgot that I added a setting for that. The reason is to not break existing installations but set a new default for new installations: Without that setting sorting will have no effect. Did you check that box?

I've added that to the docs for you some minutes ago 😉

Hey @nurkka glad if you like it 🙂 I've added docs for this question here: https://www.baumrock.com/en/processwire/modules/rockforms/docs/entries/ Does that answer your question? I'll come back to the other question later.

No, I understood that. But I didn't want to mess with the sort order and thought this would be a better and more powerful solution. For example let's say you have blocks "Gallery - Hero - Info" (sorted a-z) But for blog posts, you want editors usually add them in the order "Hero - Info - Gallery" You can now add a preset called "Default Blog Post" (or anything else) and when the user clicks on that preset it will add blocks in the order "Hero - Info - Gallery" You could then also add different presets to that page and this would not be possible with your suggested sort feature. For example you could have two presets "Default Blog Post" and "Event Blog Post" or whatever.

Hi @adrian. Thanks for the comments. That was the intention, but I missed it in one important place - hopefully now fixed. I think my new version handles this. Ditto. My code only replaces config items which have page, field, template, role, or user in the key name (case insensitive) and where the value is numeric and is a valid id for the related type. Hopefully this avoids the problem you mention. If someone builds a module with a type name included in the config key with numeric values which are valid ids, but where the values are not intended to refer to ids of that object type, then it won’t work, but that just seems really perverse to me! I have uploaded the new code to my GitHub and have incremented the version and amended the ReadMe. Obviously it is pretty hard to test it on all modules, certainly as regards importing, but it seems ok so far. Let me know if you find any exceptions. One module that causes problems is (deprecated?) ProcessEmailToPage but it is a problem even without my changes. That is because the configdata is wrong - it self-overwrites - so not something that your module can fix, I think.

Interesting. I can reproduce in FireFox, but not in Chrome. Update: Ok, now I also get this in Chrome. When testing in my regular chrome window it worked without an issue, but when using an incognito window it shows the json.

Hey @bernhard, here is a little screencast in Firefox: Visit processwire.com Open the search field Enter a search term Wait for the autocomplete results Hit enter to get to the search results page I get this in Chrome, Opera, Edge and Firefox. Safari has no issue.

and that worked straight up 100% absolutely perfect. thank you!!

Hi @bernhard, The current Rockfrontend Docs talk about a favicon field that gets added if RockMigrations is installed (https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/seo/#favicon-and-og-image) In the code, I do not find any migration that installs that field. In the module code at https://github.com/baumrock/RockFrontend/blob/2c1570656bd0152f9927f03144d334eff5c8d4de/RockFrontend.module.php#L3346 it says Use [realfavicongenerator](https://realfavicongenerator.net/) to add a favicon to your site. Are the current docs this still valid? Since I don't have the favicon field despite RockMigrations being installed when I installed RockFrontend, I assume that functionality does not exist anymore? Could you please clarify. Thank you. Also In module settings, I get But there currently is no favicon.ico file in the root. If I change the check in https://github.com/baumrock/RockFrontend/blob/2c1570656bd0152f9927f03144d334eff5c8d4de/RockFrontend.module.php#L3335 to $hasFavicon = $http->status( $this->wire->pages->get(1)->httpUrl() . "favicon.ico" ) === 200; the detection works.

Thank you @gebeer I've removed those outdated sections from the docs! Also you are right about the favicon.ico detection. I've fixed that in v3.22.1 😎 The og:image field/feature has been moved to RockSettings module and the favicon has been removed in favour of a favicon generator, because these favicon generators do a lot more (like also making it possible to define different colours for different devices or adjusting border radius etc).

Hey @nurkka I have something for you 😎 Please download v5.9.0 https://www.baumrock.com/en/releases/rockpagebuilder/ All you have to do is add a hook like this to /site/ready.php: wire()->addHookAfter( 'RockPageBuilder::getPresets', function (HookEvent $event) { $page = $event->arguments(0); $field = $event->arguments(1); if ($page->template != 'blogitem') return; if ($field->name != 'rockpagebuilder_blocks') return; $event->return = [ 'Demo' => [ 'Alert', 'Features', 'Features', 'Videos', ], ]; });

Thank you sir! Seems to work fine as below: <?php namespace ProcessWire; // site/ready.php // HOOK $this->addHookBefore('PageFinder::find', null, 'hookBeforePageFinderFind'); function hookBeforePageFinderFind(HookEvent $event) { $selectors = $event->arguments(0); // AMEND SELECTOR $selectors->init("has_parent={$myDynamicID}"); // Populate back arguments (if you have modified them) // DON'T THINK THIS IS NEEDED AS IT STILL WORKS!? $event->arguments(0, $selectors); } Will do more tests and report here if I come across issues. Thanks!

Hello @DrewPH Thanks for reporting this issue and you are absolutely right. I have changed all class names (not only the "block" class name) of the CAPTCHA element by adding the prefix "ffm" to all classes. Now it should be very unlikely to get class names conflicts in the future. So please update to the latest version 2.2.17 in order to get all changes. You can read the full changelog here. Important information to all other users: If you have modified the styling of the Slider Captcha by adding your own CSS by overwriting the default CSS, please take care that the class names have been changed now and your changes will no longer affect the the styling of the CAPTCHA. So please adapt your custom CSS with the new class names.

After probably 12 years with Processwire, I just discovered that pressing the 🌲 tree icon link, in the breadcrumbs, opens a modal with the page tree.

Version 2.2.15 is out! This update comes with a small performance upgrade. Now you can choose on which pages you want to embed the JS and CSS files of the FrontendForms module. This means that you can prevent the files from loading on pages that do not contain a form. This also allows these pages to load faster This version includes a new configuration field in the backend where you can select all the pages where you want the files to be embedded. Best regards

Version 2.2.14 is out! This new version comes with a new CAPTCHA type: a slider captcha. Now FrontendForms supports 7(!) different CAPTCHA types and I guess this will be the last one. There is a fabulous module in the module directory which also creates a slider captcha that can be used with other forms: Slide Captcha. But the slider Captcha in FrontendForms is an extra coded and integrated captcha, that has nothing to do with this module. To be clear: The slider captcha inside FrontendForms is similiar to the Slide Captcha module, but it has nothing to do with it. So there is no need to install the other module. The only thing you have to do is to enable the slider captcha in the module configuration - that is all. You have 1 additional configuration field where you can select the accuracy of the puzzle piece to the goal. 5 means that the distance of the puzzle pieces to the target must be less than or equal to 5px in order to solve the captcha correctly. Here you can see the new slider captcha in action: As always, please report any bugs on Github!

Version 2.2.13 comes with an upgrade for the FrontendFormsManager module. The FrontendFormsManager module shipped with FrontendForms was added a few versions ago. The usage of this module is optional. This module now also supports the management of suspicious IP addresses. These are IPs that have been temporarily banned due to many unsuccessful form submission attempts (logging must be enabled in this case). A new section for managing these IP has been added. As you can see, a table of statistical data and a chart have been added to the FrontendFormsManager. When you click on the "Go to all temporarily blocked IPs" button, you will be redirected to a new page that contains all the temporarily banned IPs. The data is taken from a log file. Below you will see a screenshot of this page. Inside this table you have a button to view more details about this IP and a button to add/remove this IP to/from the blacklist. If you click the "View details about this IP" button a panel will be opened with more information about the IP and the number of blockings. With this information, you can now decide whether you want to block this IP permanently by adding it to the blacklist or not. Happy testing!

Actually, you probably want $field->addFlag(Field::flagAutojoin); $field->save(); so you don't remove any other existing flags.

Just for clarification, the "\" backslash works better: ProcessWire\wire()