teppo

At the moment SearchEngine doesn't have built-in support for this. That being said: you could create a custom search page and use SearchEngine to index and (optionally) find items, which you then output manually. Or you could hook into Renderer::renderResults() and customize the output there. So yeah, there are ways to handle this, but it will require a bit of extra work ? Out of interest: is each group going to contain items of a single template, i.e. in your example would "single-floor home" and "two-story home" be templates, or would this be some sort of option on a shared template (integer, options field, or something along those lines)? Grouping results by template might actually be a good idea as a built-in feature, just wondering if that'd work in your case.

So far only seen the site on mobile, but at least from that point of view it looks and feels really good. Especially enjoyed the typography. Great job! Can't wait to get a closer look on desktop ? (The pause/play button on the home page carousel is a nice touch, by the way.)

I realise that this is a rather old request, but I've just added a config setting for this. It's available as of AdminBar 2.5.0 ? So far I've been unable to reproduce this issue. There's a check for RepeaterPage, in which case it should be skipped for this sort of purpose, and since RepeaterMatrixPage extends RepeaterPage that should kick in here as well. Please let me know if this still occurs, though, and I'll be happy to take a closer look!

We could possibly be talking about different things here, but I don't see a difference between WordPress and ProcessWire in this regard: both can be installed into a subdirectory. There are a number of topics here regarding subdirectory installs ? If you're looking into something more specific or custom, some sort of .htaccess trick (or including ProcessWire's index.php, essentially bootstrapping ProcessWire within plain PHP script) might be the way to go — but again, if we're just talking about running a ProcessWire site from a subdirectory, that shouldn't be necessary at all.

Handle yourself (in code) or use the whitelist option, in which case ProcessWire will handle them automagically for you — but anyway, whitelist is also explained on that page ?

Hey @antpre! Could you check what's on that line and paste it here, and also double check your PHP version? If I'm looking at the correct line of code, 478 should be this one: public function createIndexField(string $index_field_name, string $redirect_url = null): ?Field { ... and if that's the case, the only matching issue I can think of would be the use of nullable return type ("?Field"). Support for nullable return types was added in PHP 7.1, so this would suggest that either you're running an earlier version of PHP, or there's something else wrong with the setup (or perhaps I've got the wrong line) ?

Hey @999design! SearchEngine can handle pages that are stored in PageTable or Repeater fields automatically, but if you're literally using subpages and there's no backend / field level connection between the parent and the children, then this would (at least for now) require a custom hook. In other words you can use SearchEngine, but you'll have to add a bit of extra code to populate the index. Something like this should do it: $wire->addHookAfter('SearchEngine::savedPageIndex', function(HookEvent $event) { $page = $event->arguments[0]; if ($page->template == 'ContainerPage' && $page->children->count()) { $searchEngine = $event->modules->get('SearchEngine'); foreach ($page->children as $child) { $child_index = $searchEngine->indexPage($child, false, [ 'return' => 'index', ]); $page->search_index .= "\n" . $child_index[0]; } $page->save('search_index', [ 'quiet' => true, 'noHooks' => true, ]); } }); Note that you need to use SearchEngine 0.21.0 for this to work; I just released a new version that made Indexer::indexPage() a bit more flexible. Also note that if you're building a multi-lingual site, indexPage() will return an array where the index is language ID, and you'll need to use setLanguageValue() to store it for each language one by one ?

Sorry for the delay from my part as well... ? Indexer grabs the value using $page->getFormatted($field_name). This means that output formatting is temporarily enabled for the page, value is read, and then output formatting is disabled (assuming it was disabled in the first place). I'm not able to make this work via the API either — getting the same error there, so I'm also somewhat confused about this. Could mean that there's some difference in the way we're testing this. Anyway, both $page->save() and direct call to SearchEngine::indexPage($page) lead to the exact same error in my tests using your Hanne Code snippet ? In this case the problem seems to be that your Hanna Code snippet is accessing Repeater Pages that were loaded with output formatting disabled (FieldtypeRepeater::___wakeupValue()). I've been trying to work around this for a while now, but to be honest I have no idea how to do that without causing potential issues and/or slowdowns elsewhere. I do have a couple of ideas I'd like to try, but it may take a while to figure this out, and even then the conclusion could be that this is simply too much of a hassle to automatically handle in SearchEngine. The TL;DR here is that at least for the time being a slight modification is required for the Hanna Code snippet: foreach($page->images_gallery as $img) { $img->of(true); (Or, alternatively, you could get $img->image with $img->getFormatted('image').) I'll keep trying, but I can't give you any promises regarding a possible future Hanna Code compatibility enhancement yet ?

Hey @ryan! Sorry to bother you with an old request, but I'd really appreciate if you could take a look at https://github.com/ryancramerdesign/TextformatterVideoEmbed/pull/12 and add support to this module for youtube-nocookie.com. The PR has some conflicts by now so probably can't merge that right away, but the key part is basically a new option to use the privacy enhancing cookieless domain ?

Hey @Mike Rockett! Just a heads-up that I sent you a little merge request: https://gitlab.com/rockettpw/seo/jumplinks-one/-/merge_requests/3. The gist is that currently the config link is displayed regardless of the user having module-admin permission, so I've added a check for that first. At least in our case typical Jumplinks users don't have access to modules section, which means that this link would only lead to an error message, which is obviously not very nice ?

Hey @bernhard. Just a quick heads-up: the support board link in the modules directory points to the GitHub repository. Assuming that wasn't intentional ?

No reason to apologise. Ideas are always welcome here, no matter how rough they might be ? If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree. This "one tree" approach is actually pretty fundamental to ProcessWire, and — as Ryan explains in this very old thread — there's a good reason for this: I think someone was developing a module (?) a while ago that sort of created separate trees, though again it was basically a "virtual" approach where you get multiple page lists in admin, yet behind the scenes things are still in one big list. On a loosely related note: a while ago I came across a site that used an approach of URL segments + separate PHP router library. Not necessarily an approach I would've preferred — in most cases that's just some added complexity you don't really need — but that's always an option. Anyway, I think you may be onto something here, but I'm just not sure I'm seeing the entire picture yet ?

This is interesting! Full disclosure: on a few occasions I've considered adding a separate model layer to Wireframe, but I've never found a proper reason, i.e. I couldn't think of anything I can't do without it — or even anything it would make notably easier or more effective or more organised — and I'm trying not to add features just because they'd be fun to implement. That being said, I'm always on the lookout for interesting new stuff to add, as long as it adds real value to the framework ? I think when you say "model" you probably mean something a little different than what it means to me personally. In my mind models are tied to data structure, have very little to do with routing, and so on. In fact from what I could gather from your examples it looks like such models would indeed be a lot like custom post types in WordPress in that they'd be located in a single "bucket" and define a per-model route that's separate from the regular page tree structure. If that's the case, wouldn't one variation of that just require creating a parent page on the root level and then subpages below that? Or, for more complex routes, you could make the parent page render its subpages based on URL segments. All the building blocks are already there, though obviously this one needs quite a bit more work — you have to define the routes programmatically, for one. Any chance you could flesh your idea out a little more: What would you use this sort of thing for? How would you envision defining the routes? How would this be different from existing options, such as placing a parent page under root and then subpages using specific template under that, or using URL segments — i.e. would the biggest benefit be some abstract method of defining routes? WordPress templates are a bit different in that they're about representing data, while ProcessWire templates are obviously all about structuring data. Wireframe, for an example, has concepts called "layout" and "view", which are largely in line with WordPress' templates: each template can have multiple views, and each of those views can then be used to render pages in different ways, and/or for different purposes (JSON, RSS, HTML, etc.) Long story short: I'm intrigued, but not entirely sure of all aspects that this concept would bring to the table. Definitely interested in hearing more though!

Hey @toni! There's no close action on the forum, but I'm going to merge this topic with the TemplateEngineFactory support board — the recommended approach is that if you have questions regarding specific module, you should post them on the support board for that module. You can find the correct board via the modules directory (there's a "support board" link in the sidebar for each module) ?

Hey Ryan — just wanted to say thanks. Assuming that I've got this right and this could mean that eventually ProcessWire can natively (or at least with a module that doesn't have to rely on any weird tricks) support something like S3 or Google Cloud Storage, this is a brilliant move! Very much looking forward to that. Thanks again, and keep up the great work ?

@GhostRider, FieldsetPage support is now included with module version 0.20.0. I didn't have much to test with, but it did seem to work as expected on my limited use case — let me know if you run into any issues and I'll be happy to take a closer look ?

I've only ever used Hotjar. Their personal plan is free for sites with relatively small traffic (you can collect data from max 2k pageviews per day).

Sorry for taking so long to reply — this is now the top item on my todo list. I'll try to get it included sometime soon!

In case you're using Page Autocomplete for the inputfield, this might be related: https://github.com/processwire/processwire-issues/issues/550. Either way, you'll likely have to switch from "custom find" to "selector string" and include "check_access=0" in your selector to get this working ?

Hey @Confluent Design, Sorry for the delay. Your message slipped my mind, thanks for pinging me ? You're correct in that SearchEngine stores its index in a ProcessWire field, so yes — since your database is already shared, there's nothing else to do in that regard; unless I've very much misunderstood something here, it should work right out of the box. From a basic technical point of view, no, I don't see any issues here. It's worth noting, though, that elasticsearch is quite a bit more complex and feature-rich than this little module here. Depending on your needs that might or might not be an issue. Basically with SearchEngine you get a searchable blob of all page content that can be converted to text without toying around with additional APIs or libraries (so no file data at the moment), and the search itself is done using a simple selector string — no advanced weighting, stemming, etc. I do have a few "advanced" features on my todo list, but at the moment there's no timeline for any of that ?

It looks like you're using Hanna Code with one or more of your indexed fields. Is that correct? Here something is trying to resize a Pageimage object while it's actually a Pageimages object, which usually means that output formatting is off. If so, you could fix this in the Hanna Code snippet itself (by checking for Pageimages and getting the first Pageimage from it). I'll see if there's something I can do to make this work better, but that's the quick fix anyway. (Assuming I understood the stack trace correctly...)

If you view the page source (right-click + view page source, i.e. not the "formatted" version you see in dev tools), is that actually what you see there as well? Since a_01_text is a CKEditor field it'll return markup, and in this case that markup probably consists of a paragraph (<p>Some text</p>). Since you can't have a paragraph inside a paragraph, your browser might be "correcting" it to this. How 'bout converting that wrapping <p> element into a <div> instead? <div class="wow fadeInUp animated" data-wow-delay="1.3s"><?=$page->a_01_text?></div>

function renderCustom(PageArray $items) { foreach($items as $item) { echo $item->title; // ... heavy content loading } } Is this just an example, or is your actual function also just echoing content? If so, that right there could be your problem — echo will output the content right way instead of returning it for assignment. Try something like this instead: function renderCustom(PageArray $items) { $out = ""; foreach($items as $item) { $out .= $item->title; // ... heavy content loading } return $out; }

I think this would be a very good first step, and would probably be quite enough for almost all use cases. If you could make this change, I'd be a very happy user indeed ? Options like these are great to have, but from my point of view automation is always the best solution (if it can be done, that is). After realizing that the cache can now contain pages that are not public I turned to this option, but doing it manually on a site with loads of non-public pages all over the place... not fun ? Slightly off-topic: I was under the impression that the "Templates without sitemap access" setting would also affect child pages, removing them from the sitemap, but at least on one site it doesn't work like that: parent page (the one with a template that was specifically selected here) doesn't show up, but its children still do. Not sure if that's a bug or something I've misunderstood?

@Mike Rockett, I think we're talking about different things here. Sorry, my bad — should've been more clear! ? The thing is that currently this module caches content for logged in users as well, which in turn means that the XML sitemap that guest users then view might contain non-public content. This probably shouldn't be the case, at least not by default: if the user is logged in, it would be safer not to cache anything at all, or you may end up with a sitemap that publicly displays content that wasn't meant to be public (even if only URLs and update times)... not to mention that (as you pointed out above) including non publicly viewable URLs is not particularly useful anyway. The idea about including roles in cache key was mostly just so that if there's indeed some use case where folks prefer current behaviour, that could still work. I can't think of many reasons for that either, though, unless it's for some sort of an internal API / index or something ?