adrian

Hi @bernhard - have you tried the "Clear Session & Cookies" option - I think that does what you are looking for.

@MarkE - this looks really very impressive - looking forwarding to testing it out! @Kiwi Chris - that's one of the things that my ancient Migrator module handles - it takes several loops to correctly install required fieldtype modules, create fields (including any required page reference page trees, as well as any new fields they might need), templates and pages such that all dependencies are satisfied in the correct order. This stuff is all pretty painful. Definitely curious to see how @MarkE has handled this.

Just did a quick test and it looks great - thanks for sharing this - I think it will be a great solution for many folks.

Hi @fisnik - I am sorry I don't have time to look into this, but if you dig into the MigratorWordpress code that parses the xml you should be able to grab the feature image (if that plugin is adding it to the xml). Looking at your other post on the CMSCritic thread, it looks like you are also considering the approach used there - maybe that's a better option for you?

@Mackski - take a look at the "Copy or Move Repeater Items to Other Page" action in the AdminActions module. What you've done may work for some repeaters, but won't handle images if there is an image field involved.

@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')