adrian

@Ivan Gretsky - sorry for the trouble - could you please debug which of these conditions (https://github.com/adrianbj/AdminRestrictBranch/blob/4964a3f5b83338f7313f7c6daeefe6c6793640b0/AdminRestrictBranch.module.php#L228) is resulting in the error message? And if it's the last one, then figure out where in this method: https://github.com/adrianbj/AdminRestrictBranch/blob/4964a3f5b83338f7313f7c6daeefe6c6793640b0/AdminRestrictBranch.module.php#L236 or in this hook (https://github.com/teppokoivula/AdminRestrictBranchSelect/blob/3ac88e7f4da482a5a16dad1abe3f221fdaeb2742/AdminRestrictBranchSelect.module.php#L54) in @teppo's module it's returning "1", rather than one of the allowed branch parents? BTW - are you having the same issue with ARB without this addon module?

If I understand correctly, this should do it: https://github.com/adrianbj/TracyDebugger/blob/481a548a4d9f09784ccb1c7f598212e2923b2191/TracyDebugger.module.php#L774-L784

@Ivan Gretsky - guest a guess - are you using the correct setting in the main ARB module? Or are you perhaps logging in via a URL to open a specific branch of the page tree?

Does this help? https://processwire.com/modules/fieldtype-image-marker/ I have modified it to use the coordinates, but not show the marker on the frontend. Otherwise, perhaps you could build in fieldtype around this https://github.com/maschek/imgmap/

@rjgamer - you could of course just use a different image field in the repeater so the rules can target it separately.

@rjgamer - just did some testing and I remember now that it's not designed to handle repeater fields as separate pages like you are trying to do. I assumed that rules should be applied to all images on a page, whether they are within a repeater field or as a regular image field. It would have actually been much easier to set up the other way ? I am sure the module could be modified to achieve what you're looking for, but not sure I can do it in a timely fashion for you. I will take a look when I get a chance though. Remember that PRs are always welcome!

@rjgamer - a few things: 1) Not sure if it will break anything, but I'd steer clear of naming a field "meta" because PW has an inbuilt meta field: https://processwire.com/api/ref/page/meta/ 2) When selecting enabled pages, I am not sure it's going to work to select the actual repeater page parent (although I'd need to check to be sure). Does it work if you select the parent of the tree of pages that has the repeater field in their template? 3) It should be fine to have 2 separate rules for each of the fields - have you tried adding an extra rule to handle this?

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 ?