Another week in the books.  Decent week, though not as good as last week.  This report covers revs 274 through 303.

• Menu item editing and deletion has been finished and rolled in.  This signals the end of all things menus (for now).
• The 2.6.0 update file got some love this week, mainly just keeping up with some of the database changes.
• Worked on the update options.  Admins will now be able to decide if they want to be notified about SMS updates.  Currently, the options are all updates, major updates (2.6.0, 3.0), or none.  I may still add an option for security releases as well.
• Fixed a bug in the site globals page that was leftover from a feature I had started working on but decided against.
• Added some logic to the bio pages to handle the old way awards are done.  Now, there’s a date awarded a reason.  If those items weren’t there, it’d spit back some Apache warnings.
• The toggling of mission notes and notes (menu management page) now use a sliding toggle instead of just an appear toggle.
• Turns out the mission notes management page wasn’t using the new tabs yet.  It is now.
• I thought I’d fixed the Cobalt issue where the small login button was missing its file extension, but apparently I hadn’t.  It’s fixed now.  What probably happened was that I fixed it for the skin and not on the trunk.
• Adding the word DENY and its variants to the query check class for use by the starbase docking request code.
• Added the docking request AJAX pages.
• Finished up the new activation page and rolled it in.  Yay for being done with this beast!
• Some general trunk cleanup work.
• Mission management now uses tabs to separate current, upcoming, and completed missions.  Much cleaner now.
• Finally, I started playing around with version 2 of the ship skin.  It’s early still, but it gives me something to work on that isn’t just staring at code all day long.  The nice thing about the new ship skin is that all the ship images are in the same skin and it talks to the database to find out what class of ship you have.  This also means it’s easy to add new ships to it.

That’s about it for this week.  Next week should see a whole slew of new things and more things knocked off the to do list.  Until next time.

No promises here, but one thing I’ve been looking at for SMS 3 is rich text editing.  Early on in the SMS 2 cycle, a lot of people were asking for it, but it kept getting pushed back.  Well, it landed on the SMS 3 roadmap and this morning I stumbled on something that just might make it a bit more of a reality: markItUp!  We’ll see what happens, but it’s a step in the right direction.

I was swinging through the CI forums this afternoon and came across a post from Derek Allard, one of EllisLab’s technical architects.  He said, and I quote: “we won’t be ‘holding out’ [CI with Javascript libraries] until EE2 or anything, as soon as its ready we’ll announce it and get it into your hands.”  This is great news as it means less of a wait on starting SMS 3!

PHP

SMS 3 will require PHP version 4.3.0 or higher.  This shouldn’t be too much of a problem as most free hosts are already using PHP versions at or higher than this.  PHP 4 is end of life, but unfortunately, that doesn’t mean much to most free hosts.

MySQL

SMS 3 will require MySQL version 4.0.0 or higher.  This could be more of an issue, but since MySQL 3.x hasn’t been supported since December 31, 2006, I think it’s time to leave it behind.  Just in case though, check with your host to see what version of MySQL you’re running.  If it’s under 4, begin to ask your host when they’ll be upgrading to 4.x or even 5.  MySQL 4 goes end of life later this year, so they really should be moving toward 5.

Other Databases

I’ve gotten the question before, so I figure I’ll stoke the flames a little bit with this post.  There may (and I do stress the may part) end up being support for additional databases in addition to MySQL.  CodeIgniter supports MSSQL, SQLite, MySQLi, OCI8, and PostgreSQL.  It’s all in the installation module.  From there, you could easily change your setup to use another database type.  I’d just have to make sure the installation is written in such a way that works across multiple databases.  Obviously there will be more on this as we get into development.

Another week, another slew of commits as we inch toward the SMS 2.6 beta. This week, especially the latter half, saw some major things get scratched off the to do list. Next week should see some more big items off the list as well. This report covers revs 246 through 273.

• A lot of work was done on some of the AJAX pieces this week. Because of this, our query check file needed to have a new action added to one of the methods.
• Refined the user acceptance and rejection code, specifically the fact that a pending user won’t have a rank to use as a wild card. That’s been removed from the rejection message.
• The post, log, and news AJAX activation/deletion pages now display the entire content of the post/log/news item right in the modal window. A simple overflow-y class was used so that a scrollbar will appear if the text is longer than the overflow area. This also allowed me to remove the tables from all 6 AJAX pages to make them a bit cleaner.
• The user, post, log, news, and awards sections of the new activation page have been written, meaning that only the starship docking piece has yet to be finished!
• I got side tracked during some stuff today and tackled all the Apache warnings and errors on the Mission Post management page. Worst. Apache. Debug. Ever. Not looking forward to the other management pages. On the bright side, I was able to re-write a chunk of it to make it a bit more efficient. Still, 90 minutes on debugging Apache errors is out of control.
• Updated the awards queue database table to use a rejected field as well as pending and accepted. This way, there’s a complete record of every nomination ever sent in.
• Found some stray references to images that were removed last week.
• Updated the install and update files to reflect some database changes that happened this week.
• Added some UI Tabs styles to handle the nested tabs that are going to be needed for the menu management page.
• The beast that is menu management. Going in to today, the menu management pages were the only two NOT using the new jQuery tabs. I was dreading doing these pages, but decided to tackle them tonight. Once I was about 5 minutes into it, I realized they were going to have to be re-written. Of course, once I took a step back and looked at everything, I realized that re-writing these pages meant I could take 2 menu pages and turn them into 1. Along with this, 3 new AJAX pages were added so that menu items can be created, edited, and deleted from modal windows.
• The query check class had to be updated again to reflect the menu management changes.
• The basic and advanced menu management pages were removed, leaving only a lone menu page. Huzzah!

Lots of great stuff this week. I was especially excited about being able to cross the item about finishing the conversion of tabs to the jQuery tabs off the list. Surprisingly, I got the award queue acceptance/rejection stuff right on the first attempt. That was exciting. There’s only one more piece to the new awards stuff and then that piece is done.

On next week’s agenda is finishing the activation page and getting that plugged in to the main system (currently it’s a separate page). Also, I want to get more of these AJAX pieces plugged in. Right now, mission creation is done through an AJAX page, but ranks, positions, departments, awards, and tour items need to be added. Those are the major goals. I’m sure other stuff will come up, including lots of Apache debugging. One week closer to beta. In a few weeks here, I should have a better idea of how long until we hit beta.