adrian

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.

There is probably a cleaner way, but this hack works: .content .PageList .PageListID1 .PageListActions{display:none !important} .content .PageList .PageListItem:hover .PageListActions{display:inline !important;-webkit-transition-delay:.25s;transition-delay:.25s}

Use the module that Reno mentions above: http://modules.processwire.com/modules/admin-custom-files/ and add this CSS: .content .PageList .PageListItem:hover .PageListActions{display:inline;-webkit-transition-delay:.25s;transition-delay:.25s} EDIT: You'll want to apply it to the ProcessPageList process. Works a treat!

If I remove it I get a parse error in line 112? But the final line of my template is actually line 110. Line 112 is empty? PHP error line numbers will sometimes do this - if you having a missing "}" it will keep looking to the last line of the script and if it still doesn't find it, that will be the number that is associated with parse error. It may not seem very helpful, but in reality there isn't really a better line to refer to when something is missing PS I am guessing that you have a couple of empty lines after 110 - hence the 112?

I know it may feel excessive, but this is one of those things in PW that seems a little crazy in the beginning, but really does work out amazingly well. I would recommend the option to store these pages under a central parent outside the structure of your site. Use the "Select a parent for items" on the Details tab. I usually also use the Automatic Page Name Format option on the Input tab. I struggled with the concept of a black box of pages, but once I stopped worrying about, it really does work well.

PageTable won't work on 2.4 (I am fairly certain there were some core changes required), but there should be no reason not to upgrade your site to 2.5. Is there a reason your hesitant to upgrade? Page Table can handle any fieldtype/template combination you need, so you can definitely use headline, link, caption etc