Leaderboard

I've just released RockFrontend 3.0 https://github.com/baumrock/RockFrontend/releases/tag/v3.0.0 @netcarver found that .less and .latte files were publicly accessible if you knew the file path (eg example.com/site/templates/sections/footer.latte) which is for sure something that you don't want even though it should not really be a security concern. Sorry for that and thx for spotting @netcarver ! The latest release updates /site/templates/.htaccess to block access to .latte/.twig/.blade/.less files so be sure to upgrade RockFrontend in all your installations! Other than that I've also changed the way how RockFrontend loads assets and I'm not 100% sure if that might introduce issues in existing sites, so be sure to check if everything works as expected. New features: RockFrontend now ships with https://github.com/wasinger/htmlpagedom wich let's you parse and manipulate html markup which can be super handy in several situations. I'm using it on my new website where I'll show docs for all my modules that are rendered from markdown files and add some magic here and there via manipulating the resulting html that comes from the markdown parser. Improvements for the Topbar: There is now a toggle that makes it possible to hide/unhide the bar instantly (and persistantly). Also you can add your own custom markup to the topbar by adding custom markup to $rockfrontend->topbarPrependMarkup or topbarAppendMarkup.

I don't see anything wrong with the logic used, so there might be some underlying issue with how you're using it in this context. If you definitely want a full WireArray class object to hold this particular structure, would this work for your use-case instead? <?php $homePage = $pages->get('/'); $sectionPages = $homePage->children(); $sectionPages->prepend($homePage); This takes advantage of the WireArray method "prepend" instead of the WireData method of "and". If you're looking to generate a breadcrumb (edit: $page->parents for breadcrumbs) or navigation menu, or sitemap, the example code from the sitemap.php template in one of the default profiles might come in handy (included below in its entirety): <?php /** * Site map template * */ include("./head.inc"); function sitemapListPage($page) { echo "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { echo "<ul>"; foreach($page->children as $child) sitemapListPage($child); echo "</ul>"; } echo "</li>"; } echo "<ul class='sitemap'>"; sitemapListPage($pages->get("/")); echo "</ul>"; include("./foot.inc");

@BrendonKozthanks for your hint! Prepending the page even seems to be a bit more performant. Regarding the MySQL timeout - it was another problem which I could fix in the meantime.

There's this: https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/ And this: https://github.com/processwire/processwire/pull/267

Hi, I just did a fresh install of 3.0.218 twice and received this error message both times. Using php -S localhost:8000 as my server. I am using php version 8.2.6 on ubuntu. Note, I did install 3.0.210 and it worked. I was at the point of the install where I set an admin user, and tell it to delete the install files, I received this error message. Hmm… Fatal Error: Uncaught Error: Call to a member function get() on null in wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module:625 #0 wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module (1819): InputfieldSelector->sessionSet() #1 wire/core/Inputfield.php (435): InputfieldSelector->setAttribute() #2 wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module (224): Inputfield->__construct() #3 wire/core/Modules.php (700): InputfieldSelector->__construct() #4 wire/core/Modules.php (1211): Modules->newModule() #5 wire/core/Modules.php (1023): Modules->loadModule() #6 wire/core/Modules.php (407): Modules->load() #7 wire/core/ProcessWire.php (557): Modules->init() #8 wire/core/ProcessWire.php (315): ProcessWire->load() #9 index.php (52): ProcessWire->__construct() #10 {main} thrown (line 625 of wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.module) This error message was shown because: site is in debug mode. ($config->debug = true; => site/config.php). Error has been logged.

According to the docs at https://processwire.com/api/ref/wire-cache/get/ for $cache->get($key, $expiry), $expiry means: I thought that meant: at 9am store something with an hour's expiry (so 10am) using $cache->save($k, $v, 60*60); At 9:01am, ask for it, if the value is younger than 30 mins, using $cache->get($k, 30*60); But it doesn't. And it seems to me it can't do as it's documented to do because the date the thing was stored (and therefore how old it is) is not stored in the db table. In fact the SQL that's run is: SELECT * FROM caches WHERE name=$k AND expires <= 9:31am So even though our data is 1 minute old, it's not considered younger than 30 mins old and is not returned. The only way the cache could honour the docs would be if the date the thing was stored in the db was saved. Then we could do whenSaved < 9:31am (though I'd suggest we also specify that it hasn't expired too, to honour the save() contract). But we don't have that field. Just wanted to sanity check these findings with the community. And if I'm right, how do we go about suggesting clarifications for the docs? If I'm just a confused noob, please explain the designed use-case for the documented get/expiry behaviour.

Hi, Is there any solution to making output regions work with field templates? I've inserted this at the end of "/site/templates/fields/images.php" file. What I'd like to achieve is to insert the js module only on field render (to optimize the js...) ?> <script pw-append="modules" type="module" src="/site/templates/scripts/gallery.js" defer></script> of course i have the region defined in the "_main.php" <pw-region id="modules"></pw-region> and it works from regular templates, just not from field templates... because they're just "compiled" in a different way. Thank you!

Hello @ryan, I had to change some role names on an existing site – after a while I recognized changed behavior for some role related functions. What I found is that using roles in selectors doesn't work exactly the same as I see on other fields: $s1 = "roles=aaa"; $s2 = "roles=aaa|guest"; $s3 = "roles=aaa|guest|notavailable"; echo $users->find($s1); //works, returns some users echo $users->find($s2); //works, returns some more users echo $users->find($s3); //returns empty pageArray ! As soon as I do an "OR" with a role, that does not exist, it wipes out the whole result set. Is this the intended behavior? I guess not, but maybe you can tell me where I'm wrong. Thank you!

If you know you're going to loop through a structure anyway, even if it might look a little bit cleaner by storing things in a variable first, the descriptive nature of ProcessWire's methods (API) usually provide more than enough context-via-code to not really warrant setting up variables first. I just checked my own navigation structure and although I (ironically, because I had forgotten) created nearly the exact same code as above (get homepage, then get children of homepage, then prepend homepage to children variable), I didn't use it. Homepage is always page ID #1, or (nearly always) "/". We can test numChildren, and if so loop through the children, then as we get to the children we can also test each of their numChildren and if > 0 then loop through their children, and so on. ProcessWire's structure essentially already is hierarchical (array-like). Trying to recreate it in variables might end up duplicating the order of magnitude by 2 (loop via the API behind the scenes to create an array for a variable, then loop through the variable --- or just use the API to loop right in our code). Example: <?php // We assign $homepage to a variable since we refer to it more than once $homepage = $pages->get('/'); if ($homepage->numChildren(true)) { # code goes here to create link structure foreach ($homepage->children() as $main_link) { # code goes here to create link structure if ($main_link->numChildren(true)) { # code goes here to create link structure foreach ($main_link->children() as $secondary_link) { // If we go deeper than this, a recursive function // is likely better, so this example will stop here # code goes here to create link structure } } } } I used foreach here, but ProcessWire also has an each() method that you could substitute in, if you'd prefer. NOTE: I don't remember why I tested if there were numChildren first; I might get an error in PHP v8+ without it, I can't remember. I think the ProcessWire each() option would circumvent the need for that check, unless you need to do something in an else block.

New month, new version: https://github.com/baumrock/RockMigrations/releases/tag/v3.26.0 Bug Fixes double linebreaks (bf07c6b) magicpages comparing classnames without namespaces (28b5657) prevent migrating pageclasses twice (b3c9add) remove double slash when using $this->path (aa9502c) wirerandom issue on deployment (29bd145) Features add placeBefore to wrapFields() (906753c) add random salts to config-local suggestion (1e7401c) add rm-hints to field and template gui (27b5b25) add support for parent_id as page path (e45e430) imporve createPage for array syntax (74bd338) improve getTemplate (use ::tpl fallback) (b6f6d14) improve isDDEV() (e4df541) improve setFieldData() method (2830eed) use $this->path instead of DIR #22 (f134e1b) One very nice feature is that RockMigrations now adds uikit tooltips to the field and template editor where you can directly inspect the name of the property to use and also the value of one setting, which is very handy if you need a setting that you don't know by heart. With this update you don't need to find the setting by inspecting the html markup any more and you can instantly see it by hovering over the setting:

I think you are right for the ->title, but not for the ->url. The url is a property of the page object, not a regular field. So there is no textformatter applied and therefore it should just work like shown in the example. If you have a textformatter applied on the title field, then you'd need a |noescape filter in latte, yes.

I have the same problem, freshly downloaded 3.0.218 DEV version @ryan is there a problem here with the current version? /edit: reverted to 3.0.217 DEV and it's working...

In the meantime, I have packed the backup site with its db, that looks correct. Looking into page differences, I've found that if I add a new item in the repeater field on the main page, this item uses a new template for the repeater: "repeater_vouchers1" instead of the original "repeater_vouchers". New template is created yesterday. Obviously the php code doesn't extract nothing, becuse all the selectors points to "template=repeater_vouchers, ... " But if I delete this item from the main page, it is deleted also from the admin for-page-XXXX container. This did not happen for the original articles... Very strange. For completeness, these updates were made yesterday: The only one I think might have affected is core 3.0.210 (updated to migrate to TinyMCE): current repeater field is a FieldTypeRepeater, not the Matrix bundeled with pro ones. 01/06 - 10:44 Just finished to apply the same upgrades, step by step with double check on backup version of the site and all is fine: no repeater problems...

@szabesz Nice. I think I prefer that to the maths Q approach as it requires less mental effort.

Sounds like a bug - could you raise an issue on processwire/processwire-issues?

@flydevThanks for your suggestions and links to posts and code examples. Highly appreciated. Got the idea and philosophy already partially by Bernhards YT video, which brought me to PW first place. Was about to start with pure PHP/MySQL, HTML/CSS/JS. Pretty sure I wouldn‘t be that far, as I did my last serious PHP/MySQL project about 5 years ago. So far I am pretty happy with PW and I know I just revealed the absolut basics yet. Looking forward what more to come in the future.

Best would be to use ProCache which does exactly this. You just have to select the template you want cached and update your .htaccess so your server serves the generated page’s HTML. Edit: note though that the page needs to be visited for it to be cached

Depending on your requirement, you could generate random URL. my best bet (because you ask free solutions) is to use a custom login form as I suggested yesterday, or going with @Juergen module lower/mitigate attacks: Shield NGINX @mitchellkrogza/nginx-ultimate-bad-bot-blocker You might be interested in (Pro) WireRequestBlocker / (Free) Blackhole Module: https://weekly.pw/issue/195/ for an intro, and

Yes, that's what is good with this tool, you are not required to be stick with a fixed solution. You can implement what's you have in mind and how you want to implement it. Really glad to see where you already are on using ProcessWire, it seem you got the freedom philosophy it bring to you 👏👏 The module FrontendForms from @Juergen look a good candidate to me as he maintain it and did a fantastic job on it. Also, I saw @AndZyk linked LoginRegister Module in other thread which could fit good here, for free. I remember we discussed years ago on some customization tricks that could give you ideas. Below you can find a thread about it, but keep it for later as I see you are short on your deadline 🫡 The original blogpost for the Pro version, just in case: https://processwire.com/blog/posts/login-register-pro/ You will find also a lot of tips (generally using code from quite deep in the core) from @Robin S in the forum, there are so much of them that you will need google to find them 😂 PS: I am going to add a comment on your other threads about the spam protection.

Do you get any result when you output the body unformatted? <div id="content"> <?php foreach($page->sections as $x) : ?> <?= $x->getUnformatted('body') ?> <?php endforeach ?> </div>

Ryan has already responded to the Github issue and will merge the fix as soon as it can be confirmed. Passing along a PW API method call he shared that can fix this in case anyone that runs into this and wants to skip working in the DB directly.. $query->exec('RENAME TABLE tmp_field_body TO field_wvprofile_body'); Thanks @ryan!

I did a little more digging too. It seems as part of the field rename process, the corresponding (old) table is temporarily renamed to tmp_field_yournewname, and then tries to rename this temp table to the correct new name: field_yournewname. This second part fails because the table already exists, so I believe this throws an Exception and you would expect the admin to re-render with an error notice. (Like it does with the normal duplicate field name error). However, since the underlying field's DB table has been renamed to its _tmp version, there's another exception, showing the error. At least I think that's what's happening. DB table names are lowercase by default ($config->dbLowercaseTables is true unless overridden), so 'Body' will try to create 'field_body'. @FireWire, you might find there's a tmp_field_body table in your DB, with all your content intact. Good to know there's a Github issue opened.

I tested in 3.0.217 and when trying to rename a field to the same name as an existing field PW gave an error notice, did not change the field name, and no data was lost. So maybe it was a strange glitch, or it was an issue that was fixed between 3.0.165 and 3.0.217.

That's (very) unfortunately not possible because the input field used there, InputfieldTextTags, uses jQuery's selectize addon, which doesn't allow duplicates. A bug requesting that capability has been opened ten years ago. It might help to upvote this bug, then @ryan could adapt InputfieldTextTags (or rework, most likely, since it uses tag values as keys, which also eliminates duplicate values). There's, however, already code inside InputfieldTinyMCEConfigs.php for a textarea instead of a text tags input (with all the downsides of not validating the names entered) for the toolbar config. Just uncomment the code here and comment out the field definition after that.

This is a simple module to prevent guest users and search engines from accessing to your site. Primarily it is designed for use during site development. Modules directory: http://modules.processwire.com/modules/protected-mode/ Github: https://github.com/adrianbj/ProtectedMode Install and check the "Protected Mode" checkbox Create a user with only the guest role and give the login details to your clients/testers. Of course existing admin users can use their personal logins still. There are some similarities with Pete's excellent Maintenance Mode module, but the reason I built this, rather than using Maintenance Mode is: I didn't want the "Maintenance Mode" badge showing up on the site since this is for development before a site has ever been live and I didn't want the client seeing that badge. I didn't want users redirected to the PW login page because I didn't want visitors to see the PW login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form, and also apply some css to style the login form. Hope you guys find it useful.