BitPoet

It's not likely to change without the developer consciously doing so, but $config->http404PageID is much more expressive than "27" anyway.

The symptoms all point towards ProcessWireUpgrade. It does have a login hook for checking available updates, after all. I'd first check outgoing HTTP(S) connections and, if those work and are performant, possible DNS lookup hickups on the server. The message about SchedulePages is normal, as it's not listed in the module repository.

It's the page of the hosting company where the (not linked) PW driven site runs. Strato is one of the oldest and biggest European hosters.

Ah, sorry, I missed a hint in your screenshot. The module won't do anything applied to the file descriptions. You need to add the Textformatter to the textarea field that uses the images.

Hi @Leftfield, I'm not sure what the reason could be, so I've added logging to the dev branch of the module. You can download it here. With debug mode on, it logs to "imgdatauri".

Three possible solutions: Add a whitespace after the closing PHP tag Add an empty line after the closing PHP tag Output a real line break. In your example, you're putting a literal \n in the source, outside of PHP. Use <?= "\n" ?> instead.

You need to expand the parent select and navigate to the assigned parent. When you hover on that, you should see the "unselect" button.

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.

After a quick glance, I don't think so. Have you tried writing into the PW log from ___install and ___uninstall? This should at least tell you whether uninstall+install happen. In the later case, you should also see the page request that triggers the re-installation. Just to make sure: you have $config->debug enabled so you don't miss any warnings, right?

You'll probably find either the full code or at least an include directive or module invocation in the page's PHP template file in site/templates. It's usually home.php for the start page, but if this differs from a default installation, you can look the name up in the template's configuration in the backend on the Files tab. If that is empty, the template file is named the same as the backend template.

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.