Leaderboard

@TomPich I wouldn't recommend caching a field value like that, as I don't think you'll get any performance benefit since the amount of work for PW to do is the same either way there. What I'd recommend doing instead is caching the resulting output, which also means only loading the repeaterConsultants when it will be used to generate that cached markup. Whatever markup you generate, use that as your cache value, for example: echo $cache->get('consultants', 'hourly', function() use($pages) { $out = ''; $consultants = $pages->get(1027)->repeaterConsultants; foreach ($consultants as $consultant) { $out .= "<li>$consultant->consultantName</li>"; } return "<ul>$out</ul>" ; });

@iank I had a look at this and it seems like it can happen if you omit homepage language segments, and are also using the PagePathHistory module. What happens is that PagePathHistory provides a shortcut for finding the page, leaving no language segments for PagePathHistory to detect the language. I don't think PagePathHistory supported multi-language URLs until 3.0.186, so maybe that's when the issue started. Though the entire URL-to-page mapping system has been rewritten since 3.0.165 via the new PagesPathFinder class, so who knows. I think maybe it's not been reported before because just about everyone is using language segments on the homepage, and I always recommend doing so, but didn't intend to require it. I've attempted a fix on the dev branch, it's just one line of code, so maybe it'll work just to modify your copy too. Do you find this fixes it there? https://github.com/processwire/processwire/commit/9e6b89cf9331fccb8f41ae0b1785e21c8c5d62f0

Ran into the exact same problem a few minutes ago. Verified the [home] of composer with this: composer config --list --global And finally added it to my $PATH in .bashrc export PATH="$PATH:~/.config/composer/vendor/bin"

I don't know if this will help you in your case, but I will take your partner example here to demonstrate my way of doing similar things. Partners wouldn't be content on its own. I see them more like data I can re-use. Therefore I need two templates: partners (parent for all partner entries - just to group the partner pages) Fields: title Template file: none partner (single partner page with all the data, content, images) Fields: title, desc, image, www, phone, email, ... Template file: none With this setup I can create a RepeaterMatrix block called partners and would add a PageReference field there that allows multiple entries. Probably AsmSelect to be able to sort those entries. Or a selector field to look up (template=partner, sort=random, limit=5) Now whereever I want to display a set of partners I add that partners block, select my partners and it's done. There could be multiple blocks for partners in RepeaterMatrix - so the layout can change easily. partnersLogo - just the logo partnersLogoLink - the logo linked to the partners website partnersLogoDesc - partner name and the description partnersCard - full card with logo, name, description, link to website With this setup I create those partner pages somewhere in the backend and reference those. Would even work in case your partners would be pages on their own. In terms of images I stopped worrying too much. There are several ways to handle images. For example: Tags. Tag images with hero, gallery, avatar, or whatever and select images based on your needs. While this works I started using multiple image fields. It's easier (for me) and I can upload optimized images for each use case. AND I can check how many partners don't have a hero image, og:image or gallery images super easy.

Have you ever listened to the podcast Darknet Diaries - this is the exact vibe I always get about how these hackers are operating. Begrudging admiration for the ideas they come up with. Given that most email css is inlined, does this require the machine or platform of the mailbox doing the forwarding to be compromised? Otherwise how are they modifying the CSS without the forwarder's intervention? I guess a dodgy browser extension could also do this ? I.e. target the CSS of known mailboxes e.g. when you visit gmail or outlook. EDIT: After reading the article I realise I misunderstood the concept. So they're not modifying existing emails, they're sending and email with this method build in as hidden payload. I guess the lesson being to ensure trust of the original message.

Looking forward to the upcoming ddev 1.23.0 release as it should (finally) have fixed support for generating .avif images.

You can probably find the executable file from /home/<username>/.config/composer/vendor/bin -folder so running /home/<username>/.config/composer/vendor/bin/wirecli should work. If you want to use it without the path you should add that path to your shell $PATH-variable.

Hi everyone, AdminerEvo was updated yesterday, but the latest version no longer supports PHP 5.x. The fix is simple (it's a null coalescing operator issue), but I am tempted not to push them to support it, but before the opportunity slips by, is there anyone here who really needs 5.x support? I really hope not because if you're stuck on it for some hosting reason, it's time to move :) Let me know.

https://weekly.pw/polls/ Which PHP version are you hosting your ProcessWire sites on? (December 2020) PHP 5.6 or anything older than that (3.1%, 4)

Looks like the next level of Business Email Compromise just became unlocked (if it wasn't already.) Lutra Security have a nice write-up on the attack they are calling "Kobold Letters". Basically, email clients change the DOM of the email when they forward it, allowing different CSS to apply between the first recipient viewing an email, and subsequent recipients. Allows an innocent-looking "request to forward to the CFO" phishing email to the CEO to become a "request to send funds/data" when received by the CFO from the CEO. Explict verification of the request contents needed now, not just a "Did you send me a message?" question which only verifies that the message was forwarded. Something to be aware of if you work in a team or are responsible for any kind of staff training on phishing etc.

Nice as in... creative, impressive, stunning, unexpected. I really like how creative those bad guys are sometimes. These people would earn good money in QA - ok, probably even better when doing their bad stuff. Still I am more often impressed by how some people can think and how simple some things are. Similar to dark patterns and deceptive design. Not that nice to use those, but still clever. Oh... I probably should. Will look it up. Could be totally my thing.

@Entil`zhaand @wbmnfktr Thanks, confirmed that was the missing piece. Thanks for the details and much appreciated.

Hi, I have a site that uses Multi-language URLs and Multi-language Page names to present different language content for the same page, using a language specific URL. After upgrading PW to version 3.0.229, the language-specific field data is only displayed if the home page has the language name (segment) specified and marked as active. Prior to this ( version 3.0.165, I'm not sure at which version this changed), it wasn't necessary to set the home page language name and make it active. Instead, I could just create a specific name for a page beneath the home page (e.g. /test/ for the default language, and /test-fr/ for French), and mark that language as active just for that page, and it would work, displaying the language specific content for that page. The problem I have is that not all pages are translated - in fact there are just a few - and these might have different combinations of language-specific content. One page might have default (English), French and Spanish content, another page using the same template might have default (English), German and Dutch, for example. Hence I don't want the whole site to have a language prefix at the root for every language - just to have language-specific names for those (few) pages that are affected. Until now, this has worked fine, but since upgrading the site to 3.0.229, only the default (English) language content is being shown for those pages, even when accessed via their language-specific URL. Essentially the detection of the language from the page name is now fully dependent on the home page having that language active (and hence a segment prefix) whereas before it wasn't. Can anybody suggest a way around this? If I replace the core LanguageSupportPageNames module with the version from 3.0.165 then the previous behaviour is restored, but obviously that's not a very robust solution. Thanks. Ian.

@ryan - thanks for the quick response! That worked perfectly. ? I'll mark this as solved. Much appreciated, Ian. P.S. For anyone interested, here's the site and the specific page that the client noticed had the issue - content in 4 languages (English, French, German, Dutch) all now rendering as expected: https://www.traffic.org/unite-fr/

Great to hear that ? This is interesting. I've never really had the need for that - maybe because RockPageBuilder is doing that for me and I don't need it at all on frontend editing - but I'm wondering if a module setting could make sense. I could think of a checkbox "trigger frontend reload on page save", or maybe a config setting. A config setting could have a page selector that checks if the saved page matches the selector and only reloads if it's true. But I'm also wondering how that feature would be used and by whom. Would it be a developer thing? Or could it maybe also be useful for regular site editors? So far Livereload was really only intended for local development, but the technique has been quite reliable and should work with any infrastructure as SSE + JS is available everywhere...

Just started using RockFrontend on a local site and I'm relly enjoying livereload when updating .latte templates. In fact, as I work with my admin pages in a window on the left, and the site in a window on the right of my screen, I wanted to get livereload when saving pages in the admin - but only for the basic-page template. So here's a little hack. Adding this to site/templates/admin.php, before the line require($config->paths->core . "admin.php"); works great, and I now get livereload on page save or file changes. Not sure how well this will work with Alfred though as I'm not using that yet. $pages->addHookAfter('saved', function($event) { $p = $event->arguments(0); if (in_array($p->template->name, ['basic-page'])) { // Update array as needed $touchfile = __DIR__ . "/.lastupdate"; touch($touchfile); } });

Yes, that's right - it's all included in the original email. Ideally yes, but it's now possible for what the first recipient sees to be totally benign, just requesting the message be forwarded to another decision maker in your organisation. Once the forward happens, the message the 2nd recipient sees can be totally different to what the first recipient saw. So now the content of the forwarded message needs to be validated - not just a quick check that the first recipient actually forwarded a message to the 2nd recipient. If that's already part of the standard-operating-procedure (SOP) in your organisation, then I think you are OK. If that's not the case, then the SOP needs to be updated so validation of the forwarded content actually happens.

Did you use the "$cache->save()" method? So something like this: $cache->save("test", $consultants, 3600); // get single cache value $str = $cache->get('test');

Nice?

Done

Why is it that the bad guys are always so creative? They have the nicest hacks and ideas.

On the dev branch this week are a few issue fixes, but also some new features. The "Parent" field in the page editor (Settings tab) now is contextual to the page's template family settings. Now it will just show you the allowed parents, if you've configured them in the template. Previously it would show you a page tree to select from anywhere in the site. This saves you time, as well as the hassle of getting an error message after save, should you select a parent that isn't allowed by the page's template family settings. Next, the page tree "Move" actions (that you see when hovering a page in the tree) are now a little smarter. Previously, these Move actions would appear for any page that was either sortable or moveable. But now it also checks how many other allowed parents there are, per template family settings. If there aren't yet any other potential parent pages existing in the site, the page is no longer considered moveable, and thus won't show a Move action. This useful addition was added per Bernhard's request, as was the addition to a couple new classes used in the page tree to better differentiate between public vs non-public pages... something that I understand Bernhard's admin style may soon demonstrate. This week a question came up through email about how to make multi-language "required" fields require a value in all languages the page is active in. Currently multi-language required fields only require a value to be present in the default language. If you want to make them require all active languages, you can do so with a hook in /site/ready.php. I thought it was pretty useful so thought I'd share it here. Though maybe we'll have to add it as a feature. if($page->process == 'ProcessPageEdit') { $wire->addHookAfter('Inputfield(required=1,useLanguages=1)::processInput', function($event) { $inputfield = $event->object; $page = $inputfield->hasPage; if(!$page) return; foreach($event->wire()->languages as $language) { if($language->isDefault()) continue; if(!$page->get("status$language")) continue; // skip languages not active on page $value = $inputfield->get("value$language"); if(empty($value)) { $inputfield->error("Value required for language " . $language->get('title|name')); } } }); }