Jump to content

cbutler

Members
  • Posts

    32
  • Joined

  • Last visited

cbutler's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. I have that warm/fuzzy feeling I often get from TCH. I'm scrambling to update my last un-upgraded clients to PHP 5.3, but I greatly appreciate your effort to keep 5.2 support alive. Many unloved and abandoned PHP websites are out there, which may break under PHP 5.3. TCH is trying to buy us some time, but backward compatibility is an impossible game. The web is littered with endangered websites -- what web designer wants to take over a Smarty PHP website and climb that dead-end learning curve? Did Ruby on Rails survive its 15 minutes of fame? Local (Austin) craigslist job ops suggest "maybe not". Kudos to TCH for an interesting approach, and a clear understanding of how to serve resellers. This latest effort is above and beyond... Cheers, Chris Butler
  2. Bob... Thanks very much. "php5" seems to have done the trick. Great forum, guys... Chris
  3. I need to embed PHP in a client's existing HTML files, and tried the usual changes to .htaccess : AddType application/x-httpd-php .htm AddType application/x-httpd-php .html AddHandler application/x-httpd-php .htm AddHandler application/x-httpd-php .html I've introduced little PHP code to the client's HTML files, but all of it is ignored. The "AddType" option produces a Mac pop-up asking what application I wish to use, while the AddHandler option is just ignored. I'm on philadelphia, which is probably an older codebase to avoid breaking older PHP-based websites like some of mine. I've been with TCH a while... FYI, I develop on Snow Leopard running Apache2 and PHP 5.3, where the above changes result in proper PHP pre-processing of my client's HTML files. Thanks for any help. Chris
  4. Bruce... That database has a single user, and I already tried removing and restoring that user. I just repeated that process, and also created a new user/password. In each case, I get this error message: Warning: mysql_connect(): OK packet 6 bytes shorter than expected in /websites/bbm_georgetown/shared_v4/libs/database_lib.php on line 96 Warning: mysql_connect(): mysqlnd cannot connect to MySQL 4.1+ using old authentication in /websites/bbm_georgetown/shared_v4/libs/database_lib.php on line 96 Other suggestions gratefully accepted... Chris
  5. Dick, I'm now trying to connect from my Mac development system to a MySQL database on philadelphia, and am getting the same error message about old vs new password MySQL authentication. My Mac is running PHP 5.3.2, so I assume my PHP mysql_connect() code is producing the newer longer password hash. I'm guessing the correct solution is to delete my MySQL user and then recreate that user, which should generate the new password hash. I'd prefer to update to the newer MySQL password convention instead of working toward backward compatibility, and will change anything necessary in my PHP framework. FYI, I've added my local IP address to the access list via cPanel, which is how I got as far as the old/new password conundrum. I'm reluctant to offer more specifics in a public forum, but I'd appreciate your input to help me generate a coherent ticket. Thanks, Chris
  6. Thanks for the prompt reply -- TCH never fails to impress me. Can you give me a rough idea what's involved in the fix? I prefer not to have my client inconvenienced for long, if changing password software requires major changes in my code. I'm developing on a Mac/PHP5.3 system, but I greatly appreciate that TCH hasn't made the jump to PHP 5.3 yet. I still have some clean-up works to make my TCH/PHP 5.2x websites work cleanly under 5.3. Just being cautious here... Chris
  7. I'm apparently running into a software version mismatch when trying to access a remote MySQL database on my TCH reseller account. Via cpanel, I've enabled the TCH-based reseller database for "%" access. I'm developing on a Mac Snow Leopard system -- PHP 5.3. The same user/password works fine for my PHP code running in production mode on the TCH website and also on my Mac development system. But I get "OK packet 6 bytes shorter than expected" when I try to access the remote TCH database from my Mac, using the same user/password combo. Web comments suggest software mismatch, but I have no control of the TCH system. phpinfo() hasn't made the problem clear. Can anybody help? I'm trying to let a client with multiple websites use a single instance of his database, instead of replicating it across all his websites. I realize "localhost" is the easy solution, since all my client's websites are on the same TCH reseller account. But my client is growing and will need multiple distinct websites in the future, probably on dedicated servers. Thanks for your consideration, Chris Butler PS: My sympathies to the TCH support crew. It seems "regression testing" is just a mild embarassment now to the developers of PHP, and all bets are off now that Oracle owns MySQL.
  8. Months after my initial post, I'm grateful to the TCH crew for keeping my reseller account (server Philadelphia) below PHP 5.3. My websites still work, and I've had time to prepare for the inevitable. Some folks may be interested in my conversion efforts, after I upgraded to Snow Leopard, which ships with PHP 5.3: 1) I wrote a set of "acme" wrapper functions for the few ereg functions that I use, which map between ereg and preg. I also wrote a PHP script that changes ereg calls to "acme_ereg" calls. A few regular expressions needed hand-tweaks, but that approach seems to work. 2) My home-grown PHP framework used $namespace as part of my effort to deal with the lack of early namespace support in PHP and CSS. PHP 5.3 confiscated that keyword, so I wrote another script to change all my instances of $namespace to $acme_namespace. Again, that approach worked. 3) Ditto for "split()" (deprecated) and "mysql_list_tables()" (deprecated). 4) PHP 5.3 no longer seems to allow <? as a PHP intro tag, requiring <?php. I wrote yet another PHP script to change my existing code, some of which dates back to 2002, when <? was kosher. Every modified website had to be tested. This is a trickier than some might expect, because PHP is a just-in-time interpreter/compiler. The tester must actually hit each code path to test it. If you use a conditional "include", your PHP code may not even get a basic syntax parse. I'm near a happy ending, and wish everybody else good fortune in their conversion efforts. But to the PHP developers: dohhhhh! The number one rule of successful software development: Don't break existing code! My Intel-based MacBook can still run PowerPC code via Rosetta, and Microsoft still supports the (idiotic) A: B: C: drive-naming convention that dates back to CP/M. (See Unix "mount" for the correct solution.) Deprecate any code you want and don't waste further development/debugging efforts, but leave it in the code tree. C code I wrote in 1980 still works. Cobol still works. PHP is the only language I've used that punishes early adopters. Again, thanks to TCH for being realistic. TCH has always been a reliable partner for me. Cheers, Chris
  9. Yes, I know what deprecated means. What in my initial message suggests otherwise? All my websites have most PHP error reporting options enabled, because I want to know when a problem arises. When 5.3 hits, I suspect I'll have to turn some PHP error reporting bits to keep "deprecated" messages from squirreling client websites. Not a major effort, but it would be nice if 5.3 included a bit or a function to specifically turn off ereg deprecation warnings while leaving other warnings enabled. Fat chance... When PHP 6.0 hits, I'll have no choice to modify every client website I've ever written in PHP. This isn't a simple typing exercise. I'll have to retest everything I've written -- shopping carts, photo galleries, databased catalogs, etc. Anybody who revises code and doesn't retest it, hasn't been in this business long enough. I figure two weeks to revise and retest, if everything goes well. Plan B is simply to leave the ereg stuff in the PHP codebase, tell the world it's no longer being supported, and use it at your own risk. Perl-based regular expressions are more capable, but the ereg functions are more POSIX-compliant. What's wrong with keeping both? I'm a Unix guy at heart, but I appreciate that Microsoft owns a big chunk of the computing universe because they grok "backward compatability". It's why Cobol is still around, and still arguably the world's most portable language. Maybe I'm naive, but I suspect TCH support staff will be losing some weekends and evenings soon... Chris Butler BS/CS 1980
  10. The PHP language developers have decided the PERL/preg functions are superior, so the PHP ereg() family is being deprecated in PHP 5.3, and removed in PHP 6.0 That will break every PHP-based website I've developed over the past 5 years, and I suspect I'm not alone. I'm hoping some TCH gurus are paying attention and will complain loudly on this issue, because TCH gurus can expect total outrage from PHP users like me when the transition to PHP 5.3 or PHP 6.3 occurs. The solution seems simple. Just tell the PHP language developers to keep the ereg family in the codebase, but state explicitly that no further development or bug fixes will be done on those functions. Thanks, Chris Butler
  11. My PHP requirements are becoming more complex as multiple pages interact, so it would be helpful if I could use the "pecl_http" module. In particular, PHP's HttpRequest class has a lot of capabilities which seem handy. I have a standard reseller account, so I can't add that support myself. Is this something TCH would consider? Thanks, Chris Butler
  12. I recently purged a client for non-payment, and then he belatedly requested reinstatement. I was delighted to find that Total Choice keeps archives going back 4 weeks, which was sufficient. In less than an hour, TCH tech support guy Alex Spaford restored the website in my reseller account, and it was back on line. I continue to be impressed with TCH professionalism, after 3 years and counting... Chris Butler
  13. A bit obscure -- I use MySQL a lot, but for PHP info? Still, that's what I needed. Thanks very much, Chris Butler FYI, here's the response my ticket got: "After looking at your ticket I have concluded that a senior level admin will be required to conduct further testing. This ticket has been escalated to our Level 2 Administration Team for Review and possible action." Arghhh....
  14. ------------------ The part that isn't clear is that this is apparently a permanent condition, denying me access to information I rely on. I'm having trouble with the $_SESSION superglobal and phpinfo probably would have been helpful. I'll send in a ticket, but a more convenient solution for everybody (including TCH) might be a login-based page that shows phpinfo's output. It's gettin' ugly out there on the web. Chris
  15. Folks... When I try to cal phpinfo() on server 47, I get a warning that the function has been disabled for security reasons. I've reviewed my .htaccess file and don't see any problems. I can get my own PHP runtime info via PHP superglobals, but that's an inadequate solution. What's up? Chris butler
×
×
  • Create New...