There is a regression regarding support of static front pages in Breadcrumb NavXT 2.1.3. It has been fixed with the help of a few alert users. You can hotfix your installation if needed, by grabbing the latest breadcrumb-navxt-class.php from SVN. The cause was some cleaning of the class, which inadvertently removed a branch from a if statement that was not orphaned as previously thought. This obviously will make it into the 2.1.4 release, which will be released before the 18th of July. Version 2.2 will debut in late July/early August.
Later this week a new release of Berry will be available. I’ve fixed a number of bugs, and tweaked the comments form. There seems to be a text size bug that will need fixing before the release is made, look for it on Friday.
MooTools 1.2 was released a week or so ago, thus out dating Mtekk’s Testimonials. I’ll get to work on updating that with some nice fixes along with migration to MooTools 1.2. Hopefully, that can be ready before the 18th. With the release of MooTools 1.2 work on WP Trainer will begin (again). Subcomponents of WP Trainer are already complete, the plug-in part itself is what need to be made, along with an interface of sorts. Deciding on the UI is one reason the project keeps getting deferred until later.
It time for the third service release for Breadcrumb NavXT 2.1. This is the second to last planed release for the 2.1 branch, heavy development for 2.2 begins this weekend. There are some fixes with bugs in the core breadcrumb class, especially relating to having a post as a member of both a parent category and one of its children. Some administrative interface cleanup has taken place, and the German translation was resynchronized with the administrative interface. Yesterday was the intended release date however a wait for the German translation to finish synchronizing took place, it is not fully up to date, but by the end of the week the distribution will have it fully updated.
New features to look for in 2.2 include fully customizable anchor structures (yes, that means you can use the rel=”” element for those who want nofollows (I’d advise against using nofollows, but that does not mean we’ll stop you)). Breadcrumb trails will no longer require to contain linked elements (for if you want to have them in your HTML title). Plus a bunch of other things. Begining today the Development build from SVN is considered unstable and possibly broken.
Announcing the immediate availability of Iframe-B-Gone 1.1.0. This new version’s interface matches better with WordPress 2.5’s new dashboard. A dashboard widget performs quick scans of the default terms (yes terms, delimited by commas) and counts how many infections have been cleaned. Note that even with multiple search terms possible, only automatic removal of iframe tags is fully supported. That said, the WordPress Exploit Scanner may be a more valuable tool even though it does not automatically protect against iframe injections.
Maintenance release 3 for the 2.1 series is almost ready, some final fixes and checks are being made. Tom, once again had some significant input on this version. The administrative interface was tweaked a little, plus some fixes were made to the core class. There is a new look for the administrative interface, but its introduction may wait until 2.2 (the code for it will be there, just one line will be commented out to prevent it from running, adventurous users can uncomment that line if they wish). Speaking of which, 2.2 is going to have significant changes, some of which have already been set in motion.
The “API” for Breadcrumb NavXT is changing in 2.2, the existing functions for backward compatibility will not exist in 2.2. Additionally, in 2.2 some redundant options will be removed. This is for better integration into WordPress. Internally, many things will be changing for 2.2 as more of an object oriented approach in implemented. Realistically speaking, this is just a natural evolution of the breadcrumb class, which was set in motion back in 2.0.
In August of this year PHP4 will reach its end of life. Even though WordPress may continue to support PHP4, we will not. Most webhosts have PHP5 available for their customers, if PHP5 is not enabled on your site yet ask your webhost how to enable it. After August 8, 2008 the official solution to any problem experience in a PHP4 environment is to switch to PHP5 and retest. This may sound arrogant, but it is time for PHP4 to go the way of PHP3 and the dodo.
The folks over at Instinct Entertainment released WP e-Commerce 3.6.6 today and received not so great feedback from users. Looks like 3.6.6 is a bit buggy. Sadly, this does not surprise me one bit. Take a look at the code, and try to grasp what is going on.
A year ago I muddled around, and hacked an older version of it (was the newest version at the time) apart for a client of mine. At the time the code was a nightmare to navigate. This spring when they wanted to add more features, some of which were in the newer 3.6 branch, I did some research on the changes between versions. Sadly, things have not gotten better (code organization wise).
Right now, WP e-Commerce is not open source. It however, is the only solution for users that want to use Authorize.net. The client that I made the modifications to WP e-Commerce for at one point proposed just making our own plug-in. Since I personally do not have an interest in establishing a e-commerce site, I will not spontaneously produce a e-commerce plug-in.
Should such a competing plug-in be released by me a few things can be guaranteed about it.
Fully commented source, just about every line will have an explanation, functions commented properly, with explanations of their prototypes.
Clean, fast code that is object oriented when appropriate.
Highly modular, easy to remove unwanted/unneeded features. Items included in the HTML head are reduced to only what is needed.
Predictable release time line similar to that of Breadcrumb NavXT and WordPress. Monthly bug fix releases, new features released the same month as a WordPress “major release” (e.g. 2.2, 2.3, 2.5 were major releases), or every three to four months (I try to keep bug fix releases fixed to three or four max).
100% Open Source licensed under the GNU GPL2.
Numbers 1,2,3,6 and 7 would be there from the get-go. The fifth one would be introduced in time, and the fourth would be an ongoing thing. Development would begin as .1 and not follow any particular time line for releases until 1.0 is reached. By 1.0 it would be stable, though by .8 or so it’d be a suitable replacement to WP e-Commerce.