I agree I don’t like the way MAMP keeps trying to give you “free” MAMP-Pro trials and sneaking you into the premium product. I deleted the whole thing, mamp and all, and restarted the MBA.įirst step I downloaded the mamp/mamp-pro installer, which does everything possible to kick me into the mamp-pro application … Bloke wrote #327573: No relevant apache errors, the MySQL log was too spammy for me to check. The PHP log was empty for the time I ran the test. Checking the various error logs (Apache, PHP, MySQL), I did not see anything obvious. Looking at the txp-user table it is possible that the user was actually not created. Every single click in there generates a truckload of warnings and possibly errors.
those were rejected.īlood pressure in not-so-good zone… back to phpMyAdmin, try to check the DB. Next I attempted to access the login panel directly, going to /textpattern/ that of course was fine, but no way could I login with the created username and password. I clicked the button that should bring me to the TXP login panel… and… it brought me right back to the start of the setup process. The usual steps, everything seems fine, placed a config.php file with the provided data, and finished (name, username pass…).
I was greeted with endless warning panels, luckily with a button at the top, “ignore all”. accessing the phpMyAdmin page to create a DB. pkg process – absolutely did not appreciate their attempt to shove me into mamp-pro).Īfter some cursing and what not, I found the non-pro mamp.app, selected php8, loaded their webstart view. Presumably, if we can emulate the conditions under which those errors are thrown, you’ll get a white screen situation in PHP 8 because it ignores the error suppression?įirst step I downloaded the mamp/mamp-pro installer, which does everything possible to kick me into the mamp-pro application (the installer itself is fine, standard. Honestly, I’m not even sure I know how to simulate a failure in those two instances, but there must be some kind of avenue for them to fail because we added the error suppressions for a reason in those specific places.Ĭan anyone get Txp to throw an error message to the screen here in debugging mode if the signs are removed? I seem to recall it had something to do with the trace log dying and throwing a white screen under some circumstances. Maybe we need to locally turn on mysqli_report() just before the mysqli_ num_rows() calls, and then switch it off again straight after, to avoid having uncaught errors thrown around other mysqli_ calls? Then pass the return value into the subsequent calls. I’m not sure how best to handle those situations with proper error handling.
There are only two uses of in there: both surrounding attempted error suppressions of mysqli_num_rows() in the safe_query() and safe_field() functions. Addendum: If anybody would like to have a go at patching txplib_db.php that would be a useful exercise.
0 kommentar(er)
