Tuesday, October 19, 2010

PHP-Calendar 2.0 Beta9

Big thanks to Michal Osowiecki, Kerri McHale, Hristo Delchev, and Kim Hansen for this release. This release may break what day of the week your calendar starts on (if you're upgrading). Simply go into the calendar admin and set it to the proper value. The look of the calendar is much improved from some changes submited by Michal Osowiecki. Hristo Delchev submitted a Bulgarian translation. A number of bugs have been fixed since the last beta. Thanks to every one who submitted a bug report or email. The main thing left to do for the final 2.0 release is writing an updater from 1.1.

Monday, June 14, 2010

PHP-Calendar 2.0 Beta8 is out

There's not really much to talk about here in the way of features. A couple of new translations, Danish and Chinese. Not too many bug fixes. No DB changes. The big changes here are all security related. I added a check to protect against CSRF, fixed a few XSS and an SQL injection or two. Thanks to Teemu Vesala at Qentinel and the folks at Skipfish for helping find them. The update scripts from 1.x series have been removed as they were another attack vector.

There was a published vulnerability about the update scripts that I was never notified about. I'm pretty disappointed about how they handled that situation. The security advisory. Despite the fact that the bulletin says I was notified and the rep from isecauditors.com said he notified me, I was not notified. If you're using an older version of PHP-Calendar, mainly version 1.1, please delete the update08.php and update10.php files.

VUPEN released an advisory for the security issues fixed in 2.0-beta7. Anyone on an earlier beta should upgrade to 2.0-beta8.

Wednesday, May 19, 2010

PHP-Calendar 2.0 Beta7

This is a somewhat unusual release. There were a couple of XSS issues either the early betas or maybe longer. One was an artifact from debugging where escaping HTML entities in subjects just never got re-enabled. I think that one was introduced when I added UTF-8 support. The other issue, which was around a lot long, was there was no checking of the lastaction parameter on login, so someone could craft a URL to be redirected to any location. Thanks to VUPEN for discovering these issues.

In other news, I've included a French translation, allowed month names to be translated, and fixed a few statements that caused PHP to print notices on some setups.

Friday, March 12, 2010

Version 2.0 beta6

There isn't too much new here.

I fixed some bugs that I created in the last release. Specifically, some of the SQL statements with categories weren't quite right and when I fixed anonymous users, I broke one of the admin pages. Nothing really earth-shattering there, but they were stupid mistakes nonetheless. More noteworthy is that just because you have a table and the fields set as UTF-8 does not mean that MySQL is going to generate UTF-8 strings for you. I thought the entire calendar was UTF-8 before, but I was sorely mistaken. For those that don't know, UTF-8 is a character encoding that allows Western and non-Western characters to coexist. So if your Japanese friends want to post to your calendar in Japanese... now they can! Also, accented characters in the description broke the hover thing in the month view; that's now fixed.

I wrote a really simple and stupid script to generate the translation files. It's in the install directory. All of the translations are horribly out of date. I'm really sorry. If you have a favorite language and you want to create a translation or you're having trouble getting the translations working, please visit http://code.google.com/p/php-calendar/wiki/Localization. I wrote that up today for the release.

Thursday, February 11, 2010

2.0 Beta 5 is out

After about a month of slacking, 2.0 Beta 5 is out. The most important point about this update is that the DB format has changed slightly, so previous installations cannot be directly upgraded. I haven't written an upgrade script, so if you really need to upgrade your existing calendar, the easiest way is to install a new calendar with a different prefix, then rename the table `prefix_categories` to your original prefix, and look at the new `prefix_events` table. It should have one more row than your existing events table. Create that row in your events table. Embedding the calendar is changed a little, index.php now has a lot more variables to customize (and embed_setup.php has the same variables to customize), these variables were previously in setup.php, anonymous users can create events again, and events can now have categories with custom backgrounds.

Wednesday, January 13, 2010

2.0 Beta4

Another week, another beta. There's no much big or interesting in this one. I was hoping Beta3 would be the last Beta. Unfortunately, the were a few fairly obvious bugs in the install/DB code.

If there was ever a problem connecting, I was calling the mysql instead of the mysqli function. No really a huge deal, because if you're having a problem connecting, there's already a more important issue, but it's something that needed to be addressed nonetheless.

The next issue was just a typo that I made while fixing pretty much the same typo. No excuses here. The reason it got though is because I don't have a setup to test that portion of the installer. Why? A little laziness I guess. My host requires me to create databases and users through their web admin panel, so I can't test the portion of the calendar that creates databases and users.

The final issue and main reason for the early beta, some configurations (well, only one that I've heard of, but that's enough) don't respect the default database being set in the mysqli constructor, so I'm setting it using select_db() immediately after, which seems to work fine. This seems related to another issue with PDO where changing the order of arguments to PDO fixed the same problem. I think both issues were on Windows XP. Regardless, this should have no impact for anyone else and fixes at least one setup.

Try out the beta. If you had problems with the install, hopefully they're fixed. If you didn't have problems with the install, please try it again to verify that it's still working.

Wednesday, January 6, 2010

2.0 beta3

I was planning to make the next package a release candidate after I finished my TODO list. Today, I added a file to SVN and discovered a few others hadn't made it into SVN either. Checking the issues, this affected 2.0 beta2. So, I put up a new beta today. In addition to having all of the appropriate files, I fixed the global admin panel which had been broken by some other change. Everything else is pretty trivial. No more extra rows in the event form from hidden fields, readonly events can be created, global admins can delete users, and some other random bug fixes with the admin panels.

Hopefully Beta3 will be the last one before the release candidate(s). So play around with it, it should be more feature-complete than 1.1. Keep in mind http://code.google.com/p/php-calendar/wiki/ToDoList, if there's something that isn't right. If you have a suggestion, not on that list, create an issue or send me an email.

Monday, January 4, 2010

2.0 Beta2 is out

This is kind of a culmination of a few years of idle work. I've been working on a form class for a few years (very occasionally), and it's finally included. New work and kind a departure from past releases is some more Javascript. JS is all JQuery and not strictly required, but will be pretty awful and confusing with JS disabled.

This should be the final DB format for the 2.0 release. The event format is final. It similar to the version that has been in the trunk for a couple of years, but a little different. Previous versions used an event type column in the event table to mark repeating events as daily/weekly/etc. The version on the trunk expanded on that idea. It had a table for occurrences for each event and occurrences had columns to specify when they started, stopped, how frequently they occurred, etc. It was really complicated. The current (and final) version creates an occurrence for each occurrence (wow, how novel), so if an event is scheduled to happen 50 times, there are 50 rows in the occurrence table for it. This allows specific occurrences to be removed easily, makes for a very simple DB format, and removes some conceptual problems I was having with the previous format.

So take it for a spin, but don't expect all of features to work. There are a few pretty major omissions yet. Read-only events are basically supported, but the UI isn't there yet to create them. Multiple occurrences aren't shown in the event display yet. If you have suggestions for what that should look like, leave a comment. The admin panel probably hasn't seen any improvements since Beta1, but it's been a long time since then and if I made any changes, I don't remember them. Someone posted a comment on a bug saying that they couldn't use the calendar because their host didn't have PDO. I didn't really have a good reason for using PDO. I thought if in the future I wanted to support some other DB, it might make things easier. I don't know if that will necessarily be the case, so there's no sense leaving potential users out over some possible eventuality. For this release we're on to MySQLi. This may support a different subset of users. If anyone had PDO, but not MySQLi, I'm sorry. The PHP docs recommend MySQLi, so that's what I'm going with. Luckily, my server doesn't have mysqlnd, so I got to catch a couple of problems with MySQLi straight away.