Leaderboard

This week the most useful core update is likely the refactored column width slider in the template editor, located Setup > Templates > [your template] > Basics > Fields. You may or may not already know that clicking, holding and dragging the percent indicator on the right side of each field adjusts the column width. With the term “column width”, I mean the width of the field in the page editor, for when you want to have multiple fields in different columns on the same row. It’s a convenient and time saving shortcut. But it was also a little tricky to use, as it allowed anything between 10% and 100% in 1% increments, and it was a little finicky trying to get the percentages just right sometimes. It’s something that’s been bugging me for awhile, and @Pete messaged me on Slack this week and mentioned it. He suggested making it operate in 5% increments rather than 1% increments. He also suggested making a double click of the percent indicator open up the dedicated column width range slider that allows for more precise adjustments. I thought those were good suggestions, so I went ahead and implemented them this week. In addition to now using 5% increments, it also supports the commonly used 33%, 34% and 66% width values as well. But if you happen to already have some field that is using a less common width, like 27% or 72%, etc., then it reverts back to 1% increments for the same behavior as before. Of course, you can also use the 1% increments by double clicking the percent indicator to open the dedicated column width range slider. Thanks Pete for the suggestions, I think it all works better now. I’ll be applying the same changes to FormBuilder’s equivalent of this feature as well. This week I’ve also been working on the new CustomFields modules (FieldtypeCustom and InputfieldCustom). Most recently I’ve been working on adding support for multi-language fields, as well as adding more examples and tools to make it really easy to use and configure. I may have it ready as soon as next week or the following week. The PageAutosave module is also getting a new version soon. I’ve been focused on the LivePreview feature of it and making a version of it that doesn’t depend on auto-save. The alternative LivePreview option (which we’ll just call “Preview”) will work anywhere because it has no field limitations. It simply updates the preview window whenever you save the page. While that’s not as fancy as live preview as-you-type, it’s still very helpful, while being reliable in any situation. It’s reliable and portable enough that I may end up putting the feature in the core, but will be testing it out in the next version of the PageAutosave module first. Have a great weekend!

@BrendonKoz Thanks for your reponse, yes this would absolutely be the reasonable solution in most cases, but the structure I have here is weird and it seemed relevant to have 2 separate fields at the time I created it. Maybe in hindsight I still should have gone for this solution, but it's just a personal project so I can't be bothered to change everything now, I'll have it learned for next time :^) @dynweb Thank you very much this is what I was looking for. Here's what I ended up doing, it works perfectly if ($cover_image) { $images = $images->prepend($item->cover_image); } if ($cover_video) { $videos = $videos->prepend($item->cover_video); }

After doing a test and seeing your gif could it be because you’re also slightly moving the mouse on the Y-axis? Maybe the slider should stick to one axis once you passed a certain threshold?

Alternatively, you can just use different logic on your interactive procedure. I do something similar to this with just a single field, where the first image (manually sorted) in an images (Multiple Images field) is used as the primary/cover photo. All of the rest are placed into the standard gallery. The API makes that easy with the WireArray class methods of first() (only retrieve the first when using the "cover photo" as a portfolio thumbnail) and shift() (if you wanted to separate the first/cover photo from the rest of the group in a template). Images are files, so you can use the same logic for file fields. If you don't want to modify your template(s) and would prefer to keep your logic flow intact, what dynweb mentions should work too. 🙂

Pageimages::add() should do what you are looking for.

@poljpocket You are absolutely correct. After configuring the homepage URLs like you suggested. Language translation is working fine. Thanks for the help. Thank you all.

A quick code read gives me this problem. I think you are right, this is a bug! Line 443 of WireTextTools must be the culprit: https://github.com/processwire/processwire/blob/3cc76cc886a49313b4bfb9a1a904bd88d11b7cb7/wire/core/WireTextTools.php#L443 while(strpos($str, "$r$r") !== false) { ... } PHP 8 strpos will always return 0 (zero) for an empty string as needle (which is the case for $r = ''). And thus we get an endless loop. PHP 7 strpos will trigger a warning because the needle is an empty string. Nevertheless, the result is false and the loop breaks. I think your code was generating these on PHP7 but didn't fail and thus, you didn't care about it. This behaviour matches the updated strpos function in PHP 8, see Changelog here: https://www.php.net/manual/en/function.strpos.php @Ferdi Derksen this is your finding. Would you like to post the issue? I can produce a PR for it afterwards if @ryan would like me to. The fix is easy enough.. while($r && strpos($str, "$r$r") !== false) { ... }

Sorry for OT, but this isn't true. Maybe it is because the documentation lacks any mention of it, but years ago, @ryan fixed that problem in this commit: Add support for retaining abandoned translations in `__('text')` call… · processwire/processwire@34cc4e9 (github.com) You can pass an array with all alternates (as he calls them) to retain the old translations, e.g.: <?php namespace ProcessWire; $stillWorkingForOldTranslation = __(['new_translation_value', 'old_translation_value']); Like this, you can update your strings and still carry over the old translations to apply to both the old and new versions of the strings. I have to be honest, I believe this isn't generally known. I only know this because I stumbled upon this whilst reading the source code of the ProcessWire Core. This strategy also works for _x() and _n() functions, and also in modules with $this->__(), ->_x() and ->_n().

Hello @SIERRA, in theory the translated string translation should be display, when visiting the translated page. In your case "Welcome to our website" should be translated when visiting the "/test-language-tn/". It is not necessary to manually switch the user language in the template file or to save it to a user, unless you want to build a different translations solution. In your screenshot I cannot find the string translation "Welcome to our website". Can you please make a screenshot with the string? Personally I don't use the core string translations anymore, instead I am using the ProField Functional Fields: https://processwire.com/blog/posts/functional-fields/ Because if you change the core string translation, all translations get lost and core string translations are not so nice for editors to edit. Regards, Andreas

ProcessWire decides the language displayed based on the URL. I am assuming you didn't configure different root URLs for your languages and thus, ProcessWire doesn't know which language to display and will revert to the default language. A quick test shows this exact behaviour. If you configure your homepage URLs into something like this, your languages will work:

@BitPoet Great module! Just saved me time and was exactly what I was looking for. The one thing I ran into is that if a child page with a single-template child restriction is set to hidden then it's still possible to select that template when creating a new page. My use case is a settings page that is published but hidden. I tested the changes made in this Github PR and it resolves the issue. Thanks again for the module!

It's been two weeks now since I switched to Cursor Pro full-time and I have to say... "Thank you, Supermaven. It was an awesome time. Fare well, enjoy your life now. Was a pleasure to meet you. 😊" I'm there, in a different way as planned, yet... I reached that point. And I am super happy. Best part... Docs included. Anyone else of you moved completely or at all to Cursor?

Hey, @kuba2! The issue is not PW itself, but rather a 3rd party module - MarkupSEO. It has not been updated for awhile (8 years))) You should: Solve the issues in this module yourself (the author is not around anymore AFAIK). Use a more modern SEO module like this one. Remove all the SEO modules and cope with SEO needs with regular fields and creativity. Anyway, you need to be able to change PHP versions back and forth and see what other modules might need an update.

That rule was in conflict with native admin urls so I had to change it and use this way: <IfModule mod_rewrite.c> RewriteEngine On RedirectMatch 302 ^(.*)/(en|it|pt)$ /$1/$2/?lang=$2 # ... Hope this help someone else in the near future.