new earth online

It's not often that I talk about .net here as I prefer PHP - and I'm sure there are other developers that feel the same way - and vice-versa! An amazing achievement from a UK company called Jadu (a company I can honestly say I'm very proud to work for!), a leader in the CMS market, is a joining of these two languages for the first time ever.

The Phalanger PHP compiler was developed and funded by Jadu, but is being released to the open source community, the company said.

The tool works by allowing the compilation of PHP applications which can run natively under the .NET Framework, allowing firms to make use of PHP apps without needing to rip out existing .NET/Visual Studio infrastructure, according to Jadu chief executive Suraj Kika. 

So this means if you're on a .net based system, but require the use of phpBB or some other PHP development, you could use Phalanger to get it running in the same environment as your .aspx based scripts! That's a pretty amazing feat really. Thinking about it, that also means you could write what you want in PHP, and then have it work and accessible from C# scripts.

If you want to use WordPress but you're a Microsoft house, you can compile WordPress down to an executable and drop it onto .NET with Phalanger," he said. "You can then start working on it in Visual Studio, and build your own apps around it. It is extremely portable.

It's like Yin and Yang - two opposites, yet working together to produce something that is more than the sum of it's parts. I can imagine ASP.net pages using their "special" forms, but validating and submitting it to the database via a PHP script. It certainly opens a whole new door to .net developers and PHP developers alike, and it is looking like a bright future for Phalanger. I'm sure this is only the beginning of what may change web development as we know it forever...

The people that run the PHP project have done what they said they would - they've discontinued their support for PHP 4. Just last week they released version 4.4.9 meaning that it will apparently be the last time an update is released for PHP 4. All work by the team now will be focused on PHP 5, and stabilising and adding features to PHP 6.

Fortunately the majority of web hosts have now moved over to PHP 5, but there are still some that haven't. I don't see support for PHP 4 ending as being a bad thing, I don't think it's really going to affect anyone really - even if they are still developing for 4.

phpBB is arguably the most popular software for implementing forums around. Several months ago they released the third version that updated many of the features and made it far more pleasurable to work with. Now they've released their second patch for it, fixing the following issues:

• Ability to set permissions on non-mysql dbms (Bug #24955)
• Fixed blank style on setups having no username defined within config.php (Bug #25065)
• Made the compress_tar class tolerate archives that do not properly have their archived contents listed (Bug #14429)
• Moved topics should not count towards the number of topics in a forum (Bug #14648)
• Properly check for invalid characters in MySQL DB prefixes during install (Bug #18775)
• Bring the PostgreSQL backup system back to working order (Bug #22385)
• Update correct theme for cached styles in style.php (Bug #25805)
• Correctly determine safe mode for temp file creation in functions_upload.php (Bug #23525)
• Correctly sort by rank in memberlist (Bug #24435)
• Purge cache after database restore (Bug #24245)
• Correctly display subforum read/unread icons from RTL in FF3, Konqueror and Safari3+. (thanks arod-1 for the fix, related to Bug #14830)
• Added missing form token in acp
• Do not remove whitespace in front of url containing the boards url and no relative path appended (Bug #27355)
• reset forum notifications in viewtopic (Bug #28025)
• corrected link for searching post author's other posts (Bug #26455)
• HTTP Authentication supports UTF-8 usernames now (Bug #21135)
• Topic searches by author no longer return invalid results (Bug #11777)
• Delete drafts and bookmarks when deleting an user. (Bug #27585)
• Set last_post_subject for new topics. (Bug #23945)
• Allow moving posts to invisible forums. (Bug #27325)
• Don't allow promoting unapproved group members (#16124)
• Correctly fetch server name if using non-standard port (Bug #27395)
• Regular expression for email matching in posts will no longer die on long words.
• Do not display ban message if direct call to cron.
• Correctly display double-colon on special conditions within highlighted php source (Bug #26795)
• Increase storage capacity of titles/subjects due to specialchared content (Bug #25235)
• Catch invalid username wildcard ban (we do not support these) (Bug #29305)
• Fix (email)-domain checks for those having DNS prefixes set (Bug #29635)
• Adjust truncate_string() to be able to adjust the maximum storage length.
• Sort the tables at the database table backup screen
• For determining the maximum number of private messages in one box, use the biggest value from all groups the user is a member of (Bug #24665)
• Show email ban reason on registration. Additionally allow custom errors properly returned if using validate_data(). (Bug #26885)
• Don't allow redirects to different domains.
• Added optional referer validation of POST requests as additional CSRF protection.
• Added optional stricter upload validation to avoid mime sniffing in addition to the safeguards provided by file.php.
• Streamlined banning via the MCP by adding a ban link to the user profile. Also pre-fills ban fields as far as possible.
• Added ACP logout to reset an admin session.
• Only allow urls gone through redirect() being used within login_box().

So it's a pretty big update really, and although some of the changes are trivial to most users there are a few big ones there such as the additional CSRF protection that makes it a worthwhile update.

Link: phpBB 3.0.2

In PHP it's probably quite common to want to import data into your database using a CSV file, or an XML file - even though phpMyAdmin is capable of doing it. As I recently found out though, this can sometimes be an issue in itself. In this particular example there was a CSV file from an unknown system that was being read in by PHP and processed but it appeared like it was only reading in the first line due to way the data was being processed. As it turned out the entire file was being read in as a single line, and since the script was using fgetcsv to read in a line of comma separated variables it turned out to be pretty obvious what was happening after using print_r on the output.

I knew that fgetcsv didn't have a parameter for specifying a line ending character so I decided to investigate what could be done to solve the problem. Eventually I found:

<?php
   ini_set('auto_detect_line_endings', true);
?>

After putting that line in before reading in the file all the problems were solved and the file was read in correctly. A strange issue, but a simple solution.