Leaderboard

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!

@Krit65 Just in case, do you know the common way to translate modules in PW admin? Menu Setup > Languages > Your Language > Find files to translate > Select LoginRegister file > Translate what you need. If it's needed to make translations editable from frontend, I would use PW translator to save phrases. I never used this API, I did a test but I don't know why it's breaking my existing translation file (it removes all previous translations and leaves 'file' and 'textDomain' empty): $language = wire()->languages->getLanguage("english"); /** @var LanguageTranslator $translator */ $translator = wire(new LanguageTranslator($language)); $textDomain = '/site/templates/account-edition.php'; // Domain for LoginRegister should be '/site/modules/LoginRegister/LoginRegister.module' $translator->loadTextdomain($textDomain); $translator->setTranslation($textDomain, 'Logout', 'My translation'); $translator->saveTextdomain($textDomain); // Breaking my existing translation file Another way, closer from what you're trying to do, is to hook one of the LoginRegister methods that build forms and change text values on the fly using your term-translation page, so in ready.php (code not tested): wire()->addHookAfter('LoginRegister::buildLoginForm', function (HookEvent $event) { $terms = $pages->get('template=term-translation'); /** @var InputfieldForm $form */ $form = $event->arguments(0); $myField = $form->getChildByName('Email'); $myField->set('label', $terms->myTranslationField); }); Take care that there are several hookable methods that build a form in this module, ___buildLoginForm, ___buildRegisterForm... (check source code).

This works for my needs. Did not know PW had this kind of translation function, was only using the multi-language fields. Thank you everyone!

Solved it for now. If it happened once, it could happen again. Or maybe not. Sometimes it's not worth wondering why things happen... Thanks!

Hey @Klenkes sorry for the trouble. Never seen this in my 3 years of using the module. I'd unhide the block via API in the tracy console and see if the error occurs a second time on another block at some time. $pages->get(#your-block-id#)->removeStatus('hidden')->save();

Hi @Krit65 I don't use LoginRegister module but if you want to translate a string in your template file. You can try: <?php echo __("Your String"); ?> And then find the file in the backend translate tool (setup --> Languages --> Your Language --> Find file to translate --> find your template file) to transfer the string to other language. Gideon

Happy to announce the launch of the completely rebuilt San Francisco Contemporary Music Players website, using ProcessWire. https://sfcmp.org/ The previous website was a hornet's nest of disorganized content, dozens of 3rd party plugins, duct taped together within WordPress... difficult to use, time consuming and confusing to manage. And didn't look so good either. Lot of fun to rebuild this, though took several months. YOOtheme Pro and UiKit were a dream for me to work with, just love those. Made it so possible to create all of the custom sections, widgets, sliders, cards, mega menus, and so on. Don't consider myself a front-end focused web dev, so have a deep appreciation for the time, care and effort that Yoo has put into both UiKit and YOOtheme Pro. Almost no additonal CSS was needed to be written for this; the stock UiKit classes and attributes make it possible to just build things in HTML and not have to fiddle with CSS. Ryan's commercial modules played a major role in the build. ProFields, ListerPro, ProCache, and FormBuilder were all important. FormBuilder+Stripe allowed me to confidently migrate their need for a stripe checkout from some WP plugin to the clean and simple setup now using FB. ( https://sfcmp.org/donate/print-for-sale-dirge-by-hung-liu/ ) Some libraries also were of great use and value, namely PLYR for audio, and tabulator for some table display type of stuff. As always, the API was a dream to work with, many custom import scripts were created along the way to import legacy Press, Albums, Repertoire works, Program Booklets library, Players etc.. The image API is doing wonders with SRC sets, and webp images. The PW documentation site was a daily companion. This forum likewise was always a most valuable and enjoyable resource to search and rely on for solving the occasional conundrum. There is such a wealth of info here that i never found it necessary to post a question. Lastly, to underscore just how unparalleled, flexible and user-friendly the PW backend is, we had the backend training session a couple of weeks after the site was launched, and within 30 minutes, the person who will be managing the content was able to know how to create and manage concerts, blog posts, albums, press articles and more.

PS: Last chance to get RockPageBuilder with huge discounts of up to -30% until today 23:59:59 CET (Vienna) ?

I've been using Apache forever... never even touched nginx. Today I felt like giving Caddy a try and it feels nice. I developed what I believe is a much more improved Caddyfile that also supports ProCache and stronger blocking of files (returns a 403 like PW's htaccess file, instead of a 404 which is what /denyaccess seems to do). I added a way to also put the site in maintenance mode (meaning all requests get rewritten to /maintenance.php) if /maintenance.php exists (which is now part of my deployment process). Hopefully I can share the results in a week.

Hi @rst For some reason in PHP8+, the coordinate values default to the empty string. You can fix the module code and hard-code their values to float. Until @ryan fixes it. if( ((string) round($lat, $precision)) != ((string) round((float)$this->defaultLat, $precision)) || ((string) round($lng, $precision)) != ((string) round((float)$this->defaultLng, $precision))) { I've requested changes to the https://github.com/ryancramerdesign/FieldtypeMapMarker

can you just foreach the images and output each slide? otherwise $page->images->eq($n);

Have a look at eq(n) - if you want to target a particular image....this is in the cheat sheet ....but maybe does not answer you question...but the usual suspects are about...so your question will be answered ....