adrian

Hey chrizz - great job! Given all the ex-MODx'ers around here, I wonder if you'd be willing to share your migration script? Also wondering if you might be willing to adapt it so that it works as a plugin to Migrator like Nico's Wordpress Migrator. This might seem selfish as it would have my module get more use, but the main thing I am hoping to achieve is to help migration from MODx to handle image migration as well. Looking at your site it looks like you have manually dumped all the images into one (or maybe a few) /site/assets/images/ folders, rather than into the page's numbered assets folder which of course means that the images won't be accessible via the page edit images field etc. Migrator/MigratorWordpress takes care of all this which I think results in a better end result. Please don't take this as a criticism - just trying to see if we can end up with a more complete approach for those wanting to migrate from MODx. Anyway, please let me know if you'd be willing to help with a MODx plugin for Migrator - I would be very keen to help you out with it. Thanks again for your write up on your successful conversion!

I haven't had a chance to play with this yet, but I know it will be used on an upcoming site - just wanted to say how great it looks and most importantly how impressive the documentation looks to be - love the use of Github wiki!

Steve - thanks for the module - it has proven very useful, however I wonder if you'd consider having multiple rules so it would be possible to redirect some roles to one page and other roles to a different page, etc? I might end up making the changes myself and submitting a PR if you don't have the time to tackle it, but hoping you might

Don't you still want to hide the main page tree and redirect them to them to your Form Result Process Module, or did I misunderstand? Anyway, that is what the module from netcarver, wanze, and kongondo will do - of course you still need to assign the permission to view the page like Jan showed. Actually, re-reading your first post now, maybe you didn't want to hide everything else at all - maybe my 3000th post wasn't helpful at all - oh well, can't win them all

This module works perfectly for exactly that scenario: http://modules.processwire.com/modules/admin-restrict-page-tree/ PS Not exactly an earth shattering 3000th post (how time flies when you're having fun), but hopefully helpful anyway

Not sure if it suits your needs or not, but: http://modules.processwire.com/modules/process-changelog/ Also, check out isChanged(): http://cheatsheet.processwire.com/?filter=ischanged

Not sure if the first line of your first post is a question or a statement , but renderItem(): https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Fieldtype/FieldtypeComments/InputfieldCommentsAdmin.module#L33 and render(): https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Fieldtype/FieldtypeComments/InputfieldCommentsAdmin.module#L88 are hookable, so it shouldn't be too hard

If I understand correctly, there is no need to hook - just don't use the built in render method, but instead generate the output yourself. http://processwire.com/api/fieldtypes/comments/ and scroll down to the "OPTIONAL: Generating your own output" section. Does that cover your needs?

Hey Macrura - nice looking site! One minor thing - the navigation-divider.png looks a little weird to the right on the selected menu item. If I disable it, that little black line goes away and looks better. I understand it looks good between the unselected items, but it does look weird to the right of a selected one which is green. #navigation ul li a { display: inline-block; color: #fff; text-decoration: none; font-size: 13px; font-weight: 500; padding: 17px 25px; background: url(/site/templates/centum/images/navigation-divider.png) no-repeat right 50%;

There is also this lorem ipsum module for PW: http://modules.processwire.com/modules/markup-loren-ipsum/

You can't assign the parent like that - you need to provide a page object - something like: $p->parent = $pages->get("/blog/"); You should also get into the habit of setting outputformatting off before saving a page: $p->of(false); Correction - even though the above approach works just fine, apeisa's way of assigning the path to the page also works, so my comment about needing a page object is actually not correct!

@Raul It looks like this module hasn't seen any updates in a long time and the author doesn't appear to have a forum account (under the cnsknight name anyway) and there is no official support thread for it. I think your only option might be to post an issue over at github and see if you get any response.

You also might find this module by soma very useful: http://modules.processwire.com/modules/chrome-php-logger/ It logs lots of useful info to the console, including: "current page with all its fields and their value and field settings" I think this will be the easiest option for what I think you want.

Wow - how did I miss (or maybe forget about) this - thanks That works perfectly! PS Sorry for hijacking your thread here @justb3a

I was a little confused at first too and thought it might work to generate dynamic/conditional dropdowns like you are describing with the Europe countries example - actually that is a field type that I think would be nice - I have been thinking about it the last couple of days actually What this relation fieldtype does is create a dropdown field that lists the entries for the selected field from all the matched templates/pages. The option value is the ID of the page that has the entry. Clear as mud right Maybe you just need to try it

Thanks for this - I think it will come in very handy. Just a quick note though - looks like you did a find/replace just before submitting, because there are several instances of "FieldField" instead of just "Field", eg. $chooseFieldField and instanceof FieldFieldtypeRepeater - this is preventing your attempts for excluding a bunch of field types from the list of available fields. PS I'd love to see support for Profields Table subfields

Sorry - not sure what you mean here - changes from when till when? Sorry, now I think I am the one having the blonde moment

Actually, I think you are right. Although there might need to be a slight variation on that, depending on the WP source format. I hadn't ever looked at the canonical link info, so knowing that is set up correctly, I guess we don't need to worry about those ID based links - guess there really isn't much to do afterall PS the "k" man beat me to moving this thread!

Well it's just that WP URL's often have the date in the URL and there are a few different format options. Of course this could be replicated in PW, but typically it isn't, so I was mostly wanting to redirect from the pretty WP format to the PW format.

Hey Mike - any thoughts of making is possible to add redirects via an API call. After the discussion this morning about imported Wordpress rewriting (https://processwire.com/talk/topic/8869-wordpress-url-rewrites/), I would like to add this functionality to MigratorWordpress so that rewrites are automatically added. Obviously I can do it through SQL inserts, but thought an API method would be nice.

I am not sure on this, but I wonder if Page Path History can handle that URL format? Have you thought about using the Redirects module (http://modules.processwire.com/modules/process-redirects/) or the new Advance Redirects / Jumplinks (https://processwire.com/talk/topic/8697-alpha-processadvancedredirects/). I am also curious how you did your import. I am thinking of adding redirect support to the MigratorWordpress module (https://github.com/NicoKnoll/MigratorWordpress) and will probably use one of those two modules to do it. I would want to add both the ID based and SEO friendly WP links as redirects - any thoughts?

Thanks for this - looks like it has great potential, but at the moment, you have these errors: Warning: stripos() expects parameter 1 to be string, array given in /site/modules/FieldtypeImageExtra/FieldtypeImageExtra.module on line 229|230|231 which break the image upload due to outputting header content before the image during the ajax upload with PW debug set to true. There are also some layout issues if you disable the orientationField - the Link field only takes up half the page width. I had the same issues as Joss, but switching the field type did the trick!

If anyone is getting this issue with images not properly uploading in PHP5.6, make sure to set: always_populate_raw_post_data to -1 in your php.ini file. The deprecated notice is causing header issues with the ajax uploader. Hope that helps someone else out

That was my doing Martijn - since it's hooking into SaveReady, I thought that "Before" was actually appropriate in this case - it's certainly not renaming after save, otherwise we'd have to save again - right? I certainly don't see any harm in using the true option and I think it should generally be safer for page names and how you are generating them.

Glad it's working, but I would suggest adding the "true" back into the pageName sanitizer. From the docs: "Sanitizes a value for a URL friendly Page name and cleans out leading or trailing dashes, and converts double dashes to single dashes. Use this if you are passing in a headline to convert to a page name (for example)."