Leaderboard

@FireWire This plugin has saved me so much time with a site I'm building for a client. Is there anywhere I can sponsor you or a way to send a few bucks your way?

Fluency has hit v1.0.1 and has been submitted to the modules directory, should be available pending review/approval. Really appreciate everyone's feedback and input to help on this project. All new features from the development branch have been added to the latest release. This is a recommended upgrade for everyone that also fixes a couple of issues. https://github.com/SkyLundy/Fluency/releases/latest If you there are any bugs found during usage, please file an issue on Github where you'll get credit for your help, or consider creating a pull request with a fix! @ryangorley That is most excellent to hear and I am very glad it helped! I've re-added a donation box on the module config page in the latest release, very appreciative of your support!

Personally I don’t really see how setting something like this would entice the community to contribute more than making a pull request to a module’s repository to share your translation in your language (https://processwire.com/blog/posts/pw-3.0.181-hello/). I’m mostly working on english websites (or for people who are ok with an english admin) but if one day I’m required to use french and I need to translate some modules then I’d happily share my work this way. And if you need a shortcut, you can always give a shot at @FireWire ’s excellent Fluency translation module ?

@David Karich ProDrafts doesn't have versioning per se, it just maintains a draft version. So the version support will be something different, though the plan is that ProDrafts will be able to eventually use it for maintaining its draft versions. As for how the versioning works, it's very simple in that you have API methods to add, get, save, and delete versions of a page. That's the extent of it. While technically you could code a hook to make it save a new version on every page save, I don't think it would be practical, as a version is an entire copy of a page, including its files. Most likely one would use it to create a version intentionally, and perhaps work on it independently of the live version of the page. Or maybe they would use it to create a restorable snapshot or backup of a page's current state, before making some other changes. I think there are a lot of possibilities for how someone might use it, but for now I'm just focused on its API and making it all work reliably across different fieldtypes. @MrSnoozles A media manager is something I've not needed here, and I get off track and mess things up when I start developing stuff tools I don't have a use for in my own projects. Nearly everything that's in ProcessWire's core is stuff that I develop and maintain because I use it in my client work. When I need to share file or image assets across multiple pages I build a page or group of pages for the purpose, and that is ideal for my projects. A big part of the reason why PW as a framework is so modular and hookable is so that there is always the opportunity extend it in ways that are useful for your own projects. For example, @kongondo built what looks to be a really cool media manager for ProcessWire, though I don't have experience with it beyond reading about it and watching the videos. As for translations of the admin, PW's admin is already 100% translatable, so if you are seeing a mixture of English and another language, then that means that the language pack you have installed is missing translations. But that's something you'd need to ask the author of the language pack about. You can also always submit a pull request to the translation author's language pack, or create your own. PW makes this all very simple. Multisite is another example of a module that I just have not yet had a need surface for in my own work. Though I'm interested in it, so always looking for the opportunity. I'd have to come up with a case where I would use it and find it worthwhile. Otherwise I don't think I could do as a good job of a job as someone that is actively using it. I think the existing multi-site module(s) were built by someone (Soma, Apeisa?) that was using them in their projects. Worth mentioning too that PW will happily serve multi-site already, so long as you add all the hostnames to $config->httpHosts and use conditionals like if($config->httpHost === 'host.domain.com') to decide what content to serve. What I find useful in my work here is multi-instance, being able to boot other sites when and where needed, like we do on this site, where the modules directory actually comes from a separate ProcessWire installation, despite being delivered by the main site.

As far as I understand, what Ryan suggests is putting if($config->httpHost === 'host.domain.com') and such into template files. Instead of putting if's into template files for deciding what to render based on the current host, I do something like (and more...): if (file_exists($hostTemplatePath)) $templates->get($templateName)->filename = $hostTemplatePath; in init.php to decide what file to use as a template in the first place. In the very same loop where I set the actual template, I also do if (class_exists($namespace . $className)) call_user_func_array("{$namespace}{$className}::initiate", []); so my page classes can get initiated upon their request.

I didn't know this! Where does this code go, ready.php or init.php? Or in config.php?

To me it looks like renderRepeaterLabel is also called for a dummy repeater item (see the call with a NullPage here). That one doesn't have a page associated yet, as it hasn't been saved. It's just used to render the form for adding a new one. So the calls for the existing items succeed, but that last one fails and throws the error. This can be cured easily by adding a check for $page in the hook: // Get values of arguments sent to hook (if needed) $label = $event->arguments(0); $cnt = $event->arguments(1); $page = $event->arguments(2); // Only execute the hook for actual repeater items, // not for blank placeholders if($page instanceof NullPage) return; // Your code here, perhaps modifying the return value // just a simple test: $return = "LABEL " . $page->getForPage()->template(); In a short test, this worked like expected.

Hey Jens this works great, thank you! {* page background image *} <picture id="page-bg"> <source media="(min-width: 1400px)" srcset="{$home->backgroundImageUrl(1920)}"> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAXNSR0IArs4c6QAAAAtJREFUGFdjYAACAAAFAAGq1chRAAAAAElFTkSuQmCC" alt="Page Background"> </picture> And the css: body, html { height: 100%; width: 100%; } #page-bg img { position: fixed; left: 0; top: 0; width: 100%; height: 100%; object-fit: cover; z-index: -1; } I'm using a transparent pixel data-url by default (taken from https://shoonia.github.io/1x1/#00000000).

@teppo I just wanted to let you know this plugin saved my life today. Thank you for building it! I just became a sponsor :)

I'm not 100% happy with that wording. No offense, just want to be clear on that. It's not that I don't want to support RepeaterMatrix to push sales of RockPageBuilder. I'm just not using RepeaterMatrix any more because RockPageBuilder is far better for what I use it and it integrates well with RockMigrations. RockMigrations is a module containing thousands of hours of work that you get for free and that does not pay any bills for me. I just can't put any (more) unpaid work into it unless I need the features for my own work. But I'm happy to support RepeaterMatrix and any other pro field of Ryan if people provide PRs even though that might mean less sales for RockPageBuilder. I'd be even more happy if @MarkE had a look at RockMigrations and used it as common base so that we can work together on an api that does all the heavy lifting - independent from wether it is used by RockMigrations or MarkE's GUI. And even more happy, of course, if we had a migrations API in the core...

Hey, I see your idea like having static properties, instances are pages and static properties are on template. I don't know it this is a good idea, on my side, since I discovered custom page classes I declare this on UserPage for example: public function getAvatar(): string { return $this->avatar ?: wire()->config->urls->templates . 'img/default-avatar.png'; } I could also have the default avatar on a generic configuration page.

@ryan Good points. The slim core and the enormous flexibility is why so many love ProcessWire and trust you with your decisions. Still I want to comment on one point: I know it is simple, but the reality is that in client projects it often still ends up being a mix of <language> and English, because not all modules provide translations (the community seldom submits pull requests for languages) and there is no time to translate everything. I think that ProcessWire is lacking in this area has to do with you rarely needing it in another language but English. My idea how this could be improved would involve three relative simple steps: 1. Set up a community translation tool, like Weblate (https://weblate.org/), where people that want to contribute can easily see which translations are still missing. Weblate is really good feature-wise, but the interface for adding translations could be simpler, so another tool might fit better. 2. Write a crawler that goes through all the uploaded modules and core files, extract the translatable phrases and upload those packages to Weblate 3. Write a ProcessWire module that maps the languages defined in ProcessWire with country codes, then automatically downloads the matching translation files from Weblate whenever a module is added or updated In general: would that something you would consider useful? If so I could try implementing a POC when I find the time.

Hey @ryan, I'm so excited about the feature. The two big things I think ProcessWire is missing are versioning and a lack of global asset management. ProDrafts was a good approach so far, but had limitations. Can you perhaps briefly explain how the versioning module works? ProDraft had the approach that everything I save is saved in a draft until I publish. Is this also the approach here, that every time I save a page a new version of the last state before saving is created or do I have to create a new version myself beforehand, in which I work, revise a draft and then "restore" it when I'm done as a form of "fake" publishing?

New version pushed to the dev branch with fixes for InputfieldTable and FieldsetPage elements. Please let me know if this solves the issue @monollonom https://github.com/SkyLundy/Fluency/tree/development Thanks for everyone's patience. Work has been crazy (and a long-ago planned vacation didn't help). Thanks!

@monollonom Big help! This problem was caused by my replacing <button> elements with <a> tags for the translate triggers under fields. The fact that my links don't have an href="#" was an oversight because I always add those, but either way that would have caused an issue. I did that so that links could match any custom styles that were done to the admin, which was something that isn't possible if I used a <button> element. I could revert to using a button, but it would be a welcome fix the JS could be patched with more specificity since the # href is very common. In any case, open to input from @ryan In the meantime you can use the previous release as the only changes after this were for cosmetic reasons. Tables will work here: https://github.com/SkyLundy/Fluency/releases/tag/v0.9.0b I've identified the culprit, my code wasn't accounting for hidden template elements that InputfieldTable uses to create new items. I haven't nested a table field in a repeater before, so I'd never have seen this coming. Working on a fix. Thanks for the bug report and the assistance!

I also have a 100% working spam protection technique I always use (and nothing more). See it working here: https://www.szepelet.com/about-us/contact-us/ Human Detection is a pure PHP random number, rendered by :after {content: attr(data-attr);} and the css class is deliberately not named with a related term, just to make it more obscure. No bots have been smart enough to crack it so far.