adrian

Ok, there is now a new config option that needs to be checked to show the action code. On an unrelated note, I also revamped the recent $noBackup option. This is a breaking change, but now you can set: protected $dbBackup = 'automatic' (or 'optional', or 'disabled') in your custom actions to override the default behavior as defined in the module config settings. Hopefully this will be a helpful change.

Ah, you're right - sorry about that - shouldn't do things in a rush. I think I am going to remove that option from the module completely. I'll see if I can find some time to answer the issue of hiding menu items another way in your other thread. It is only visible for superusers - is it still an issue for you knowing that?

Here's a JS demo: https://jsfiddle.net/abdennour/oh3jL82j/ Not knowing your exact scenario, but I think a purely JS solution would be better unless you have a LOT of children that you are doing the getRandom on. If you really want to go the AJAX route we can help you further, but it's really a PHP issue, rather than PW so googling around would be pretty helpful. The only catch with PW and AJAX is that the URL for the ajax request can't be directly to a php file in /site/templates - the file either needs to be outside /site or you need to assign the file to a PW template and page call the url for that page. Sorry for the short answer - I am a little rushed at the moment.

@jmartsch - I wasn't finding an easy solution to your menu problem (maybe just not thinking straight), so I added a new option to the AdminActions module. If you create a new permission: "admin-actions-hide-menu" and give that to those roles that you want to allow actions, but not via the Setup > AdminActions menu. Remember the user will need to logout and back in again to clear the cache of the menu. Let me know if it works ok.

Because your click action is client side (javascript) and the getRandom is server side (php), you will either need to get all the options initially and do the random filter using javascript, or you would need to do an ajax call on each click and return another set using getRandom. Does that make sense?

Listers are real pages - take a look - see the "Test Lister" at the bottom? Just move to directly under "Admin" Ok, so I guess it's back to the drawing board Let me take a look at your hook code and see if I can get it working for you.

Hi @jmartsch - good idea - I have changed it so that message is only displayed if there is no custom message defined. As for using $this->message or $this->error - I don't see any reason why you can't already use those if you prefer - please test and let me know. The reason I went with the other approach is to allow for a larger and more obvious response than the standard PW message/error interface provides. If you need any additional tweaks on this front, please detail them out for me. I didn't spend a lot of time on this part of the module because it was initially designed for superuser use, although I am myself starting to make actions available to other roles, so I would like to improve this experience. Cheers, Adrian

If I understand correctly you want to hide a parent menu item (Pages) but display one of its children (A Lister Pro page)? The only solution would be to move the Lister Pro page directly under the "Admin" parent in the page tree. Then you can go about hiding "Pages" without any problems.

@jmartsch - I feel like the easiest option might be to just make the Admin > Setup > Admin Actions page set to "hidden" status.

Welcome to PW! Use the autocomplete inputfield: http://modules.processwire.com/modules/inputfield-page-autocomplete/ Let us know if you have any problems with it.

Hi @jmartsch - glad you figured out the hidden type and glad you are finding the module useful

Ok, I went with a different fix for the UiKit admin theme sidebars that works with the current version of PW and the UiKit theme. If sidebars are enabled, the Tracy debug bar is attached to the main iframe. Please let me know if you notice any issues.

@MilenKo Ok, just committed new versions of Migrator and also MigratorWordpress so be sure to update both. Comment dates now working and also fixed an issue with comment status from last commit. I'll look into the comments/tags and homepage issue tomorrow - gotta run

Thanks, but I am certain this used to work fully, so I would like to get it back to that state. I have the comment date sorted out, but am working on a couple of other things and have to head out shortly, so probably won't post until tomorrow, so will look again at categories and tags.

Thanks @MilenKo - I'll take a look at the comment timestamp issue tomorrow. Could you please PM me the new XML with just the posts. I might also look at working with the full one - we'll see. How did you go with Categories with just the posts in the XML?

@MilenKo - thanks for all those details. I have pushed a new version which fixes that eq() error. I finally did a full import of your file and I think I now know why you are having troubles. Your XML is for the entire Wordpress site. I have only ever used this to migrate blog posts. I would suggest that you create an XML export of just posts (I think that's an option). I think that will probably take care of the homepage renaming issue, as well as the categories and tags problems. It's all about the pages being relative to the correct parent and when you import pages and posts at once, it messes that up. Obviously this should be fixed, but I think that for the moment if you do this, you'll get a complete import of all posts - fingers crossed

Perhaps you have checked one of these two options in the settings for this module: Prepend site's root path to local/relative URLs? Allow relative/local URLs without "http://" at the beginning? Either of those will break the lookup of the page for getting the title. But again, Page Reference is much better for local links - one of the key reasons is that is stores the page ID which never changes, rather than the URL which may possibly break down the road.

@sms - I don't know why that code isn't working for you - it's fine here. Is this live somewhere we can look at? That said, I do think a Page Reference field is more appropriate for your use case.

@sms - if it's a local page, then you can get the title of the linked page with: $pages->get($page->AssistedURL)->title; But you might be better using a Page Reference field because then you could do: $page->linkedpage->url; $page->linkedpage->title; If there will be some external links, then maybe a Repeater field with URL and Title fields might be the best option.

For anyone who tries out the new sidebar features in the UiKit admin theme, I just wanted to mention that I already have a partial fix (not committed yet) for the problem of the debug bar appearing in each sidebar, along with the main content area. Each sidebar (and main content area) is an iframe, which is why the debug bar gets loaded in each one. The fix I have works for the initial page load, but falls down when you try to edit a page. I have suggested a change to the core/uikit theme to Ryan (in a PM) that will allow me to fix this as well, but I need him to implement first. I'll update Tracy as soon as there is a fully working solution. Cheers, Adrian

Hi @ryan - spreading my feature suggestions around at the moment - sorry What do you think about having a simple and more obvious way to replace the Page list in the main frame when the sidebars are displayed. I know we can do this other ways, but I feel like this will become a more sought after thing now. For example, for some sites I think it would be great to point to a ListerPro view for example, and I am sure there are lots of other possibilities now that the page tree doesn't have to be the main initial view.

You could hook into Pages::added, check to make sure the page has the user template and then create your own logic to notify the admin - eg send an email.

Anything hooking into Page::viewable ?

Sorry - I didn't notice that in your code example you were already using include_once - it seemed like that was the obvious reason for the issue. You shouldn't have to turn off the file compiler to get things working - it takes care of things if you're not namespacing your template files. There must be something that is declaring that function more than once, but if you are certain that all calls to it are using include_once, then I would start by clearing out /site/assets/cache/FileCompiler

Probably just a matter of using "include_once" or "require_once" instead of "include". There are several way to prevent PW's file compiler getting involved - do you actually need it off?