BitPoet

You can use https://processwire.com/modules/fieldtype-runtime-markup/ for that.

Can you try the latest release (0.2.0) and let me know if that fixed the issue?

Published to GitHub and pending approval in the module directory.

Here's a small module I wrote a few years ago and was asked to share in the module repo. TextformatterImgDataUri This Textformatter checks all images in the field's markup for images under a certain size and converts those from links to data URLs, i.e. it embeds the image data itself. This can be handy when you cache whole pages and want to cut down on the number of requests. Original post with the module code:

The default URL would be http://yourwebsite.com/processwire/. If it was changed to something else at installation time, and you have access to the database, just look in the table "pages" for the row with the id "2". The value in the "name" column there equals the path to the admin page.

I wonder if @ryan was ever contacted about this. I've tried to come up with a scenario where the URL injection mentioned in the CVE can become exploitable, but I'm having a hard time. When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality. That's why we have DANE, so the communication stays confidential even if you're routed through untrustworthy networks. I've sent a rejection request to MITRE with the following rationale:

Comments.php isn't loaded automatically. It's only included when FieldtypeComments is loaded. The quickest way to access all the auxiliary classes for this fieldtype is to load the module by calling $modules->get('FieldtypeComments');

When you use file_get_contents with the filename property, there won't be an extra http GET, as it will recognize the local path and use regular file system IO. It's only when the argument to file_get_contents starts with a protocol schema indicator (http(s):// etc.) that it uses the network wrapper.

It worked, but it's a pretty roundabout way to go about it, as the server performs a http GET for the SVG to retrieve its contents. But my bad, path is the wrong property. Try "filename" instead.

It should be $content->images->eq(0)->path since file_get_contents operates on the local file system.

I'm a bit of two minds on that, as there might be a use case for empty repeater items. Nevertheless, it wouldn't hurt to point this out in the API docs. Perhaps open an issue in processwire-requests?

Thanks for letting me know. I've created an issue and will take a look as soon as I find a quiet minute.

Another vote for a page multiselect, with a label format of "{parent.title}: {title}" and a sort of "parent.title, title" to make things easy to see in the backend. As for grouping by sections, this might perhaps help you:

That's an nginx error. You need to increase the client_max_body_size setting in nginx.conf.

I really don't think the problem is within the module code. Are there any messages when you do a Modules -> Refresh? Do you have another module active that accesses simpleSearch? Additional idea: a debug_backtrace from within the constructor might be able to shed some light on it if it's really a case of the module being blocked from uninstall because it's in use.