adrian

@teppo - this sounds like a pretty decent solution. I wonder if it might be something that could be incorporated into the ARB module as a feature. Let me know if you'd be willing/able to share the code at some point, or even better if you would be happy to incorporate into ARB as a PR.

I'd still recommend backing everything up before-hand, but it should all be ok. If it's a critical website that can't have any downtime, I would also suggest making a copy and upgrading that just to check there aren't any issues, especially with third party modules.

I migrated a 2.3 site directly to 3.x without any problems.

@CliffG - I'd also suggest it might be time to upgrade to PW 3 ? - it's usually just a simple upgrade of the wire directory (.htaccess and index.php files). Rarely does it require anything more.

There have been some stricter settings in general in the policy.xml in recent versions of Imagemagick, some to protect against ghostscript vulnerabilities (https://askubuntu.com/questions/1127260/imagemagick-convert-not-allowed) so it's probably a good time to get familiar with policy.xml (https://imagemagick.org/script/security-policy.php), although I must admit I have starting using command line tools for PDF stuff lately, eg: pdftoppm and pdfinfo - sorry, getting OT.

This post should get you up and running again: https://processwire.com/talk/topic/18341-mysql-group-by-error-help/?do=findComment&comment=160359

Hi @sandimilohanic - unfortunately that's just not possible with the way this module works. Restricting to one branch in PW is relatively simple (what this module does), but restricting to more than one requires a completely different approach which is a little more fiddly. Perhaps you can build exactly what you need (without the need to be flexible like a publicly released module has to be). This gist might be a helpful starting point: https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6

Here you go: https://github.com/adrianbj/PageEditSoftLock Good luck actually uninstalling that System Notifications module - it's a persistent little bugger and IMO it should be removed from the core immediately - it gives a bad impression for anyone who tries it.

Hi @szabesz and @ryan - it's interesting to me that no-one else has mentioned that this is missing from the directory. I think it's an essential module for any install. As far as I know, it's the only way to prevent users from accidentally overwriting each other's edits. That said, I think this is the sort of functionality that really should be in the core. I have made some other additional changes to the module - it now also fires on "onbeforeunload" so that pages are released as soon as someone stops editing them. I got tired of telling clients that they had to wait for the page to be released after someone else closed it. I am happy to share this version, but I still think it should be core functionality.

That is a really nasty bug - apparently it didn't affect many users but it affected several of my sites - not sure what that says about me, but I am definitely glad it's fixed because I was hacking around it for a couple of years there.

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?