teppo

Great — let me know if you run into any trouble and I'll be happy to help! If you mean which file, for this purpose (saving pages in the admin) you could put the hook into site/templates/admin.php, but site/init.php is likely just as good (and also catches page saves that occur outside the admin).

Thanks! Currently "id", "name", and "title" are indexed automatically for page reference fields. If a programmatic approach is easy enough, you can modify this behaviour and add more fields by hooking before Indexer::getPageReferenceIndexValue() and modifying the $indexed_fields argument. Alternatively you could hook into this method and in specific cases replace the behaviour completely, for an example by returning the output of the indexPage() method for each individual page instead (here's a loosely related example). Let me know if you need additional pointers and I can provide some sample code.

Seems reasonable. In fact I had similar issues earlier, but those were fixed by switching from substr() to mb_substr(). This case seems a bit different, though. I'll try to set up a test case and see what I can do about that; so far I've only managed to end up with a partial encoded entity, 80& instead of 80' and so on ? Meanwhile I noticed that in some cases the new auto desc feature generates odd looking "......" character sequences and other weird results, so there's more to tweak anyway. I'll try to dedicate some time to this in the next few days. Just to make sure: did you mean HTML Entity Encoder?

I'm not Adrian (obviously), but from my side things seem to be running smoothly now. Been running a bunch of my own sites on PHP 8 for a month or so. As long as you're using the latest dev version, that is — I ran into some bugs in current master that I'd consider showstoppers, though can't remember exact issues. I think one was somehow related to image sizer, at least ? New minor issues still seem to pop up, such as this one from a few days ago: https://github.com/processwire/processwire-issues/issues/1363.

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 ?

Thanks @adrian! First one was a PHP8 issue, while the second (and bigger) problem was related to fulltext index queries. Both should now be fixed in version 0.29.1, though please let me know if it doesn't work for you. Also: I had accidentally grouping by template enabled by default, this is now disabled by default.

Took a lot longer than anticipated to get this out of the oven, but version 0.29.0 of SearchEngine was just released. Word of warning: this is the biggest new release for the module so far (in terms of features as well as changed lines of code) so please test carefully! Main features included in this release: New group_by option in find_args. For now only supported values are null (default) and "template", the latter of which (obviously) groups results by template. Here grouping means two things: first of all results are rendered in tabs on the front-end, and second of all instead of a single Query object the module instead returns a QuerySet object, which in turn contains multiple Query objects. New results_grouped_by option in render_args. This accepts any field name, page property, etc. and essentially divides found results into groups by said field value / property. For an instance if you specify "template.label", you'll get a list of results with subheadings for templates. While both of these options are related to grouping results, they work on an entirely different level: group_by performs separate SQL queries and splits results into their own Query objects, while results_grouped_by is something that only affects the render phase (front-end). It's also possible to combine the two, in case that makes sense ? There's also a new custom sort setting "_indexed_templates" (results are sorted by the order of templates in the "indexed templates" config setting) and new argument "pinned_templates" for the find() method that will show results with provided templates at the top of the results list.

I'd say that these are more like two sides of the same coin: You've solved the file issue by directing static file requests to CDN and pointing file related requests to a single (?) master instance. This is of course a valid approach, but in this type of setup you've got at least two types of instances (read and read-write), which can make things more complicated than just replicating a single instance type based on the load, and may not work so well for sites that often require direct access to assets. This could also potentially impact fault tolerance: in case you indeed only have one write instance, that going down for any reason would be a big blow. Most cloud setups I've worked with have handled this the other way around: files offloaded to external buckets and database shared among instances. One benefit of this is that those instances are identical, there's no "master" to rely on. In most cases S3 hasn't had major impact on performance (plus there's always CDN) and I've never run into a case where database would've been an absolute bottleneck. Of course DB requests should be limited: most web requests can be served from static cache, and if advanced caching is needed, in comes Redis. The long story short is that I believe core level ability to store files somewhere other than local disk would be a splendid improvement for cloud use. It's true that you can get past this and it's not strictly necessary in order to run ProcessWire in the cloud, but it would simplify things quite a bit. That being said, I definitely get what you mean by this being the more complex part ? Also, just to be clear, I think that the database abstraction is a great addition!

Also interested in this. My impression is that offloading assets to Amazon S3 / Google Cloud Storage etc. is a relatively common need, and there's currently no bulletproof solution. Some third party modules have attempted to, but I'm not sure if any of them really solve all the related needs (image management etc.) — and while remote filesystems such as EFS are easier to work with, they also come with certain downsides (such as a higher price point). I seem to recall that Ryan mentioned something about this a while ago too ?

Doesn't sound like you're missing anything, and yes — the module should automatically redirect the user to the first branch configured for them. So far I've been unable to reproduce this issue. Just in case I installed a new ProcessWire site with only default site profile + AdminRestrictBranch + AdminRestrictBranchSelect, and everything worked as expected. Following the suggestions Adrian made above should give us a better idea of what's going on, but one more thing I'm wondering is that what version of ProcessWire you're running? The module should work on 3.0.123 and above, but I've only tested it on 3.0.165, so it could have something to do with that. It kind of sounds like AdminRestrictBranch::init() might run before AdminRestrictBranchSelect::init(), or the latter might not run at all; either would at least explain the error you're seeing. A simple way to test if this is happening would be adding some debug code (bd(), or just die() with some sensible message) in both methods and seeing which gets executed first (should be AdminRestrictBranchSelect::init()).

Yes ?