BillH

The phrase you quote ("Optionally specify...") comes from the doc page for $cache->get(). With this function, you are specifying the maximum age of the cache you are trying to get (for example, up to 3600 second old). I could be misunderstanding you, but it sounds as if you're trying to set the expiry time for caches that you have created, in which case use $cache->save(). Or perhaps that is what you're using, in which case follow the instructions for the expire argument on the relevant page (https://processwire.com/api/ref/wire-cache/save/). Note: if you want them, the WireCache::expire constants are on the $cache page (https://processwire.com/api/ref/wire-cache/).

Hi Iraklis, and welcome to the forums! I can't entirely figure out what's going on from your description, but here's some information that may give you a foothold. PW has two types of field ("fieldtypes") for selection options, and it sounds as if you may be dealing with the second of these: Select Options, where the options available are defined on the Details tab of the field definition. Page Reference, where each option is set up as a page, and you select the page. The page could be a page that appears on the site, but it could be something as simple as a name (e.g. the name of a country) used only as an option for selection (and doesn't appear as a page on the site). This seems a little odd at first, but it's a powerful and flexible way of doing things! You'd find the pages somewhere in the page tree, either under Admin or somewhere else - e.g. you might have Value Lists > Countries > Afghanistan etc. To find out which type of field you're dealing with: Setup > Fields > Your field > Basics tab > Type. To find out what template a page is using: Your page > Edit > Settings > Template. You'll find template files in Site > Templates. Let us know if you need further help.

A couple of good discussions about understanding output formatting:

Have you looked at the structure of the PW database? If not, it's quite easy to understand, and you may find that storing comments would be a lot "cleaner" than you expect. Essentially, the data for each field is held in a separate table, so the comments would be quite distinct from other data. If you'd be happy with the database structure, it'd at the very least save you what I imagine would be a huge amount of work!

I'm sure it'll be mentioned in the posts you'd find following @bernhard's link, but I'd draw your attention to another module also worth looking at: https://processwire.com/modules/batch-child-editor/ - particularly the Add mode, which can import CSV.

The post from @Robin S deals with your issue nicely, I think, but it might also be worth a look at the links in this discussion: The ConnectPageFields module uses methods similar to the synchronization suggested by @Pixrael. And owner selectors look interesting, though I've never tried them.

I'm not sure what you're aiming at, but is it that you want to find pages based on both what is in the portfolio-detail page and in the user page? If so, one approach might be to do something like this (not tested): $userIDs = implode('|', $pages->findIDs("template=user, title%=sometext")); $profiles = $pages->find("template=portfolio-detail, user_id={$users}, another_field%=someothertext");

Looks good. And the way you've used a "type" field in the blocks repeater has given me a really good idea for how to deal with a completely different issue on a site I'm developing!

@rash I'd be interested to know if you do find other solutions.

One thing I'd try is using Pages > Find to make the same selection, and then simplified version, and see if you get any results. If you have debug set to true in config.php, you can see the selector being used towards the bottom of the page. Another thing would be to try displaying the results of the find using the selector – and variations of it – on a page using print_r(). Or if you have Tracy Debugger installed (highly recommended!), return the result using bd(). BTW, it might be more efficient and a little easier to debug if you find and loop through the pages something like this: $batches = $pages->find("template=batch, batchdatestart<=today, batchdateend>=today"); foreach ($batches as $batch) ...

As far as I can tell, the answer to your question is no, not directly. And it would be useful for me too if this could be done! If you include a text field in a repeater field, the site search doesn't seem to construct the correct selector. I tested this by selecting "View all" with debug turned on in config.php so that the selector appears at the bottom of the results on the Page Search page. For example, if (in addition to title) we add a field named text_in_repeater which is used in a repeater field named my_repeater, and if we search for "foobar", the relevant element of the selector would be: title|text_in_repeater%=foobar This doesn't work. To get the result we want, it would need to be: title|my_repeater.text_in_repeater%=foobar I don't know if this is something in PW that could be improved, or whether it must be this way for some reason. Or perhaps I'm missing something. Anyway, I can think of a couple of ways of dealing with this. The first would be to set up a field of type Cache, and include the fields you want to find in that. I haven't tested this for the purposes we're discussing, but my guess is that it'd work - but I could be wrong! If a Cache field doesn't work, another method would be to set up a text field, and then hook on Pages::saveReady (probably in ready.php) to add the searchable content you want to that field.

Ah, I didn't notice which forum you'd posted this in! I'm pleased you find the answer.

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.