Leaderboard

I'm probably a well-known nay-sayer around here already, but I'm still going to add my +1 to this discussion. I feel that (particularly when it comes to API design) one clean and consistent solution should be preferred, unless an alternative approach provides major benefits. Multiple options only tend to make things more fragmented and more difficult to grasp, and doubly so when you're a new user. As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added. Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x. There are, and always will be, features that should be added to the core (shameless plug: FiedltypeDecimal), but on the other hand alternatives without major benefits or major user base, and modules that may not be particularly often-used should, in my opinion, be stripped out. A module I've been working on recently has an "alias" feature (that isn't even that important to the module, to tell the truth), which was getting way out of hand. You could provide its arguments in five different formats, at least, which all required their own handler methods. I was working on this feature on Sunday (once again), and finally got fed up with it, stripped all those alternatives out and replaced them with one unified solution: callbacks. Sure, a bit of syntactic sugar might've been lost in the process, but I also got rid of probably 75% of the required code, and the documentation page is now actually readable. So, yeah – I know exactly what you're talking about ?

Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW ? I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure. I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance. I think this is a super important point!!!

I couldn't agree more - this was also my reaction with this latest version. I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off. Think back to: $pages("template=basic-page") Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method. I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes. I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.

+1 These magic functions are "hard" to decode when reading, at least it is a syntax no one is used to, so when people come across things like this they will just get confused. Generally speaking, it is great to have options but if more and more ways are implemented to do very same thing, then when one is looking at someone else's source code it will become harder and harder to decode it if it was written in "another dialect" of the ProcessWire API than one is used to. If this trend continues, reading ProcessWire source code will become harder than it should be.

It's been some time since I read the blog-post, but I really need to ask if we need the magic functions for the sanitizer, especially the grouped ones. They're hard to document, harder to be used for automated setups – where used sanitizers are aggregated by some coded means – compared to having them as parameters and I would say they're hardly simpler for manual usage over proper parameters. Personally I'd really vote for one clear way instead of having even more ways to do the same. For me there's also the reason that I find it way cleaner to work with data a.k.a. an array of sanitizer names vs. some magic naming, but that may just be me, but I think we really need to be aware of the backdraws of having to many options to do a thing in general.

I must agree as well with all those alternatives and multiple ways for the same thing.... should really stop. I lost track long time ago and 99.99% never use any of them and really don't care at all. It's utterly confusing and I completely don't understand the reason behind it. It makes it harder than it should be. So many things goes against it...

This week we take a closer look at the upcoming ProMailer module with a lot more details and screenshots. Plus an update on next steps with the new website and development schedule in the weeks ahead— https://processwire.com/blog/posts/promailer-preview/

Same feelings also. I think Teppo really said well how I felt also when read the latest post (and discussion about api examples). That kind of optimization is nice per project, but it is really confusing for a platform that we use to maintain and build hundreds of websites and applications with multiple developers. I'm all in for introducing breaking changes for 4.0. That would get rid of compiler also.

Hello all, I've just pushed a rather alpha version of this module to a new branch on github. The localisation branch adds a few new features that might be of interest. Update default countries list (in English) with names from the country-list project. Use LibLocalisation (if installed) to localise country select lists in the Inputfield. Allow localisation of config and inputfield select lists to the language of the user's browser. Switch to storing ISOs in uppercase, can still handle stored lowercase ISO codes. Unify country list loading code. Detect changes to input address when saving page. Add compatibility with FormBuilder. You'll need to do a manual update from the new branch to try this out. Backup first please. I'm pushing this now in its alpha-state, as I've had a few health problems recently and don't want to hold off making this available any longer.

There is a notice Regarding "Page List" input types... But the "specify only the parent" part of that is contradicted by the requirements for the core "allow new pages to be created from the field" option, so if you want that you would need to specify a template also. The template only relates to the new page that is added - it doesn't restrict the selectable pages for a Page List input type. If you're committed to the Page List input type and want to try workarounds for restricting the types of pages that can be selected you could look at hiding the "Select" button according to the class of page item in the inputfield. See the thread below for a different context but the same general idea:

Hope it's nothing too serious and you're on the mend.

TemplaneEngineMustache This module adds Mustache as engine to the TemplateEngineFactory. Project page in Github: https://github.com/blue-tomato/TemplateEngineMustache/ Module Page: https://modules.processwire.com/modules/template-engine-mustache/

Hey, I'm new and I created a simple module for tagging pages because I didn't found a module for it (sadly this is not a core feature). This module is licensed under the GPL3 and cames with absolutly no warranty at all. You should test the module before using it in production environments. Currently it's an alpha release. if you like the module or have ideas for improvements feel free to post a comment. Currently this fieldtype is only compatible with the Inputfield I've created to because I haven't found an Inputfield yet, that returns arrays from a single html input. Greetings Sebi2020 FieldtypeTags.zip.asc InputfieldTagify.zip InputfieldTagify.zip.asc FieldtypeTags.zip

I did a couple of years ago. It worked fine with three caveats: by default it caches all the pages and files it rewrites, so you have to be mindful of not running out of disk space. I'm not really comfortable letting an automated tool rewrite so much markup. I like to control the output. you can spend a lot of time tweaking and testing all the settings if you're not opting for the default ones. One particular problem I ran into is to exclude image rewrites from the admin. I believe it's possible to exclude directories, but I could not get it to work and it caused all sorts of unforeseen issues, such as images in Ckeditor fields. In the end, I removed it because it was not worth the hassle. I had already implemented on my own all the major optimizations it proposed to do automatically. Like you, I was mostly interested in the WebP conversion anyway. In case you're not aware, @horst is working on implementing WebP in PW.

I also agree with @LostKobrakai

Probably a permissions issue with the site/assets/files folder - check that the owner and perms match what you had in the staging setup.

If you mean you want to have different toolbars for different matrix types that use the same CKEditor field then changing field settings in template context is not going to be a solution because all matrix types within a Repeater Matrix field use the same template. And some hook that checks the matrix type is not going to be a solution either because there is only a single CKEditor configuration per CKEditor field that is sent to the ProcessWire.config JS object. So all instances of a CKEditor field on a page get the same config. I think the only way to have different CKEditor configs for different matrix types is to use a different CKEditor field for each matrix type that needs a custom toolbar. If you want to use those CKEditor fields in different templates besides the Repeater Matrix template then you can use template context for overrides.

Thanks for sharing your module. For more exposure, you might want to submit a PR to https://github.com/wanze/TemplateEngineFactory to update the README.md under "Implemented Engines" to include a link to your module?

@MrSnoozles You could use this one: https://processwire.com/api/ref/sanitizer/page-name-translate/ Define Umlaut-Translations (ä = ae, ö = oe, ü = ue) here and it's done: uehttp://domain.tld/processwire.admin/module/edit?name=InputfieldPageName&collapse_info=1 I drink Jägerbombs would result in i-drink-jaegerbombs. Or do I get you wrong on this?

Holy shit! That was fast. Thank you very much, Robin!

Just a follow up in case anyone is interested. On a separate project I needed to get into grouped OR selectors and I decided the easiest way is to create a standard array and simply do an implode on it, eg: $selector = []; $selector[] = 'user_types='.$u->user_type; $selector[] = 'ages=(ages.count='.$pages->count('template=age').'), ages=(ages='.$u->age).')'; $selector[] = 'sexes=(sexes.count='.$pages->count('template=sex').'), sexes=(sexes='.$u->sex.')'; $selector = implode(', ', $selector); This is back to how I used to do things and I feel like this is almost as clean as the selector array approach and so much more flexible.

FYI: Today, January 29, Firefox 65 is out with WebP support. The only major browser left with no WebP support is Safari.

Don't have a chance to look into this right now, but is anyone having issues on PHP 7.3? Saw a comment on the module listing from Alex Capes about it breaking. In the meantime, I've opened up an issue over at GitLab: https://gitlab.com/rockettpw/seo/jumplinks-one/issues/1 @Karinne Cyphers - only saw your note now, sorry about that! It's likely due to rules 16a/16b in htaccess. 16a limits the characters allowed in a URL, so hits would never even boot up ProcessWire. Try changing to 16b (and adding the tilde if it's not there). ——— Future Development / v2 I profusely apologise for how long it's taken to get things done for v2. As some of you know, my daily responsibilities have taken over, and committing time to open-source projects is not there as it once was. I'd love to be able to say that I can try find some time to get to it, but it's simply a promise I can't make or keep, unfortunately… The way I see it, there are two options on the table. First is to wait it out (I know, I know…) – I do have a project board on the old repo, so I know what stands where and what I'd envisioned for the module, and can pick things up where I left off last (phew, haven't touched jQuery in forever – that might be a challenge), when the time avails itself. Technically, I'm about half way there but there's still quite a bit of work to do in terms of frontend. Second option would be for someone to take over the project. It'd definitely need to be someone who can commit the time to its development, and develop in line with the way in which the module has been built so far (there's a decent amount of SoC going on, and the module is built up using packages such as Eloquent, FastRoute, etc.). Alternatively, as a third option, we could take a multi-contributor approach. So, if anyone is interested, feel free to send me a DM and we can chat about it.

Admin note: since this is clearly not a support thread for a module, I'm moving the whole thread to the General Support area of the forum. Please note that Modules / Plugins is only intended for dedicated module support threads. Thanks!

Done ? $css = '.PageListStatusUnpublished .PageListActionSelect, '; $css .= '.PageListStatusHidden .PageListActionSelect, '; $css .= '.PageListID7, '; // Hides the Trash page

I appear to have it figured out, the registration form does not like Page Reference fields. It will accept the registration and send the confirmation code, however will always fail if the original registration form contained a page reference. Shame as my site relies on it quite heavily for the initial registration, so I will look into whether there's a workaround.

Hello, I am not that experienced with hooks and was hoping if somebody could me with this task: I have a InputfieldFile in wich a single generated file will be added after checking a checkbox in the back-end and saving the page. This happens in the saveReady-hook of a page with a specific template inside a ready.php: <?php $this->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); if ($page->template->name === "example") { if ($page->checkboxField) { $page->fileField->add($generatedFile); } } }); Now if a new file should be generated and there is already a file in this InputfieldFile, I would like to remove the previous file and replace it with the new one: <?php if (count($page->fileField)) { $page->fileField->removeAll(); } That works well so far. My problem is, that I want to add the new file with the same name filename.pdf. But when I remove the previous file and add the new file inside the same saveReady-hook, the previous file still exists until the page is saved and the name of the new file will be added a filename-1.pdf, because ProcessWire makes the filename unique when a file with the same name exists. My question is: Is there a hook or way to remove the previous file before the new file will be added to keep the same filename? I tried to unlink the previous file, but then the InputfieldFile doesn't always gets updated correctly and has one empty file and the new file. ? Regards, Andreas

How about renaming the old file before deleting it and adding the new one with the same name?

$data = array_merge($data, self::$configDefaults); I think should be: $data = array_merge(self::$configDefaults, $data); Otherwise it will overwrite the saved data with the defaults.