teppo

The view in the screenshot is what you should get by calling <?= $modules->get('SearchEngine')->render() ?>. If you mean that you get the search form and a list of results but the results don't have a summary field, then it's possible that you need to define the summary field — this is assuming that your pages don't actually have a filled-in summary field on them: $config->SearchEngine = [ 'render_args' => [ // Summary of each result (in the search results list) is the value of this field. 'result_summary_field' => 'summary', ], ]; These are all translatable strings — so no, manual rendering is not needed, you just need to translate the module files to your language 🙂 The array part is interesting. perhaps options field (if I understood the next part correctly and this is what you're using here) isn't getting indexed quite right; I'll take a closer look at that soon. The code I posted a few replies ago on this thread was actually almost directly applicable to your case as well. Here's a rough idea — you still need to fill in the blanks, most importantly the way you're fetching those products: $wire->addHookAfter('SearchEngine::savedPageIndex', function(HookEvent $event) { $page = $event->arguments[0]; if ($page->template == 'TemplateWithProducts') { $searchEngine = $event->modules->get('SearchEngine'); // I don't know exactly how you're fetching those products; include your logic here :) $products = $pages->find('template=product, some_rule=' . $page->some_field); foreach ($products as $product) { $product_index = $searchEngine->indexPage($product, false, [ 'return' => 'index', ]); $page->search_index .= "\n" . $product_index[0]; } $page->save('search_index', [ 'quiet' => true, 'noHooks' => true, ]); } }); Note that if this is a multi-lingual site, that will require some additional tweaks (indexPage() will return an index value per language, and you need to use setLanguageValue() to store it). Let me know if any of this doesn't seem quite right, and I'll be happy to take a closer look 🙂

Thanks for the clarification 🙂 Grouping can be done by pretty much any imaginable way with ProcessWire data types as well, but I was wondering if this would be solvable with something that's "generic enough" to be added to the module as a feature. Technically I could add settings for grouping with custom fields etc. as well, but that sounds like it would be a lot more complex — as a module setting, meaning that it would have to work with a lot of different configurations — than just by template.

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!