adrian

https://github.com/processwire/processwire-issues/issues/1345

@ryan - sorry to keep hassling, but I am wondering about your thoughts on my idea for a referencesRaw() type method. You gave my suggestion a like, so I hope it's on your roadmap. It will be invaluable to me now that we have support for getting the URL with "raw" finds. As an aside, would it actually make more sense to add a "references" selector to find() / findRaw(), eg: $pages-findRaw('references=1234')

Hi @teppo - thanks for the update. I was a bit confused about how to get the update to trigger. Turns out I had to visit the settings page for the ProcessChangelogHooks module and then I got the notice and the update worked as expected.

That "partial" matching was the bit I didn't understand - the module description doesn't make that clear so I never figured the limitation without it. I assume this doesn't break any existing features - just means you can't do partial match selectors on ML URLs, rather than breaking them completely? I see your point - I hadn't considered the raw and unformatted nature of it, but I still think it feels weird to be dealing with arrays in data coming directly from PW methods, but it's not a big deal.

@ryan - also, do you have any thoughts about this request - something you think makes sense, or are you not willing to consider it? Thanks.

Awesome @ryan - thank you! Can you please explain: 1) How PagePaths actually improves / changes searching by path in selectors 2) Is there any significant overhead having it installed, ie why isn't it installed by default? Thanks!

Hi @bernhard - yeah, thanks. I never really looked at the PagePaths module except for really early on in my PW days - it didn't seem like it solved a problem I had. It's description says: "Enables page paths/urls to be queryable by selectors" but we already query a page by it's path, eg: Then I installed PagePaths and it didn't seem to significantly speed up the query, but maybe I need to test on a site with a lot of pages. I understand that for my request for returning the URL via findRaw() that the pages_path table should make this possible (and very performant), but is there something it can actually do in terms of selectors that I am not understanding?

Hi @bernhard - thanks for chiming in, but I'm afraid I don't really understand what you are responding to - is it in response to my comment just above, or to @thetuningspoon or ? That said, I am curious what your extension to PageHitCounter actually does - I'm a bit confused about your description as well. Sorry, if I am being a bit slow this morning ?

That's what it says in the title of this request: "or maybe a findOneID()" ? I completely agree that getID works as it should. I think that perhaps has() is a confusing term given what it does - it's hard to know by its name whether it will work like a get or a find (ie with exclusions or not). But, we also clearly agree on that ? Request just posted: https://github.com/processwire/processwire-requests/issues/394

Hi @Kiwi Chris - I haven't ever seen that which is strange. Would you mind doing me a favour and reporting that here: https://github.com/parsecsv/parsecsv-for-php/issues Thanks!

Just an observation, thanks to Tracy's Selector Queries (Debug Info panel), both the has() and getID() methods use the same query.

Use the type "markup", which will accept HTML eg: 'name' => 'docs', 'label' => 'Docs', 'type' => 'markup', 'value' => '<strong>TEST</strong>'

Hi everyone, Does anyone know if the idea of a $pages->has() that doesn't return unpublished, hidden, trashed pages has been discussed anywhere? Currently, has() works like get() but I would like to see it work like findOne() - ie one result, but with the exclusion rules in place. I just don't see many uses for has() in its current form. Based on these tests, and the fact that has() and getID() have basically the same time execution time, even a findOneID() would work. Any info on this would be great, otherwise I'll add it to the Requests GH repo.

@ryan - I just discovered that findRaw() won't return the "url" field. I suppose that is to be expected given that it's not a DB stored field, but rather calculated at runtime, but it does still somewhat limit the functionality of findRaw in LOTS of useful situations. Do you think it would make sense to support this, or would it just slows things down too much? The other thing is I am wondering if you'd consider an option to return a standard PHP object rather than an array? It would make it so much easier to switch between find() and findRaw() Thanks.

And it would be great if @David Karich could update Page Hit Counter to use it.

Just a tip - I replaced the "Page fields to search" setting in the PW core Page Search (ProcessPageSearch) module to use the search_index field. It seems like a great alternative when you want to have the admin live search find pages based on the content of lots of fields (not just title etc).

Hi @MoritzLost - I assume you are using PHP8? This used to be OK on PHP7, but 8 seems to have become more strict about blank vs zero. It should be fixed in the latest version.

@jon9china - I have tried your step by step and can't reproduce the error yet. I am wondering what version of PW you are running? There was a very long-standing circular reference bug in the PW core related to page reference fields that was fixed here: https://github.com/processwire/processwire/commit/8dbff5c7bc367e805badf51204b4e31123cf9b6e - so basically you need to be running at least 3.0.166 to have that fix in place. Please let me know the version and if it is later than that, then I'll investigate this issue further.

@jon9china - thanks for the explanation. I think I sort of understand "They were looking for the page that identified the restricted user that was logged in", but if you could provide the selector code you are using it would be helpful - perhaps I can implement something into the ARB module so that you can still use the selector the way you want, rather than changing to the email field. So if you could post the old and new versions, I'll try to replicate and see if I can fix it somehow.

Hi @aComAdi - sorry about the problem with Tracy. You know, this is one of those strange things I have seen with Tracey on and off over the years. I actually just came across it again today, for the first time in a long time and @Robin S just PM'd me about it as well. In his case, it was the Field List & Values section in the RequestInfo panel, which once disabled fixed it for him. For me it's when an image called on the frontend is not available. The weird thing I've noticed in the past is if I load all Tracy panels, then the problem goes away. I'd like to finally get this sorted out though. I thought I was the only one ever seeing it ? I'll try to take another look soon, but I'd like to know if disabling the Field List & Values section fixes it for you, or if it is related to a missing image. Thanks for your help in narrowing this down.

@jon9china - sorry you're having problems with the module. You could please clarify what you mean by "the user restricted branch setting" ? Are you talking about the "User Specified Branch Parent" option for the "How to match user to branch" setting? Do you have the same problem if you use one of the option ways to match the branch? I can't replicate the problem here, so I am wondering if you might have some other additional hooks (custom or in a 3rd party module) that are also controlling access. It sounds like you are running out of memory due to an infinite loop. If you can narrow it down to some other code interaction that will help. If it's not that, would you mind trying to debug this module to see where it might be goin awry? Could you also post your other settings for the module? Also, is the error only when viewing the admin with a restricted user?

Thanks @teppo - hooking into Renderer::renderResult worked great! Gotta say, this is a really well thought out, and well coded module. Cheers!

Hi again @teppo - I am looking to include an image for each result. The key thing is that I want to show a thumbnail version so I want to be able to call PW's size() method on the image object, rather than simply using {item.images.first.url} I think there are probably a few different ways to accomplish this - maybe by doing a str/preg_replace on the rendered results, or maybe hooking into one of the render() methods within your module, or perhaps doing a completely custom rendering of results, although I am currently not sure how to show the _auto_desc when doing a custom render. Is there a trick for this? Otherwise, I wonder if this is something you think might be a good feature to include so it's easier to do this via the standard renderResults() method? Thanks for your thoughts / ideas.

HI @Matthieu - I've just added support for the MapMarker field type. Please update and let me know if you find any problems.

Hi @teppo - I've noticed a few issues with apostrophes when searching. The first issue is perhaps not something to can easily fix if you rely on PW selectors to do the search, but it is a shame that omitting an apostrophe from the search term results in no matches. The second is more fixable - notice how the results don't include the _auto_desc when you enter a search term with an apostrophe. The second screenshot shows the same returned results, but this time I searched for the phrase without the word with the apostrophe and the _auto_desc is included as expected. The final thing I noticed is that when the search term has an apostrophe, input->get->q ends up being empty. I was using it to populate the search input field so the user gets the results page with the search populated with the phrase they just searched for. Thanks.