adrian

Well, I am still a little off-topic, but I have a new module called based on my last comment in my post above. I won't pollute this topic any further, but point you over here: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916

Hi everyone, I did a little thinking and coding on this issue last night. There is a gist on this post (https://processwire.com/talk/topic/8605-user-editsaddsmove-only-his-own-page/?p=84835) which hides uneditable pages, but be sure to read my comments in that post. And based on my comment about the issues with "is editable" checks and the need to display non-editable parents to allow a user to access editable grandchildren, here is a much more comprehensive module that allows the ability to hide specific pages (and obviously their entire branch of children/grandchildren) based on the user role. It is based off my Page Protector module so it will look familiar to anyone who have used that. It is just a first draft, so test carefully It is attached here for now. Any thoughts? AdminPageHider.zip

Looks great @mr-fan, but it is weird that: if($page->get("name={$image->basename}")->id) { doesn't work for you. It seems to be working fine here. The reason I did it that way was to only search images in the current album. Maybe that is the difference - are you wanting to ensure there are no matches in all albums - I guess that makes sense?

Take a look at the source code - it depends on the field type: https://github.com/ryancramerdesign/ProcessWire/search?utf8=%E2%9C%93&q=%22function+processInput%22&type=Code

Here is a modified version of Soma's HIddenAdminPages that hides pages that the user can't edit. It does this based on template access roles (the user's role needs to be checked for the Edit Pages or Add Children options), or the page will be hidden. It has been thrown together quickly, so please consider it a proof of concept and use cautiously. The biggest problem I see right now it that it doesn't consider template access inheritance and so will only work if you define access separately for each template. I am sure it could be improved to handle this though. The whole problem with all this is that you need to check all grandchildren to make sure there are no pages that are editable within a multi-level tree of uneditable pages - maybe it really isn't worth messing with https://gist.github.com/adrianbj/e391e2e343c5620d0720 NOTE: This does not address the OP's question, but rather the request of @guenter55 EDIT: The more I think about this, the worse it seems - there are many situations you could have pages with parents that are not editable, so you would have to show those parents, then things get inconsistent with some pages that aren't editable being shown and some being hidden. Maybe a better approach would be to have a modified version of Soma's module that allows you to hide specific pages to user roles, rather than individual users. I think this could be fairly handy. Any thoughts?

It was all due to DOMDocument which Migrator uses to convert RTE textarea field embedded image paths from assets/files/page_id/filename.jpg to assets/files/page_name/filename.jpg and back again. These conversions are actually not needed for MigratorWordpress, but are necessary for export/import from one PW site to another so that the images can be referenced by a meaningful path from the exported JSON and converted to the ID of the new page once imported to the new site. DOMDocument needs to load the html like so: $dom->loadHTML(mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8')); Without the mb_convert_encoding option, it converts UTF8 characters to entities which is where things start getting ugly. Sounds great - definitely keen to hear how that goes - 7GB will be interesting - hope your internet connection is fast! I know that Joss was testing a largish file on his local dev setup and was having some issues, although it was working fine for me. It might be helpful to up your PHP memory settings. Long term I probably need to implement some way of batching things.

Thanks for wanting to help with this, but I just managed to fix it - talk about approaching things all a** backwards. It was a very simple problem and not at all related to what I thought. I should have clued in when I read Ronnie's original analysis of things: Anyway, it should all be working fine now - please let me know if anyone notices any further encoding problems! You only need the new version of ProcessMigrator, NOT MigratorWordpress.

Hey @kathep You just need to use: $item->title etc, rather than trying to get each different item from the original page field array. You are already accessing each item inside your foreach loop. Does that make sense?

I guess I don't understand why the look is different to a standard PW images field - ie opaque and not covering the image - I think it is important to see all the image. Thanks for looking into these things Martijn!

Good point - sorry I had seen that - I was confusing list view with thumbnails displayed vs grid/thumbnails view. I think it works as you have it, but I think things look a little ugly in list view when you don't have the field set to use thumbnails, but rather the full sized version - maybe that is why I am getting the image centered and overlapping the info bar above? I am just using the standard default theme - PW 2.5.13 Probably doesn't matter in the popup for the grid view, but in the list view I think it would be more obvious for users, but not a big deal.

Hey guys - I have just started using this and have a couple of issue: Notice the way the image is transparent over the grey info bar? In thumbnail view, the crop button is not showing. Also I have two croppable image fields and toggling the thumb/list view buttons on one change the view on the other - not sure if this is related to croppable image or not though. One more thing - might just be me, but I'd prefer to see the crop buttons just below the image - ie, above the description and tags fields. Thanks!

Looks like you aren't doing the correct thing here. I am not very experienced with cPanel, but you don't want to be forwarding the email to the PW link. You need to set up a cronjob (from cPanel) using that format that @cstevensjr showed you. That cronjob will then periodically check the email address. Does that make sense?

Nice job on the configurable fields I have just committed an update that I think fixes all the issues you were having and also changes the selections for the config settings to use FieldtypeSelect and limits the options to templates and image fields as appropriate. Let me know if it works as expected for you.

Try this: wireMail('my@email.com', 'some@email.com', 'Message Subject', 'Message Body'); or $mail = wireMail(); Also, make sure your php mail function is available and working - likely it isn't on a local dev machine. So install and set up one of the SMTP options: http://modules.processwire.com/modules/wire-mail-swift-mailer/ http://modules.processwire.com/modules/wire-mail-smtp/

Sorry, I might be missing something obvious, but can you explain the issue with directory paths and why you can't use this module?

I just updated the gist with a version that deletes the images from the original parent album page. Let me know if that works for you. It's kinda funny that there has been quite a bit of interest in this, but not from the OP

Just wanted to let everyone know that thanks to @Sephiroth we now have support for comment migration - you'll need to grab the latest commits for both Migrator and MigratorWordpress! Next on my list is custom fields ...

I think you can still use this module to set up the page field and the Parent / Child A / Child B components of the tree, but to get the grandchildren: child A1 etc, you will need to add those by some other means - either manually or via one of the modules I mentioned. Remember that this module is just a shortcut method for creating Page Fields and their linked pages. You should still understand how they work and also realize that once created, all settings and content pages can be manually adjusted. Does that make sense?

I am having the same problem and it is affecting other modules too: https://processwire.com/talk/topic/4865-custom-upload-names/?p=84264 Not sure if it is relevant, but my 2.5.14 is not a fresh install though.

This is affecting certain other modules too - https://processwire.com/talk/topic/7588-admin-custom-files/?p=84276 I'll see if I can find some time later to figure out what changed and see about fixing things, either at the module side, or a core fix from Ryan.

Hi Maverick - these are two different issues. You must of course add svg to the list of valid extensions, but the problem reported above is related to SVGs that don't have their width and height set. Illustrator CC has added an option to make SVGs responsive which leaves off these attributes. I have submitted a PR for a fix for this issue, but it hasn't been incorporated yet.

Page Field Select Creator is not designed for adding multiple trees of parents/children/grandchildren. Are you actually setting up a page field, or do you just want a quick batch way of creating these for general content? If the latter, then take a look at these modules instead: http://modules.processwire.com/modules/batch-child-editor/ http://modules.processwire.com/modules/process-batcher/ If the former, can you please let us know your use case in a little more detail.

Just wanted to confirm that the: // make sure the value is of type Pageimages $obj_field->attr("value", new Pageimages($this->page)); fix also works for me. Thanks soma!

I can confirm you're not going crazy, and apparently neither am I (I wasn't sure at the time ) I saw this about a month ago, but now don't remember what I was doing at the time and I have no idea how to reproduce it!

I don't think (not positive) this is actually meant to be possible - I think this is by design - I actually get a message saying "You don't have access to list page X" when I try to click on a page to get the view/edit etc links. A couple of options for you - neither of which is really what you want, but might be useful Draft Creator: http://modules.processwire.com/modules/process-page-draft/ Page Protector: http://modules.processwire.com/modules/page-protector/ The first module should be self-explanatory. Regarding the second module - the workflow with this would be to publish the page, but protect it (also from the settings tab once the module is installed) - that way the view link will be displayed, but it won't be viewable by any guest user. You would probably also want to set it hidden so that it wouldn't show in the menu / searches etc. Sorry, neither are ideal for your needs If you want something closer to your original request, then you might need to some fancy hooking, unless I am totally wrong and missing something obvious