adrian

Ok, I went a wandering into the comments fieldtype code and discovered it was because the schemaVersion setting for the field was set to "1" whereas it should be "6". I've made that change and it seems to be working fine now. As to why it was set to 1 and not 6, I have no idea - maybe someone else will come across this and it will help them to solve it as well.

@ryan - I just tried working with this for the first time and the issue I am having is that I don't want to prevent guests from viewing the page, but I want to prevent them from being able to view the PDF associated with the page. Of course, the first level of protection is to simply not show them the link to the file, but if they were given (or guessed) the direct url to the file, I don't think I can actually use pagefileSecure and this new approach to block access, or am I missing something? Perhaps pagefileSecure needs to have an optional permission, eg 'files-view' or something like that - I think that would allow much more flexibility in controlling access to files without relying on access to the page they are stored on. Does that make sense?

Sorry, do you mean the latest master (3.0.165), or the latest dev? The latest master version does not include the circular reference fix I am talking about. If you are using a dev version from anytime this year, the bug should be fixed, but without clarity on that, I really can't help much ?

@teppo - it would be great when using the %= operator if the auto description could also show the separate words where they appear, rather than showing no text at all. Does that make sense? Thanks.

Thanks @kongondo - sounds like I'll have to investigate a bit further to see if I can narrow it down and possible file a bug report.

Hi, Has anyone else come across an issue with the approval link in the comment emails? The message is: "Invalid comment code or code has already been used" but the problem is that no code or subcode was ever created in the DB table. I am seeing this on all comments on a new site I am finishing up, but looking back at another site using the comment system I see that sometimes no code was entered there either. I thought it might be related to logged in users, but even guest users don't get the code and same goes for users without already approved comments. Anyone also seeing something like this?

I always use this approach: $this->wire("siteSettings", $modules->get('SettingsFactory')->getSettings('settings')); and it sets it just fine. I put it in init.php

Hi @fisnik - I am glad to hear the import when reasonable well. I also just used it a few weeks ago - it's strange to me that it doesn't seem to see much usage. Sorry about the ML issues. I have never seen the xml export of a ML wordpress site so I don't know the format, but it sounds like they are separate entries. I am sure this is doable but it will either require some modifications to MigratorWordpress to combine ML posts by ID before generating the JSON for the pages to be imported. Alternatively, you could probably write an API script to match the posts that are separate pages and pull the content to the default language version page, save that, and then delete the other language version. It depends on whether you can match the two pages - the old WP post ID would be ideal but MigratorWordpress doesn't import that is so you'd also need to handle that I think. Should definitely be doable, but I am sorry I don't have time to help at the moment, but happy to answer questions if you get stuck along the way.

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.