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.

I think this would be a useful addition to the Sanitizer class. Something like this should do it: $dotfloat = rtrim(number_format($number,100,'.',''), '.0');

Perfect! Thank you! I have merged your PR.

Thank you! This looks good to me! If you make a PR I will merge and release a new version.

So far I haven't found a fully working regex. My test case is this. You you or anybody else finds a solution a PR is more than welcome. $test = "<h2>Fully URLs</h2>"; $test .= "http://domain.com <br>"; $test .= "http://domain.com/ <br>"; $test .= "http://domain.com/dir <br>"; $test .= "(http://domain.com/dir) <br>"; $test .= "http://domain.com/dir/ <br>"; $test .= "http://domain.com/dir/?a=1 <br>"; $test .= "<h2>www. domains</h2>"; $test .= "www.domain.com <br>"; $test .= "www.domain.com/ <br>"; $test .= "www.domain.com/dir <br>"; $test .= "www.domain.com/dir/ <br>"; $test .= "www.domain.com/dir/?a=1 <br>"; $test .= "<h2>flourishlib Examples</h2>"; $test .= "Example 1: www.example.com.<br>"; $test .= "Example 2: https://example.com.<br>"; $test .= "Example 3: john@example.com.<br>"; $test .= "Example 4: ftp://john:password@example.com.<br>"; $test .= "Example 5: www.example.co.uk.<br>"; $test .= "Example 6: john@example.co.uk.<br>"; $test .= 'Example 7: <a href="http://example.com">http://example.com</a>.'; wireModules("TextformatterMakeLinks")->format($test); echo $test;

Unfortunately, I'm not very good with regex, but I still tried to solve the problem. Can you please give it a try if the result is better if you remove the \b in lines 52 and 53? Has anyone here with more regex experience an idea what problems could arise from this change?

It looks like Safari has a problem with the ui-helper-clearfix class. If you remove it the layout looks ok.

You can add custom classes to the body of the ckeditor iframe. In the field settings (Input Tab) insert this in the "Custom Config Options" field: bodyClass: Inputfield_textarea1 If you need more flexibility you can also hook create a hook in your /sites/init.php to add multiple classes to all of your ckeditor fields: wire()->addHookBefore('Field(inputfieldClass=InputfieldCKEditor)::getInputfield', function(HookEvent $event) { // do not show modified data on Field edit page if ($this->wire('process') != 'ProcessPageEdit') return; $field = $event->object; $page = $this->pages->get($this->input->get->id); $customOptions = $field->customOptions; $customOptions .= "\nbodyClass: template-{$page->template} page-{$page->id} field-{$field->name}"; $field->customOptions = $customOptions; });

Hi Nik, thanks, I am well Honestly I have not used my module myself for a long time, and I still have not looked into what has to be done to migrate this module to PW3 and its new image field. I plan to release a new version eventually, but can't say how long it will take. But seeing somebody still uses it at least motivates me to test it myself in PW3. Sorry, that I cant give you a more satisfying answer. I will post back here after testing.

Thanks for sharing, looks Good. Some nice memories are coming back. Chrom Records was one of my favorite labels back in the 90ies. But I am feeling old now..

Yes, should be possible now, see this blog post for more infos: https://processwire.com/blog/posts/language-access-control-and-more-special-permissions/