BillH

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

If a find() is too slow, use findMany() with a suitable selector: https://processwire.com/api/ref/pages/find-many/. Or if that's still too slow, or if you find them preferable for some other reason, use findJoin() or findRaw(), as described in the blog post at https://processwire.com/blog/posts/find-faster-and-more-efficiently/. Another option would be to try RockFinder3: https://processwire.com/modules/rock-finder3/.

If you want to do something if the page has not yet been created: if(!$page->id) { // Do something here }

I haven't tried, but you may be able to do it by hooking on ProcessPageList::find, as discussed here: Note that the pages would have to be loaded and the sort codes calculated each time the page tree was displayed, so I think the approach I have suggested would be more efficient – something that is discussed in the thread too.

The way I've done things like this is to create a text field, use a hook to add a sort code to that field, then set each relevant parent template to sort its children using that field. The sort code would be whatever you'd normally sort by, but with a prefix that depends on whether the page has children or not. So, I'd use something like the following (not tested) in ready.php, here assuming you'd basically sort on title: $this->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments[0]; if(in_array($page->template, array('template1', 'template2', 'template3'))) { $page->of(false); if($page->numChildren() > 0) { $sortcode = "A-" . $page->title; ) else { $sortcode = "B-" . $page->title; } $page->set('sortcode', $sortcode); } }); Of course, you could use a hook in a module instead. And you can use the same basic technique to get just about any kind of sort order you want.

Perhaps the easiest thing to do would be to make the fields of the user-facing form required, perhaps using JavaScript, or adding the required attribute: <input type="text" id="role" name="role" required> If you want to hook into the module, take a look at https://github.com/ryancramerdesign/LoginRegister. If all else fails, hooking before Inputfield::render (see the example on the page just mentioned) and then replacing strings in the form HTML is an option.

Yes, I noticed that too in the post https://processwire.com/talk/topic/26947-craft-cms-and-processwire-– a-comparison/?do=findComment&comment=222902 (I assume this is the one you mean), although the exact statement is "borderline deprecated". I too was going to comment because language alternate fields are really useful and I make good use them. It's not just image fields, but other non-text field types. For example, there might be a checkbox that can take values specific to each language, or a localized URL for each language, or different attached files (e.g. PDFs in each language). In general, language-alternative fields become really valuable when producing different versions of output for each language, rather than simply having translations of text. Another purpose for which language-alternate fields can be better, even for text fields, is when building interfaces and outputs for translators - for example, if in the admin one needs to display versions of text in different languages side by side, or grouped in fieldsets by language. So from me it's a big vote for keeping language-alternative fields undeprecated!

It occurs to me that with SQL you could write a user-defined function for comparing sets of tags, but this still might run into problems with execution time. I suspect @Robin S's idea is a much better approach!

I could be wrong, but I don't think findRaw(), RockFinder or SQL have any way of returning a result that depends on how many items records have in common. And anyway, to make comparisons between every pair among 20k projects, you'd be looking about 400 million comparisons – which is going to take a while! So, it seems to me that either: you need to think of an algorithm that doesn't involve comparing each project with every other; or you'll need to use a different metric of similarity between projects – or even rank by something other than similarity. Considering the algorithm, I'm wondering if there's an approach that would run in a time dependent on projects * tags (rather than projects * projects), though I don't know if this is possible - and I suspect it'd be really difficult to come up with something. Using a different way of ranking the projects might be much easier, and perhaps equally meaningful - indeed, now that I think about it, I wonder how useful ranking by degree of similarity would be. An alternative, just for example, might be something like ranking the tags by popularity (number of projects they appear in), then give each project a score depending on the ranks of its tags (the mean, or median, or sum of the top three, or something like that).

An interesting problem, but I'm fairly sure there's no solution using PW selectors. As far as I can see you'd need to compare the tags for each project to those every other project, keep track of the results, and then sort by those results. You could get the data you need into an array quickly by using something like: $tagsForAllProjects = $pages->findRaw("template=project", "tags"); However, as you've probably realised, if you have many projects, it could take a long time to work though making the comparisons. Even though you only need to compare each pair of array items once (perhaps using array_intersect()), if I've got this right (which I might not have done!) it'd take n(n-1)/2 operations – so for 100 projects about 50,000 and for 1,000 the best part of half a million. But perhaps someone knows a better way.

Some of your questions will be answered by reading through the articles listed at https://processwire.com/docs/modules/, particularly the first three. Also really helpful are the Hello World example modules described in the blog post https://processwire.com/blog/posts/pw-3.0.181-hello/. And another excellent post is https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/. These will probably give you enough to start building useful modules. And I'd suggest that building a module or two (especially by following examples) would be the best way to get started, working things out as needed.

PDFObject is useful for making the most of browsers' PDF capabilities and for setting up fallbacks – particularly for mobile browsers.

If I understand you correctly, in your final HTML you are getting something like this: <p style="color: white;"> <p> Your text goes here. </p> </p> If what you need is simply to remove the first and last <p> tags from $ber_MDL_riposta, you can use: preg_replace('^<p.*?>|<\/p>$', '', $ber_MDL_risposta) But if it seems tags are being inserted, do you have a TextFormatter applied to the field (Details tab)? When you switched to a textarea field (without CKEditor), did you check that the data in the field does not include tags? Have you used "Page Source" or "View Source" (or similar) to check the HTML?

A ProFields Table field sets up its own database table, so I don't think you'd have any performance issues at all, even with large numbers of columns and rows. But I'm not sure what the UX would be like with very many columns, perhaps most of them empty. I don't know if it'd be possible in your circumstances, but might it reduce the number of empty columns to have various types of product, and a different table field for each type (with subsets of columns), hiding/showing the fields depending on the type selected? Meanwhile, you might find this discussion useful:

Hi Peter, and welcome to the forums! If you want to get the database name, you can use: $databaseName = $config->dbName; Or you could look for $config->dbName in the site's config.php file. To see the database structure, you could use a tool such as phpMyAdmin or Adminer, or install the Tracy Debugger for ProcessWire module (https://adrianbj.github.io/TracyDebugger/#/) which is highly recommended and, among many other things, adds an Adminer page to the Setup menu. However, I note that in a typical ProcessWire installation, you don't need to use SQL queries at all, and they're probably not the best way of going about things. Generally, using PW selectors will do everything you need, and will be much more straightforward: https://processwire.com/docs/selectors/. They're one of the really nice features of PW! Let us know if you need more pointers or suggestions.