alan

If that works then it looks like a great idea, better than this probably

Thanks Ryan for that beautifully succinct summary of what I was struggling to work out(!). I have almost bitten the bullet that is upgrading my hosting (by migrating to an uprated product that has PHP 5.4.x) and until I do I will just continue to use that simple work-around. Thanks for the clarification Ryan

Thanks for the suggestion Dave, I may try this if I have time OK: The result is as follows (my hosting is stuck at PHP 5.3.5): ## Test 1 1. with MAMP PHP ver 5.4.10 install PW 2.3 locally 1. copy files and db export to hosting 1. go to login at hosting results in `Unable to generate password hash` ## Test 2 1. with MAMP PHP ver 5.3.20 install PW 2.3 locally 1. copy files and db export to hosting 1. go to login at hosting results in `Unable to generate password hash` see update 2013-05-13-1310 Conclusion: If I am correct then (since PW 2.3?—I've never seen this before so I am wondering if this came with v 2.3 of PW) if your hosting env is below 5.3.7 and you export/import a db from a local copy of a site to the hosting env then logging in won't work and will require the password being reset with a combination of Ryan's tactic and the edited Password.php file noted by Radek. NOTE: This conclusion may well be incorrect but I've run out of 'clever' and need some confirmations from those much cleverer than I on PHP/security/PW. Bottom line it's making me think I ought to upgrade my hosting past PHP 5.3.7; only trouble is it seems it's NOT easy to do this with an (mt) dv setup unless you are more of a sysadmin than I am :/ Crap. UPDATE 2013-05-13-1310: if my local env is set to PHP 5.3.20 (so like my hosting which is at 5.3.5 they are both below 5.3.7) then as long as I reset the local password as explained in 'Conclusion' above then I can now export a local db and import it over at hosting and login OK.

No forgiveness needed if I was aware or not Dave; /always/ happy to have suggestions Yes I am aware of it insomuch as I saw it mentioned in another thread but I did not know much about it other than I was indeed retaining the contents of config as all I was doing was installing locally, copying all files up to the remote, exporting/importing the db from local to remote; so I'm assuming this is not the cause(?)—but thanks for the suggestion all the same!

Hmm, this process did not directly work for me, I followed the steps but kept being denied access at the remote site. I then managed to lock myself out of my local site! So I used this Ryan tactic to get back into my local site, all good. Then I decided to try it at the remote site, so I uploaded a template with the password reset code and visited the page to make it run, returned to the admin login and WAS able to login. It now seems that if I change password locally and export the db to the remote site I kill the ability to login remotely but once I've fixed that with Ryan's tactic and am able to login at both ends I am now able to export the db locally and import it at the remote end (so able to move edits about if I need to) then login does not get broken and only re-breaks if I change the password locally. I am going to setup a vanilla clean install of 2.3 locally and then try to see if get the same (inability to login at the remote end without hacking about) or if I am able to login AOK. I hope it will be the latter (if it is then all I need to do is understand what is special about this install that it has this fragility). Will update this thread when test complete. Thanks again to Radek, Ryan et al.

Thanks Radek, I will re-read these steps and check again—I thought I'd done this (I did a password change and export/imported the db etc) but I will re-check and try again; cheers!

Thanks Radek very much for that. I tried it and have made a little progress. Now when I try to login rather than the error I get ADMIN - LOGIN FAILED or with debug turned on PROCESSLOGIN : ADMIN - LOGIN FAILED So I am still stuck, just with a cleaner error screen, but thanks once again for the suggestion.

This post is like these two but I've not been able to fix my problem reading those threads (perhaps partly because I don't fully understand some of the exchanges as they skip past things I am not familiar with). With debug turned on, when I try to login I am getting (domain and password substituted out): TEMPLATEFILE : UNABLE TO GENERATE PASSWORD HASH #0 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PASSWORD.PHP(33): PASSWORD->HASH('MY-PASSWORD') #1 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(310): PASSWORD->MATCHES('MY-PASSWORD') #2 [INTERNAL FUNCTION]: SESSION->___AUTHENTICATE(OBJECT(USER), 'MY-PASSWORD') #3 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #4 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('AUTHENTICATE', ARRAY) #5 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(262): WIRE->__CALL('AUTHENTICATE', ARRAY) #6 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/SESSION.PHP(262): SESSION->AUTHENTICATE(OBJECT(USER), 'MY-PASSWORD') #7 [INTERNAL FUNCTION]: SESSION->___LOGIN('ADMIN', 'MY-PASSWORD') #8 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #9 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('LOGIN', ARRAY) #10 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSLOGIN/PROCESSLOGIN.MODULE(77): WIRE->__CALL('LOGIN', ARRAY) #11 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSLOGIN/PROCESSLOGIN.MODULE(77): SESSION->LOGIN('ADMIN', 'MY-PASSWORD') #12 [INTERNAL FUNCTION]: PROCESSLOGIN->___EXECUTE() #13 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #14 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY) #15 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PROCESSCONTROLLER.PHP(194): WIRE->__CALL('EXECUTE', ARRAY) #16 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/PROCESSCONTROLLER.PHP(194): PROCESSLOGIN->EXECUTE() #17 [INTERNAL FUNCTION]: PROCESSCONTROLLER->___EXECUTE() #18 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #19 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY) #20 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/ADMIN.PHP(45): WIRE->__CALL('EXECUTE', ARRAY) #21 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/ADMIN.PHP(45): PROCESSCONTROLLER->EXECUTE() #22 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/SITE/TEMPLATES-ADMIN/CONTROLLER.PHP(13): REQUIRE('/VAR/WWW/VHOSTS...') #23 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/SITE/TEMPLATES/ADMIN.PHP(13): REQUIRE('/VAR/WWW/VHOSTS...') #24 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/TEMPLATEFILE.PHP(125): REQUIRE('/VAR/WWW/VHOSTS...') #25 [INTERNAL FUNCTION]: TEMPLATEFILE->___RENDER() #26 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #27 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDER', ARRAY) #28 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PAGERENDER.MODULE(250): WIRE->__CALL('RENDER', ARRAY) #29 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PAGERENDER.MODULE(250): TEMPLATEFILE->RENDER() #30 [INTERNAL FUNCTION]: PAGERENDER->___RENDERPAGE(OBJECT(HOOKEVENT)) #31 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #32 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDERPAGE', ARRAY) #33 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(293): WIRE->__CALL('RENDERPAGE', ARRAY) #34 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(293): PAGERENDER->RENDERPAGE(OBJECT(HOOKEVENT)) #35 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('RENDER', ARRAY) #36 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSPAGEVIEW.MODULE(97): WIRE->__CALL('RENDER', ARRAY) #37 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/MODULES/PROCESS/PROCESSPAGEVIEW.MODULE(97): PAGE->RENDER() #38 [INTERNAL FUNCTION]: PROCESSPAGEVIEW->___EXECUTE() #39 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(271): CALL_USER_FUNC_ARRAY(ARRAY, ARRAY) #40 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/WIRE/CORE/WIRE.PHP(229): WIRE->RUNHOOKS('EXECUTE', ARRAY) #41 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/INDEX.PHP(192): WIRE->__CALL('EXECUTE', ARRAY) #42 /VAR/WWW/VHOSTS/EXAMPLE.COM/HTTPDOCS/INDEX.PHP(192): PROCESSPAGEVIEW->EXECUTE() #43 {MAIN} So far I have: replaced /wire/ with a fresh 2.3 copy set /site/assets/cache/ plus all contents to 777 set /site/assets/sessions/ plus all contents to 777 installed a copy of PW 2.3 in a sub-domain and checked it can login OK (server environment check) and all OK I am able to update the site by updating locally and then export/importing the database. I would be grateful for any suggestions as to how I can solve this, thanks in advance for comments!

Mac user, I've tried Espresso, Coda (for a long time) and within the last 3 months, Sublime Text 2. If you like keyboard shortcuts (over mousing) then Sublime Text 2 is quite the closest thing to a perfect editor I've found. From this page you can get to this 38m video showing ST2 with a few of the 'Packages' (expand functionality) you can add. I can't recommend it enough. Edit: It comes in Mac, Win and Linux flavours.

+1!

Dear Ryan and Mrs Ryan, What joyful news! A wonderful and happy scene, you must both be proud beyond words. Cheers to you all and happy birthday to Karena! With love from me, the family, Canada and the UK!

No I hadn't see it Horst—thanks!

Thanks horst, I think I had debug on and it was local, but I (again) forgot to look in errors.log, thanks for the reminder, I will go check it

Hmm. I just implemented this limit (set width to 850 so images 851 and wider would be re-sized down at upload). Now when I add an image of over 851px wide it appears to barber-pole it's way up to 100% loaded but then never displays the image. I removed the restriction and now normal service is resumed and images are able to be uploaded again. Any ideas anyone?

Ah, gotchya, sorry not able to help :/

Hi Tom, I did this but it was a while ago and I am up against a deadline so can't spend long right now but just in case this code is self explanatory I paste it in the hope it helps, I am 99.9% sure I solved it with the great Soma's help $nav = $modules->get("MarkupSimpleNavigation"); // load the module and have an instance kept in $nav var $options = array( 'levels' => true, 'show_root' => true, 'item_tpl' => '<a href="{url}">{title} <em>{headline}</em></a>', 'item_current_tpl' => '<a href="{url}">{title} <em>{headline}</em></a>', 'xtemplates' => 'editors_only', 'xitem_tpl' => '<a class="editors_only" href="{url}">{title} <span>Editors only</span><em>{headline}</em></a>', 'xitem_current_tpl' => '<a href="{url}">{title} <em>{headline}</em></a>' ); echo $nav->render($options); Hope it helps!

Thanks Ryan, there will be some slack time soon when I am definitely going to be following up on this so I understand it. It's very helpful to know about session and cache, I will just copy them all in future I think, I can't even recall why I set them to excluded in my FTP client.

Hi @Wanze, I may be late to the party to thank you but nonetheless, thank you for this great Module—I am sure I am going to be using it.

Assuming you mean the Admin side then it's nice and easy, just check the Input tab of the field in question and you'll see 'Rows' My advice = DOH!

To see what I could learn about this error I installed a vanilla PW 2.3 directly on the hosting rather than locally and exporting. So far this method has worked and exporting back to local still works and exporting local back to hosting still works. Now gradually making the test site more like the site that had the problem (adding modules etc) to see where (if) it trips up. One thing I have learnt, if I install a Module then export the db and sync files (local to hosting or visa versa) then login on the place I exported to then although I am running with a set of files for all modules and a db that was running with all modules until I actually visit Modules in the PW admin and click check for new Modules (which reports none new are found) the new modules are not listed as installed in Modules Manager. I did not expect this behaviour and don't quite understand it but I will follow this procedure as a work-around (but maybe this is expect behaviour?). Edit: Perhaps the above behaviour is because I am not copying cache and session folders with the rest of the site when I upload?

Thanks Marty, yes this is a weird one, I ran out of time last night but I am going to get to the bottom of this one, when I go to login I am also seeing SESSION : FIELDTYPE 'FIELDTYPEMAPMARKER' DOES NOT EXIST FIELD : FIELDTYPE 'FIELDTYPEMAPMARKER' DOES NOT EXIST and there is another thread here about config.php fingerprints or keys created on one server used on another. So I also need to investigate that and perhaps they are related. Edit: OK well those two were obvious (I need more coffee) the PW install still had a field type of MAP, removed the field and restored the local DB to remote and now the remote does not report the error. Now to return to trying to figure out why my good hosting seems to cough if there is a field of type MAP...

I have found in a new 2.3 install that if this Module is present and the site is on a live host (not MAMP) then accessing a page that uses a field of type Map produces this error 2013-04-24 18:25:32 guest http://example.com/contact/ Error: Call to a member function loadPageField() on a non-object (line 651 of /var/www/vhosts/example.com/wire/core/Page.php) My quick fix is to not use this Module but I would love to solve this so I could proceed and use it in this case and in future. I am going to do some checking on version numbers locally and on the server and will edit this post/post again but in the meantime if any uber-clever PW friends know why this might be happening I would be very interested as I really wanted to use the Module. Thanks a lot in advance friends, cheers, -Alan Edit: The server version of PHP is 5.3.5 and I can set my local MAMP version as low as 5.2.17 and the error is still happening on the server and not happening on the local MAMP setup.

No idea what this is unless it's what it seems (too many people hitting your site at once?). But I assume the ProCache module would avoid this happening as, I think, it means most people are served content without PHP or DB hits. I've no idea how it does it and like a high quality magic trick I am quite content never knowing I'm just glad it's excellent.

*SO* true Tom.

LOVE the marketing Soma.