teppo

Sounds like a neat feature, but this will get somewhat complex 🤔 At the moment automatic description is generated by looking for the (first instance of the) query string (as a whole) within the index, and then converting that + a sensible amount of "padding content" to an excerpt. So far so good. Now, in order to generate an excerpt based on multiple words... Search query needs to be split by whitespace, and perhaps other characters as well. Each word should be matched individually. Preferably words should be matched in any order, just like they are when the query is performed. Here we should probably include more than just the first match, or at least that's my initial gut feeling. Since there may be many individual matches, we need a limit to how much content gets displayed, and we should also have some sort of algorithm in place to figure out which matches to use. Of course some of this may not be strictly speaking necessary: just finding a match with any single word from the query would be pretty much as simple as the logic we now have in place. But in this scenario that would result in somewhat suboptimal results. Anyway, just thinking out loud here. I'll give this a shot and see what I can come up with 🙂 By the way, this is somewhat off-topic but this is one of the reasons I almost never use this operator: using the same content you have on the page, I'm unable to get any matches with "incised streambanks", "stream", or "banks". Might have something to do with MySQL settings (I'm using mostly default settings) but anyway, in my experience this behaviour is so flaky that I really can't be bothered with it. "%=" may not find results in "wrong" order etc. but at least it won't miss direct hits. And as for performance... well, I've never run into a use case where I would've observed any noticeable difference 😛 (Enough with the off-topic!) I'm not entirely sure about this one yet. Let's see if this makes sense once I grasp the "non-consecutive autodesc" thing.

That's a good point. Version 0.3.0 reverts field settings during uninstall. Seems that altering data is not necessary: even if the field contains multiple values (in database), only one is returned with the new settings. I'm not 100% certain that this won't cause any unexpected side effects, but for the time being it seems to work fine... 🙂

No worries and thanks for letting me know 🙂

I have to disagree with this, to an extent. If I did client projects of my own I'd very much appreciate the option of off-loading the hosting and day-to-day maintenance of said sites to someone else. Sure, most of the time a "general purpose" hosting plan is good enough and ProcessWire is great in that it has very rarely really "required" updates, but I could imagine a plan dedicated to ProcessWire providing some extra services that a general purpose one won't and can't 🙂 At the same time I don't really see why this wouldn't work for business clients as well. We host the sites we build in-house, and I can say that a lot of time and effort has gone to tweaking that setup, and maintaining the platform and the sites on it is an ongoing process. If hosting wasn't an important part of what we do, or we weren't quite as familiar with the inner workings of ProcessWire, it would make plenty of sense to subcontract that service from someone who actually specializes in it. Many companies that work on other platforms, such as WordPress, choose external hosting — not because they can't do the hosting, but rather because it's not their core business. There are also numerous "developer oriented" hosting platforms out there.

I've tried, but so far have been unable to reproduce this. Any additional pointers would be welcome 🙂 Glad to hear you got it solved. Just for the record, with latest release 0.29.6 $query->results is also available. It's otherwise the same as getResults(), but adds additional check in case there were no results (in which case it will return null instead). I believe my initial idea was to avoid multiple ways to access the same data, but this is more in line with other features 🙂

You and me both. From the outside it seemed like a very nice idea and the numbers initially posted seemed to indicate a decent level of interest. Hard to say — could be any number of reasons: technical issues, problems with the business model, or simply the classic "moved on to other projects". The service was quietly taken down, and the Twitter account or support board were never updated to even mention this 🤷‍♂️

At the moment tab labels can be customized by hooking into Renderer::renderTabLabel — does that seem feasible to you? Could also have a setting for this, but I'm not yet sure about that; it would get a bit complicated, particularly if I end up adding more group_by options. My initial impression is that current approach might be better, especially considering accessibility: users should get some kind of "summary" before the tabs, so that they know what's going on. Solving this with a "tabs first layout" could mean a) visible order that is not the same as real order, or b) visually hidden heading above tabs and then a visible heading hidden from screen readers below them. (Loosely related note: accessibility is not "perfectly" handled right now, I'll likely make some tweaks in this area soon.) I'll have to think about this a bit more. At the moment you have a couple of options: The module currently outputs a heading above the tabs and a summary below them. You could modify that first heading so that it's visually hidden and then hook into results rendering and inject your own "heading" above the summary element. This is a bit tricky right now, but I can make the heading rendering part hookable separately, I think that'd make sense anyway. Modify the order with JS. (Yes, this is a bit ugly... 🙂) So no real answer here, just some ideas, but I think that this level of control will likely require some sort of hook based solution anyway.

So you are looking into querying data from an external service (Shopify?) that uses GraphQL? Simply put, GraphQL is a query language: a client sends a query (defined using the GraphQL language) to the server, which then responds with a GraphQL object. WireHttp is a class you can use to send HTTP requests from ProcessWire. You could send a GraphQL request with WireHttp — so no, GraphQL is not a replacement for WireHttp 🙂 I'm not saying that you should use it, but here's a very simple GraphQL client implementation: https://gist.github.com/dunglas/05d901cb7560d2667d999875322e690a. Here's an example of querying GraphQL API with Guzzle (which, by the way, is something you could use as a replacement for WireHttp): https://dev.to/jakedohm_34/how-to-make-a-graphql-query-or-mutation-in-php-with-guzzle-359o. Or you could use something a bit more sophisticated, perhaps https://github.com/mghoneimy/php-graphql-client. I'm not an expert on this topic, so perhaps someone with more GraphQL expertise can chime in. Just thought I'd drop some pointers 🙂

Your approach seems fine to me. If there were a lot of templates then it would result in multiple queries, but for most use cases I'd assume the performance impact to be extremely small. On the other hand the approach I've taken (modifying the DatabaseQuerySelect object on the fly) should result in just a single query, but is also potentially more fragile... 🙂 Thanks — this is now fixed in the latest release.

Hey @Erik. Could you check which PHP version you're running? That error is likely related to nullable returns types ("?Field"), and support for those was added in PHP 7.1. This module will not work on older PHP versions.

To be honest I don't see a big reason to switch if your solution works for you already 🙂 Pros for built-in approach: Can be enabled or disabled at any point via arguments passed to the module. SE is "aware" of the built-in grouping feature, so it's something that will likely keep working consistently and may also benefit from future updates. Not saying that yours won't keep working, though. I've gone through some extra hoops to only include tabs / buttons for the templates that actually have matches. Personally I dislike it when I click that "Articles" button, wait for the page to load... and then there are no results. I don't want to waste users' time. The "group_by" setting is automatically considered when returning results as a JSON feed. Returned results are split into groups. (At least they should, it's been a while since I last checked this one...) Native feature may eventually get proper "autoload" support, so that switching between categories / templates doesn't cause additional delay. Again, this can be a bit tricky, and whether it's really "worth it" depends on the case. It's themeable and I've tried to use markup that is somewhat accessible. To be honest there's likely more to be done in this regard 🙂 Whether or not any of this matters for your use case is debatable. Again, I don't see any notable reason to switch if your solution works fine already. Actually I'm pretty sure that your solution is more straightforward and results in slightly better performance. Not sure if I got this right, but SE has a couple of options that may be related. Both are under find_args: // Optional: values allowed for grouping. 'group_by_allow' => [], // Optional: values not allowed for grouping. 'group_by_disallow' => [], Basically if you add a list of templates to "group_by_allow", these are the only templates that will get their own tabs. Other templates are still included in the search, and thus under the "all" tab. The "group_by_disallow" option works the other way around, templates included here will always be excluded from grouping (they won't get their own tabs, but again will be found from the "all" section.)

Thanks, @adrian! I was able to reproduce the issue and it should now be fixed in 0.29.4. Meanwhile 0.29.3 fixed those Debugger issues you mentioned earlier, and also a minor layout glitch related to grouping results list items 🙂

Not seeing that on my end yet. Could you post the code you're using to generate this list, and perhaps a screenshot or list of settings you're using?

This should be fixed now in 0.29.2. The module was relying on DatabaseQuerySelect::getQuery(), which no longer returns usable queries as of 3.0.158 (or something along those lines) 🙂

So I just had a two-hour nap by accident (...) and perhaps I'm not fully awake yet, but if you are literally using "group_by option" as the option name, it should be just "group_by". Pretty much the same approach as you've got there. Unless the (somewhat experimental and likely not fully functional) "autoload_result_groups" render option is enabled, SearchEngine also adds a query param (find_args group_param, default name for this is "t"), so that the final URL is something like ?t=media&q=seagrass. The autoload option loads all groups right away, and requires some JS trickstery to get things working; I'm pretty sure that paging won't work there as expected, this i mostly something I added for the Debugger 🙂 Thanks for reporting, I'll take a closer look at these next 🙂