adrian

Hey pwFoo, Just a couple of things - it isn't possible to install your module directly from the modules directory because the bitbucket link doesn't work properly. FormHelper did download and install automatically though, so maybe you just need to tweak something with the url to your module. Next thing - I installed and put: $fcm = $modules->get('FrontendContentManager'); // edit page (editable permission needed) echo $fcm->edit($page); in a template file, but nothing was output and I was logged in as a superuser. Am I missing something obvious?

Hi Marvin, I love it, although I am surprised you got a like from Antti on this, given his dislike for changing the url after the page has already been created I wonder if it might be nice to have an option to determine whether the rename will happen only the first time the page is created, or if it can change every time the page is saved (the current behavior). Just a thought - if you could check to see if my PageRenameOptions module is installed and check its settings to see what behavior is selected and honor that ? Just an aside - your module seems to works quite nicely with my Redirect IDs module. If there was a setting in your module to prevent subsequent renames, Redirect IDs could ensure redirects work so long as they use something like "id title" in your config settings. I know PagePathHistory would also be effective. Just exploring all the different options we now have

And if you want to avoid messing with core files try using Martijn's awesome Admin Custom Files (http://modules.processwire.com/modules/admin-custom-files/) to add that CSS.

Regarding the backup and restore option that owzim mentions. It is indeed very cool, but there's a bit of a problem with it at the moment. Any new fields that get created by your import script won't have the DB table removed when you run the restore which will result in table already exists errors when you run the script again after the restore because the field has been removed from the fields table so PW doesn't know about it anymore, but it's field_fieldname table is still there. Hopefully Ryan will sort out a fix for this shortly. Of course if your import script isn't creating new fields (or anything else that adds a DB table to PW), then this won't be an issue.

Makes sense, but what happens if they aren't logged in and there is no cookie set ? One thing I just noticed - if the user is logged in, you set $me to the user object and not it's id, so when you do myrank($me), it won't work! myrank($score_me) should work in both cases though.

Is $me always the ID of the currently logged in user ? Is so, then you can just use: $myscore = wire('user')->score; Otherwise can you show how you define $me

There are a few posts out there about this I think. Here's one, although mostly it seems to suggest switching to AMPPS http://stackoverflow.com/questions/25333173/mysql-with-mamp-does-not-work-with-osx-yosemite-10-10?rq=1

You shouldn't need the "id=" These should all work: $this_user_id = wire('users')->get(41); $this_user_id = wire('users')->get("username"); $this_user_id = wire('users')->get("id=41"); $this_user_id = wire('users')->get("name=username");

Not sure why Yosemite would have disabled it, but check your phpinfo() for PDO support enabled. If you can't find, try adding: extesion = pdo_mysql.so to your php.ini file.

Some more bug fixes - thanks again to muzzer! More interestingly though, during import you now have the option to automatically download and install any required missing fieldtypes/inputfields from the PW modules directory. This is optional and I have noted that if you don't trust the source of the data you are importing, then you might want not want to enable this option. It is off by default, in which case you'll receive notifications of what's missing so you can install manually before re-starting the import.

Given all the ex MODx'ers around here, I would love to see a plugin for Migrator. If you're willing to give it a go, Nico's Worpdress Migrator plugin for Migrator (that teppo mentions) might get you started. Is there an existing MODx to XML/CSV/JSON tool available that could be used as a starting point?

jlahijani - I finally had a look at the video for RAMP - it looks very cool, especially the automatic pushing from dev to production. Other than that, the big difference I noticed compared to Migrator is that currently Migrator can only export one page tree at a time and it has to be the entire tree of children below it. Sure you have the option to determine which pages get imported to the other site, but I think it would be a great enhancement to offer this selection during export as well. I am thinking the option to choose multiple pages and for each one (if it has children), determine whether to include the children or not. I think this approach would make it much easier to migrate a few newly developed pages, or several new sections, without the need to overwrite everything under an overarching parent page. You don't actually have to do this with the existing Edit Imported Content option, but it is not as obvious or easy. Anyway, it has given me some great ideas - thanks!

Actually the site/config.php in 2.5 is stripped down to almost nothing - you need to read through wire/config.php and copy any required elements from there to site/config.php

You can load a process module on the front end if you need to access a method or property from it. Usually Process modules are not autoloading because they are called from a page under setup or as a helper from another module. But if you have it already doing something in the admin, you could load it on the front-end: $modules->get("ModuleClassName"); and then call the required method/property. I would suggest limiting most parts of the module's functionality to just the admin template so when you load it on the front end, only the relevant method/property is instantiated and processed - the rest of the code should be excluded. It looks like Craig might have detailed what you need as far as setting things up.

Just a quick guess, but if you are storing the user->pass in a cookie, that would be the hashed version, so you couldn't use that to login again!

Would this take care of your needs: http://modules.processwire.com/modules/login-persist/

I don't know why but when I use my work email address which is managed by Gmail, but is not a @gmail address, I need to use: Nothing else seems to work for me except this. Hopefully that might be a useful addition to @cstevensjr's excellent post.

I just want to drop a note here to publicly thank jlahijani and muzzer for lots of recent help getting several more bugs identified and fixed and at the same time mention that you should all grab the most recent version on Github (https://github.com/adrianbj/ProcessMigrator). Thanks again guys!

Thank Mike - I'll let Ryan know so he can change it!

It is definitely possible to allow iframes through CKEditor with the right settings, but I would suggest that the easiest option might be to set up a Hanna Code (http://modules.processwire.com/modules/process-hanna-code/) tag for inserting iframes. I have to head out, but hopefully someone else can give you an example if you can't figure it out.

PW doesn't store the date/time a field is changed. I think the easiest approach might be to add a hidden field called date_terminated. Then add a hook on page save that sets the date if the checkbox field has been checked. Place this is your admin.php file. wire()->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments("page"); if($page->user_terminated == 1 && $page->date_terminated == '') { $page->date_terminated = time(); } }); That is a little rough but will hopefully get you started. You should add an if statement to limit this to just the relevant template so it is not run on all pages. I am sure other improvements could also be made. PS Apparently I was writing this while LostKobrakai was responding

Not sure if it's ready for prime time, but take a look at Blad's experiment on color skinning: https://processwire.com/talk/topic/7653-module-adminthemecustomizer/

https://github.com/ryancramerdesign/ProcessWire/issues/663 At least it no longer breaks the page Hopefully Ryan will deal with the rest of it sometime soon.

If some code from a module that you are developing (or one from someone else), breaks your site again, you can uninstall it by putting this code in a template file and loading a page with that template: $modules->uninstall("ModuleClassName"); If that still doesn't work for some reason, delete the .module file from your modules directory. If still no luck, go into PHPMyAdmin and delete the row for the module from the modules DB table. Following those steps in order should remove all remnants of a module that is causing problems. Of course that won't reverse any changes that the module may made to other DB tables while it was installed, but this is rare for most modules, so not likely an issue.

Welcome to the forums! You can set it as the default in your config.php file: $config->defaultAdminTheme = 'AdminThemeReno'; User's can change between themes from their edit profile page.