This is just a small nerd post for those of you who may be trying to use the beta 3.0 series of EasyPayPal for WordPress. The script has a very common bug in it that shows up if you don’t configure any categories to be hidden unless purchased in the options. The fix is very simple and I’m rather amazed it hasn’t been committed yet. All that has to be done is to initialize the $cats variable to an empty array since the variable is only created inside a conditional (bad coding!).
Read more…
It’s been a very, very long time since I last touched php_template and just out of the blue today I decided I’d finally get off my ass and create a Visual C++ project out of it so I could compile it for Windows users.
Well, after several hours of tinkering and encountering PHP source code “bugs”, I finally got it to compile. I had to do a few fixes too apparently – I was missing some TSRM junk to the parse_tag() function (and I believe that’s because it passes a zval around, so it needs the thread-safe stuff with it), and I had some calls to strlen() which needed to be explicitly cast to avoid warnings. This got rid of some of the compile-time warnings (there are still warnings about strcat() and cousins being used, but I’m smart and know how to use them properly) generated by VC++ 2005 and popped out a tasty php_template.dll for PHP 5.2.1.
Read more…
I was fooling around with some stuff when I noticed one of the scripts I was trying to use had some hard-coded paths in it meaning I couldn’t rename it’s base directory (which really wasn’t a good name to begin with). Anyways, I thought I’d post a few simple things every PHP programmer can add to their repository of useful junk which may help them deal with using relative paths to include files in both their PHP scripts and any HTML pages that need relative source paths too.
Read more…
I’ve been working on a project over the past few days and I came in to a situation where a table I had designed was purposefully created to NOT rely on auto_increment/numerical IDs so that I wouldn’t run in to any eventual limitations on the number of rows I could have (before the auto_increment field reached it’s max value and could no longer allow creation of new records). The table in question was made to use VARCHARs instead as my indexes so that I could link to other tables with those instead.
Then I noticed a slight issue when it came time to updating records in this table – if I was going to update a row, I had to compare almost all the fields in my table since I had no unique/primary keys defined (just 2 indexes on VARCHARs). I thought about how much simpler it would be if I had a unique ID field that would allow me to easily refer to a specific row of data – but at the same time I didn’t want to walk in to any data storage limits (though I know, over 4 billion or whatever the max INT is won’t likely ever be reached, it’s still a limitation I’d like to avoid by design).
I thought about it for a while and figured that it would be really nice if I could add an auto_increment field – but tie it in with another non-unique field (think of groups, and then in that group I count the records independently of other groups). It was an amazing idea but I had no clue how to make it work. All I knew is that I could define a UNIQUE KEY and constrain it to multiple fields like so “ALTER TABLE example ADD UNIQUE KEY id (field1, field2);”. The problem I foresaw was that if I made one of those fields auto_increment, MySQL would automatically create an INDEX for that same field to which it would store the increment count meaning that my auto_increment field would pertain to the entire table (meaning that the auto_increment field would increment irregardless of the other field specified in the UNIQUE KEY).
Read more…