BillH

I think the solution may be here (applied to a repeater rather than a repeater matrix), though I'm still conducting tests:

However, I've just found that $page->secureFiles() returns "true". [EDIT] I don't understand this, but I'm not sure how relevant it is, as I think I may have found the solution - see next post.

"Prevent direct access to file assets owned by pages using this template?" is set to "No". I tested the other two settings, and they didn't change anything. Also, following on from your suggestion, I checked $config->pagefileSecure in wire/config.php, and it's set to "false".

Thanks @poljpocket, a useful thought and I've just checked. In each case the URLs are identical.

I have an area in the front end of a site that can be accessed only by logged-in users with a particular role. The page works fine for such users, except that images in a repeater field don't appear. Each image field within the repeater displays either the alt text or a placeholder (depending on which browser), but the image does not load. Attempting to load one of the images on its own in a window using its URL also fails. However, the images load correctly when the page is accessed by a superuser. It thus seems as if users with the role don't have permission to access the images. I've tried specifically giving view access on the field settings, but it doesn't help. I can't think what other settings might work. Does anyone know what I should be doing?

Hi, and welcome to the forums! I suggest starting with this thread, which gives various options: Let us know if you need further help!

Another option might be the RuntimeMarkup module.

It occurs to me that if you want a single expression you could also use: if($page->get("field_$i") == 'test') { ...

I think you have to do it like this: for ($i = 1; $i <= 40; $i++) { $fieldname = "field_$i"; if($page->$fieldname == 'test') { // do stuff } }

It does seem that comparison operators don't work with image custom fields. I've just tried it with a text field and, like you, get a message saying the operator is not supported. I don't know why this is. Perhaps someone else can explain... A rather laborious workaround might be to create separate index fields that are automatically maintained with a hook on saving the article. If no better solution is suggested, let me know if you need help with this. On the bonus question, your version using OR-groups looks as if it should work, so I'm not sure what the issue is – though you might want to try 0 instead of the empty string.

Selectors support custom fields for images. So, my first guess is that there's something about the logic of the selector or how it interacts with the data that is causing a problem. One thing to watch out for is that 'today' is, I believe, specifically 00:00:00 today – so, for example, '<=today' might be better as '<tomorrow', or you could create your own variable containing the particular time you want. Regarding your bonus question, I think the last point above may lead to the result you want. $pages->find('template=this_template, date_from<=tomorrow')

I spoke too soon - should've checked first! I realise that I've been using CKEditor fields for this sort of thing, and they add &nbsp; entities to the start of the line. Might this be a workaround? Meanwhile, that's a really useful hook from @Robin S, which I've already made use of (but not for Form Builder fields).

Yes, completely possible! Indeed, I'm not sure why you're losing the spaces. Do you have a text formatter (on the Details tab) applied to the field? If so, this might be removing the spaces. If the textarea uses a rich text editor (CKEditor, TinyMCE), it's possible that the editor (or an associated function) is removing the spaces, so it'd be worth checking the settings. I can't think of one that would do this off the top of my head, but I may well have forgotten something! If it's neither of these, take a look at the HTML in your browser using the Inspect option. And if that doesn't clarify whether spaces are getting through to the page, you could check using something like: echo str_replace(" ", "_", $page->myTextField); If underscores appear, the issue is something to do with the rendering of the page. You could try replacing the the underscores with &nbsp; in the above, though this shouldn't be necessary for the spaces to render in a <pre> element.

By chance, I use the same two suppliers as @millipedia, and have been pleased with both!

Welcome to the forums! I have three suggestions. First, when using PW, don't think about SQL unless you really, really have to – and it'll probably never be necessary! Second, when deciding how to structure data, it's usually best to start by thinking of each major item as a page, and move on to complex field types only if it would improve things (usually because it will help with human editing of data). So, for example, you might handle each booking as a page, and then use a Page Reference field to link to the relevant event. Third, if you haven't already, look in depth at selectors (very important and a great feature of PW!) for retrieving the data you need. Let us know if further help would be useful!

Hi, and welcome to the forums! Note that questions about ProFields are best posted in the ProFields Support forum (https://processwire.com/talk/forum/28-profields-support/, in the VIP Support section). Meanwhile, perhaps this blog post will help with your question: https://processwire.com/blog/posts/new-repeater-and-repeater-matrix-features/#matrix-type-groups Or this forum post:

Hi, and welcome to the forums! I recommend that you use different templates for the home page and child pages. This should make doing what you need in the back end (editing) pages straightforward Then for the template files, there are various approaches you could use. Probably the easiest would be the one described under "Direct Output with Includes" at https://processwire.com/docs/tutorials/how-to-structure-your-template-files/. For example, the includes for both template files might be head, body and footer sections, but a menu section could be different in each. Let us know if you need further help!

I don't think there's any particular problem with OSM maps on mobile devices. For example, see https://leafletjs.com/examples/mobile/. There are good instructions for the FieldtypeLeafletMapMarker module at https://processwire.com/modules/fieldtype-leaflet-map-marker/, but it might help to note that the basics (not tested) seem to be to include the following in the head section of your template: <?php $map = wire('modules')->get('MarkupLeafletMap'); echo $map->getLeafletMapHeaderLines(); ?> And in the body where you want the map to appear: <?php echo $map->render($page, 'NAME_OF_YOUR_MARKER_FIELD'); ?> To find out more about Leaflet (including markers), take a look at the Leaflet Quick Start Guide https://leafletjs.com/examples/quick-start/.

Thanks for posting your really useful solution! I agree that your suggestion of a property to set UTF-8 page names for each language would be a good feature.

Do you have the Page Path History module installed (it's in the core modules)? Also, I think you should start by using getPathHistory(), and then getPathInfo() for information about a particular path.

You could add a rewrite rule to .htaccess, but I reckon it'd be easier (and wouldn't risk being overwritten on updates) to do as you suggest and use a Page::saveReady hook. I do this regularly to manage page names and it doesn't cause problems. You're probably aware of this, but you may need to stop the hook running if the page hasn't yet been created: $pages->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments('page'); if(!$page->id) return; ...

I'd suggest you use the core Lazy Cron module to trigger loading the JSON. Note that, as described on https://processwire.com/docs/more/lazy-cron/, Lazy Cron hooks into ProcessPageView::finished() to avoid slow page loads.

My guess would be that it's the line getting a value for $event where things start to go wrong. I'm wondering in particular where you're getting the value of $id from, and whether it's valid? You might want to try var_dump() to check whether $event actually is an object (and if so, if it looks as if it might be a repeater item): var_dump($event);

Using findRaw() you get a normal PHP array (not a PW page array). And the value for select_countries is itself an array. So you can do this: foreach($items as $item) { foreach($item['select_countries'] as $country) { echo $country['title']; } } I'm not sure what findRaw() returns if your page selector field is set to a single page, but you may need to simply use $item['select_countries']['title'] rather than the inner foreach.

It seems that, as @kongondo notes, there's an issue with the findRaw() syntax, at least with the array-type syntax and page-reference fields. However, the dot syntax seems to work. So I think the following will give you what you need: $items = $pages->findRaw("template=template-news, select_region=austria, limit=2, objects=1", ["select_countries.id", "select_countries.title"]); Or slightly simpler, as the keys of the returned array of page references are the page ids: $items = $pages->findRaw("template=template-news, select_region=austria, limit=2, objects=1", ["select_countries.title"]); I've submitted an issue regarding the other syntax: https://github.com/processwire/processwire-issues/issues/1563