interrobang

Wow, how time flies. This post is already 9 years old! The old syntax from the last post is now obsolete. But today you can do much more. I just looked at the file along with claude.ai and here is a new version. Edit: I've added all the core hooks and status codes to this file. Could be useful sometimes. But there's more, here's a little module that adds a few things to an extra phpstorm.meta.php. After installing the module you get suggestions for $fields->get('') // suggests existing field names $templates->get('') // suggests existing template names $modules->get('') // suggests existing module names + all hooks defined in /site/modules/

My main wish for ProcessWire 4 would be a generally more modern admin theme (e.g. with Ajax-Save unpoly/htmx style) and that at least fields that are also used in the frontend (FormBuilder) no longer have a jQuery dependency. On the subject of jQuery, it would also be great if the updates announced last year could also be activated for live pages in the next major release.

@ryanwill the updated jQuery and jQuery UI versions become standard in the next master? In a customer's pentest, only the outdated jQuery Ui library was criticized, but I'd rather not not enable $config->debug = 'dev' on the live site. Especially since this would not help in this case either, as the old Jquery UI version is loaded on the login page despite debug = 'dev'.

I just took a look at the source code and saw that in WireFileTools::render() all variables are added to data() of the rendered TemplateFile. You can get an array of the variables in your rendered file by $this->data(). Docs for data(): https://processwire.com/api/ref/wire-data/data/

for interest I asked chatgpt if this can be done in a single selector. here is the answer:

I have more and more customers complaining that they can't upload webp images. I understand that webp is not the ideal master image format, but neither is jpeg. The webp browser support is also so good now that it would not be necessary to generate jpeg/png versions from webp.

I don't know a solution using TinyMCE but I used a textformatter in a similar case. I used TextformatterPstripper.

Hi @ryan. The updates from FormBuilderFile sound great and I could very well use that in my current project. Is there any news when you will release this? Will the field also support drag and drop uploads? That would be even better ?

Thank you both, unfortunatelly I can't test your suggestions right now, because the site is still using PW 3.0.150, which doesn't has these options. Upgrading PW to the latest dev broke my site, so I had to return to the old version for now. But I could solve my issue for now by quoting the value in the selector. After updating PW I will try your suggestions. pages()->get("template=$templateName, parent=$parent, title=\"$value\"");

For an import script I need to match existing pages by page title, but some of the titles include a pipe. I cannot find a selector to get these pages. I have no idea what else to try. $title = "test | test"; // Non of these selectors get my existing page: pages()->get("template=edition, parent=3997, title=" . sanitizer()->selectorValue($title)); pages()->get("template=edition, parent=3997, title=$title"); pages()->get([ 'template' => 'edition', 'parent' => 3997, 'title=' => sanitizer()->text($title), ]);

The more I think about it, I am sure we need a core solution. Even if we hook into every Inputfield::processInput method we know of, there will still be custom inputfields which we will miss. And if you populate your pages by api Inputfields are not even used and the hooks are never called. UTF8 normalization should be buried somewhere deep in the core: Probably every mysql query and all user input should be normalized automatically. Currently this is not possible with hooks alone as far as I know. Btw, I just found another lightweight library which provides a fallback function if normalizer_normalizer is not available: https://github.com/wikimedia/utfnormal

Beware, a textformatter doesn't help with your search issue, as the texts in mysql are still the same and not normalized.

To be honest, I just googled a bit, I probably don't understand more of this than you ? Btw, Wordpress is discussing this now for 6 years: https://core.trac.wordpress.org/ticket/30130 Also, I don't know if this normalizer function is usually available or not – there are polyfills, but then all gets complicated. I am not sure if just saving is enough or if the fields need some changes tracked. Better test before re-saving 1000s of pages.

Without much testing this hook works for me (in site/ready.php). But I think utf normalizing should be part of the core text sanitizer, so other texts (like image descriptions) are normalized too. function normalize_UTF_NFC($string) { if (function_exists('normalizer_normalize')) { if ( !normalizer_is_normalized($string)) { $string = normalizer_normalize($string); } } return $string; } $wire->addHookBefore('InputfieldTextarea::processInput, InputfieldText::processInput', function (HookEvent $event) { /** @var Inputfield $inputfield */ /** @var WireInputData $input */ /** @var Language $language */ $inputfield = $event->object; $input = $event->arguments(0); if ($this->languages && $this->languages->count > 1) { foreach ($this->languages as $language) { $input_var_name = $language->isDefault() ? $inputfield->name : "{$inputfield->name}__{$language->id}"; $input->set($input_var_name, normalize_UTF_NFC($input->$input_var_name)); } } else { $input_var_name = $inputfield->name; $input->set($input_var_name, normalize_UTF_NFC($input->$input_var_name)); } $event->arguments(0, $input); });

WTF?! Sorry, you are right, this is not useful.