Since the original author of Breadcrumb Navigation XT ran out of time for further development of the WordPress plug-in, I have picked it up. After a few days of coding and working on setting up the code section of this blog, the new version is ready for release. This new version, 1.8.0, includes support for author pages, and limiting the number of categories displayed in the breadcrumb.
Note that beginning with this release the version numbering scheme is to follow the same as WordPress uses, the first digit changes for major changes and as the second runs past 9. The second digit changes with the addition of features, internal structure of the class will not change in with a change in this digit. Finally, the third digit signifies a bugfix to features previously introduced without any added features. The next version, 1.9, is planned for the release of WordPress 2.3 due to the addition of tags into WordPress.
Finally RPC-heir should work as expected; it only took two weeks of frustration, and the creation of a now unneeded subdomain, plus a little extra code in the default index.php file. In this though, security is higher, as only people on weblogs.us servers can ping the RPC server, otherwise they will receive xHTML.
Moo.wp, the mootoolkit manager plug-in for WordPress is now considered stable and acceptable for mass distribution. Build 30, also know as 1.0, now includes moo.dom for DOM support if the prototype.lite library is used. More updates may come with time, but as for now development for moo.wp is completed. Grab 1.0 from the moo.wp page.
Come and get it while it’s hot. The mootoolkit manager for WordPress is available now for per-release testing. Just go on the side bar to Moo.wp to arrive at the plug-in’s page. This release is fully functional and ready for developer integration. For plug-in writers, just check for the moowp_display() function to verify that moowp is installed and working. Release 2, or rather per-release 2 contains moo.fx 1.2.3, moo.fx.pack 1.2.4, moo.AJAX 1.0, prototype.lite, and prototype 1.4.0. On the backend there are idiot-resistant checks that keep dependencies fulfilled to reduce errors. Hopefully this will be helpful for some one out there.
As of this writing the Testimonials plug-in is mostly written, with all essential backend code in place. Users are able to view, and submit their own testimonial at will. These submitted testimonials aren’t viewable until they are approved by an administrator. In the administration panel, an administrator may add in, approve, unapproved, delete, and edit testimonials. All variables represented in the database for each testimonial may be edited in the testimonial’s individual edit page, even its unique ID. This was to overcome a slight issue that to resolve completely would require too many extra database reads and writes. Now work resumes on the layout end and AJAX functions for the plug-in. One last feature set would be nice to add to the admin panel is an option for randomizing the first seen testimonial. I just need to figure out where/how other plug-ins have been saving their settings as WordPress doesn’t specify a certain location in their API documentation.
I’m considering creating a Moo.fx plug-in for WordPress, so that various plug-ins can share a common library instead of many separate ones. It’ll have an admin panel that allows to select the inclusion of various parts of the Moo.fx family, incase not all of them are needed. Then all plug-ins with Moo.fx/prototype dependencies can just look for the function wp_moo.fx and if it exists, they can use that instead of adding redundant lines to the head of the xHtml document.