BillH

This doesn't help you much, but I can confirm that adding fields as you describe works fine for me. Is it possible that there's some problem with searching in the additional fields – for example, some hidden formatting that's interfering with the search? It might be worth setting things up to search in one of those fields only (and not in the title field) to see what happens. And have you checked that the default search operators (as defined in the module settings) are suitable?

Hi, and welcome to the forums! Assuming you are using the Uikit admin theme (which you probably are), go to Modules > Core > AdminThemeUikit. Then in the Masthead + Navigation section, under User avatar select Image field: user_photo.

You might find an answer in this discussion, which covers all the possibilities I could think of - and a couple more!

My first guess would be that there is actually something in the job_titel field for those two entries that is causing the sorting error. Have you looked directly into the database fields themselves – using something like phpMyAdmin or Adminer (hosting companies often provide a tool in Control Panel or the like)? You'll find it's quite easy to navigate the PW database once you take a look at it. You may see something that you're not seeing using other methods.

I don't know the cause of the trouble, though my first guess would be a timeout somewhere. Have you tried repeating the process with images of about the same size, and does the same error occur? And if it does, have you tried with smaller images? Have you checked the error logs (Setup > Logs)?

I think that sorting by path simply isn't available using selectors. What are you trying to achieve? If it's to get the results into the same order as in the admin (which of course it may not be!), you probably want "sort=sort" (see "How to force pages to sort by their admin order with $pages->find()" on https://processwire.com/docs/selectors/).

I wouldn't think there'd be an issue with different usernames - though I could be wrong. An error with accessing the database does sound like the right sort of thing, but I'd expect the consequences to be more wide-ranging and the errors to recur. My guess is that these errors were caused by something else. Have you turned on debugging in config.php ($config->debug=true;) and is anything interesting returned? And are you using the same version of PHP on both local and live servers?

Have you tried checking the logs? If not, I'd suggest looking at Setup > Logs (or going directly to the log files at Site > Assets > Logs). If you can't identify anything, it might be worth posting an excerpt here.

Take a look at the "Formatted value" section of the "Details" tab for your Icon field. You can see that the data can be returned in various forms. So, depending on your settings and the number of images, $icon->modified could return the modified value from an image – but it's not a modified value for the field itself. If you want to set a value for modified, you need to set it for a particular image. Note that if in your code you set output formatting to off (https://cheatsheet.processwire.com/page/built-in-methods-reference/page-setoutputformatting-true-false/) you will always get an array. And it will avoid trouble when setting values. So in your code I'd suggest: ... foreach($pp as $p) { $p->of(false); ...

Your code is trying to set a modified time for the field, but you need to set it for each file contained in the field. So replace: $p->icon->set("modified",time()); with foreach($p->icon as $icon) { $icon->set("modified", time()); }

Have you tried following the instructions at https://processwire.com/modules/process-menu-builder/how-to-use-menu-builder/#how-to-use-menu-builder? They're quite a long way down the page, so perhaps you missed them. You'll also find them in the README.md file of the module. And you might want to look at the support thread in the forums:

Welcome to the forums! If you don't want to use inline CSS, would you be happy with including the CSS in the template file's head section? Something along the lines of: <style>.hero{background: url(<?=$page->hero_image->url?>) no-repeat;}</style> Or you could build the style line in a separate PHP file and include the file. I may be missing something, but I'm not sure that placing the PHP getting the image URL in a linked CSS file would be more scalable or cleaner than placing it in an included PHP file. And you could avoid having to wrestle with htaccess!

Thanks @Robin S, useful to know.

There's a really useful page https://stackoverflow.com/tags/timezone/info - though it'll make you realise you're opening something of a can of worms! I think, but I'm definitely not sure, that PHP uses the IANA/Olson Time Zone Database (linked on the above page). However, even if it does, I don't know how up to date PHPs list of time zones is. The Geolite2 database from MaxMind, at https://dev.maxmind.com/geoip/geoip2/geolite2/, is free and gives IANA time zone codes. This is another option: https://www.ip2location.com/free/olson-timezone. And there may well be quite a few other such sources out there. I don't know of any ready-made tool, but that doesn't mean there isn't one!

Pleased it worked ? Whether you set output formatting inside or outside the loop shouldn't affect the issue – though inside would waste a few processor cycles! I've done some tests, and the issue is a result of page->save() not working for custom image fields. Saving the image field (inside or outside the loop) is necessary to save the content of the image custom fields. Saving the page (inside or outside the loop) does nothing for the image custom fields. It seems to me that saving the page should work as it does with other fields, and I have reported this as an issue https://github.com/processwire/processwire-issues/issues/1334 However, there may be a good reason for it behaving as it does, and it has been pointed out on the issue page that the Table Profield behaves in the same way.

I did this a few weeks ago and I got it to work. I seem to remember I had a certain amount of trouble saving the record, but I can't remember what exactly. However, the following code worked (I've simplified getting the text to add to the image fields). Note that I've done something a bit weird and saved both the field and then the page. This might have been an error (I was running a one-off process), or I might have found it was necessary for some reason I don't understand. It may just be that saving the field is what does the trick. Also, for reasons of my own, I used $record as a page variable, but I don't see why this would matter. Otherwise, I can't see any difference between this and your code. foreach($selectedRecords as $record) { if(count($record->article_images)) { $record->of(false); foreach($record->article_images as $image) { $image->photo_caption = "Some caption text"; $image->photo_credit = "Some credit text"; // First save $record->save('article_images'); } // Second save! $record->save(); } } Hope this helps, and I'd be interested if you find this works and can figure out what actually fixes the problem.

Following on from what @teppo suggests, note that it's quite straightforward to write a script to import images into image fields on pages. There's lots of help on the forums for doing this (as a starting point, https://www.google.com/search?as_q=import+images&as_sitesearch=processwire.com). So, if you have a way of getting the image URLs into text fields (which it seems you have), you could write a script to run over the pages, loading the image(s) from the URL(s).

I don't know of a way to do this with the template settings. However, if you want to the date to appear for only a particular template, you could add a check like this: wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); // Check template if($page->template->name == 'relevant-template') { $modifiedFormatted = date("j.n.Y", $page->modified); $event->return = $event->return . ' ' . $modifiedFormatted; } });

Welcome to the PW forums! The first thing I'd suggest, looking at the second line of the backtrace, is setting protectCSRF to false in config.php: $config->protectCSRF=false; If that doesn't get you in, take a look at https://processwire.com/docs/start/install/troubleshooting/ And then you may need to go back to working through posts: https://www.google.com/search?q="This+request+was+aborted+because+it+appears+to+be+forged"+site%3Aprocesswire.com%2Ftalk This one is a useful starting point:

One approach would be to use a hook in ready.php, adapting the method described in this post: You'd probably end up with something like this (not tested): wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $modifiedFormatted = date("j.n.Y", $page->modified); $event->return = $event->return . ' ' . $modifiedFormatted; });

When you add data to a field, the data is not saved to the database. This is the same as when you type the data into the CMS form (before you hit the save button). As you know, after changing the content of a field you can save either the whole record or just that field: $page->save(); // Or just the field $page->save("integer_field"); But the hook is after Pages::saveReady, so it always runs just before the page is saved to the database – for example, the hook will run after a user hits the Save button but before data is saved to the database. So if you use $page->save(), the data will be saved twice, which is unnecessary – though extra safe!

It might also be a good idea or turn output formatting off. Then you probably wouldn't need to use $page->getUnformatted(), and it might be better when setting values. So: ... if($page->template == "relevant-template") { $page->of(false); ...

This thread may tell you what you need:

I'd suggest hooking on Pages::saveReady. So, you could put something like this (not tested) in ready.php: $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); if($page->template == "relevant-template") { $originalValue = $page->date_field; $newValue = date("oW", strtotime($originalValue)); // or whatever you need to do $page->set("integer_field", $newValue); } }); Note that if hooking on saveReady you don't need to save the field or page because the page is about to be saved.

Are the tags in your HTML on separate lines? If so, Firefox will insert a space. <p> Firefox will add a space at the end of this. </p> <p>But not at the end of this.</p> I haven't noticed this happening in other browsers, though perhaps I've missed something. I have a memory that Firefox has done this for many years at least, but I'm not sure. Note that the Inspect tool in Firefox Web Developer Tools re-formats the HTML for easy reading, repositioning tags for many elements, and it removes spaces before tags in at least some cases (which is not helpful and a bit strange in my opinion!), so it's not good for debugging such things. The Page Source tool is more useful. I note that the heading "About ProcessWire" does actually have a space at the end in the HTML source. This could be for various reasons - such as a Text Formatter, or simply somebody typing a space!