BillH

I don't know the cause of the trouble, but it might be worth checking that your .htaccess file is being read by adding some random characters at the start; a server error when you go to a page of the site will mean that it is being read. My best guess about the /assets/files/ errors is that .htaccess is being read, and that the errors are a side effect arising from the rewrite rules involving that directory. Have you looked inside the PW .htaccess? It's well commented, so the next thing might be to read through it for any ideas.

I think this will tell you what you need:

You could use a hook as in this discussion: Putting the hook in ready.php may well be a good plan.

Regarding users, what you describe is a common situation with membership systems, where there are often things such as corporate members with associated members, so it might be worth searching the forums to see if there's anything about what others have done. And perhaps take a look at the Login Register Pro module. For file uploads, in one project that requires regular uploads by a client, I made a simple admin page containing only a file field (giving me an instant UI) and a Save button. I hooked after the page has saved to process the files. I don't know of a better idea for matching files to clients than using filenames – though that doesn't mean there isn't one! I have one suggestion: it might help to reduce errors if the filename included a checksum for the string that identifies the client.

You may get them in the correct order (that is, the order they appear in the page tree) by default. But if you don't, try adding `sort=sort` to your selector - see "How to force pages to sort by their admin order" on the page https://processwire.com/docs/selectors/).

Another possible approach, given $subchildren as the result of your find: $parent = null; $grandparent = null; foreach($subchildren as $subchild) { $scParent = $subchild->parent; $scGrandparent = $scParent->parent; // Or $subchild->parent->parent if($grandparent != $scGrandparent) { $grandparent = $scGrandparent; echo $grandparent->name . '<br/>'; } if($parent != $scParent) { $parent = $scParent; echo '&emsp;' . $parent->name . '<br/>'; } echo '&emsp;&emsp;' . $subchild->name . '<br/>'; } Obviously, this'll produce simple indented text, but you could adapt to generate a list or whatever you need.

I suggest taking a look at the sections 'Finding pages that have specific parents or ancestors' and 'Sub-selectors: selectors within selectors' of the 'Using Selectors' page at https://processwire.com/docs/selectors/. You might end up with something a little like this, here finding all grandchildren with a name beginning with 'a' that have a grandparent with location = 'US': $grandchildren = $pages->find("has_parent=[template=grandparent, location=US], name^=a");

And another thought: consider using URL segments as described at https://processwire.com/docs/front-end/how-to-use-url-segments/.

Recently I was planning a project for an archive of PDFs, and I decided that a page per PDF was going to be significantly easier to work with and more flexible than grouping them in file fields. The number of pages shouldn't be a problem. You'd get around 6k pages a year, so 60k a decade, 120k after two decades... Comfortably within PW's capabilities. On the other hand, a client page with a file field holding 500 PDFs after a decade doesn't sound great! If you haven't seen it, you might find something interesting in this recent blog post about new scalability options: https://processwire.com/blog/posts/pw-3.0.175/

Hi @Goca and welcome to the forums! There's a useful description of how templates work at https://processwire.com/docs/start/templates/ Don't miss the link to the pages about output strategies in the 'Next steps' section at the end. Note that if you'll have a lot of pages where each needs a slightly different template, you may find that the best approach is for them to share a template containing a little conditional logic, for example: if($page->name == 'page1') { // Display something } elseif($page->name == 'page2') { // Display something else } elseif...

What happens when you try "Check again"? The same message, error 500 or something else? If error 500, there's probably something in .htaccess that your server doesn't like. It might be worth installing a fresh .htaccess, just in case an error has crept in. Other than that, if you've tried everything in the discussion mentioned above, this starts to go beyond my knowledge!

If you haven't found it, this discussion might help:

To set a cache that will expire at midnight today: // Expiry time string $midnight = 'today 23:59:59'; // Alternatively, the start of tomorrow is midnight today // $midnight = 'tomorrow'; // Save the cache $cache->save('test-cache', 'Value for cache', $midnight); So, to achieve what you want (if I understand you correctly), you could use the get() method something like this: $midnight = 'tomorrow'; $str = $cache->get('test-cache', $midnight, function() { return "The next cache value"; }); By the way, if you haven't discovered it, the getInfo() function is really useful for debugging, for example: print_r($cache->getInfo(false, 'test-cache'));

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.