adrian

I didn't think about the pagination issue. I am not sure there is an easy fix for that with the current options for hooking into ProcessPageList Just out of interest though, here is a new version that uses ProcessPageList::find as the hook - it simplifies some things quite a lot, but still doesn't fix the pagination issue <?php /** * * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class HideOtherUserPages extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'HideOtherUserPages', 'author' => 'Adrian Jones', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // only add hook only if the render parameter is set // (as used by ProcessPageList) // or if superuser, also exit if(!isset($_GET['render']) || $this->user->isSuperuser()) return; $this->addHookAfter('ProcessPageList::find', $this, 'pageListHiddenPages'); } public function pageListHiddenPages(HookEvent $event){ $pages = $event->return; // make sure it's an ajax request if($this->config->ajax){ // manipulate the json returned and remove any pages found from array foreach($pages as $p) { if($p->parent->name != 'visitenkarte') continue; if($p->name != $this->user->name) $pages->remove($p); } $event->return = $pages; } } }

Glad it works as you want! If you remove that line, then you will hide all pages on your site, because there won't be any direct children of Home that match the name of the current user. One other useful variation you might want to experiment with would be to replace: if($c->name != $this->user->name) unset($json['children'][$key]); with: if($c->createdUser != $this->user) unset($json['children'][$key]); which would hide pages that weren't created by the current logged in user.

How about this: https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6 It hides pages that don't match the user's name unless you are logged in as a superuser. It is currently hardcoded to only check pages with parent named: visitenkarte Does that work for you?

Sorry about the "front-end viewing" text - that is a leftover from my Page Protector module, which this new module is based off. This module definitely only hides the page and its branch from the tree. Try it out. Keep in mind though that with this module it doesn't have anything to do with whether a user has permission to edit a page or not - it is a manual way to determine the pages that aren't visible for a user role. Did you take a look at the module at this gist: https://gist.github.com/adrianbj/e391e2e343c5620d0720 This should mostly do what you want in terms of hiding pages that aren't editable. I just haven't dealt with the issues of a page tree with many levels. It should work perfectly if there are only two levels below home.

It's all fixed in the latest PW dev version. Martijn worked out one fix, but I think in the end Ryan solved the problem in a different way: https://github.com/ryancramerdesign/ProcessWire/commit/5575ef62bb1695d98162bc3278b8d39bb66433b2#diff-995c5c9ce48d4bff459f52363c6e190eR401

I love this idea the ability to drag all fields into any template all on one screen. Also great

That would be great Peter - I think post them here - see if we can get input from everyone.

Here is a very very rough start on the idea of batch template confguration: https://processwire.com/talk/topic/8406-set-multiple-templates-role-access/?p=81711 There is a lot of thought that needs to go into doing this properly - at some point (if no-one beats me to it) I would like to build a really comprehensive tool, but not sure when I will get to it!

Sorry to hear - hope you get it sorted quickly! Correct - at the moment the new functionality is for creating new fields from the template config. As we discussed above - not sure how useful it would be to have the ability to assign fields to templates from the field config - if you want to assign to multiple templates at once, how would you order the field in all those new templates. Maybe it would be possible if you were adding the field to just one template - a modal could maybe handle this. Any thoughts on how to practically achieve what you are looking for from a UI perspective?

Ask and you shall receive! Check out today's dev commits https://github.com/ryancramerdesign/ProcessWire/commits/dev "Add Adrian's ProcessTemplateFieldCreator for quick access to create new fields in ProcessTemplate."

You can do this though: echo '<strong>"Project Managers":</strong>' . my_function($page->projects_managers) . "\r"; In words - you can mix single and double quotes in the same statement. In my theoretical example above I wanted "Project Managers" to be echoed in double quotes, then run a function on $page->project_managers, hence the concatenation, and then use an escaped "\r", which is why I switched from single quotes to double quotes in the same echo statement. EDIT: Of course you could always use double quotes and escape as needed like below, but I like the above version better: echo "<strong>\"Project Managers\":</strong>" . my_function($page->projects_managers) . "\r";

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/