moo.wp 1.0 arrives

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.

-John Havlik

[end of transmission, stay tuned]

moo.wp-r2 is here

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.

-John Havlik

[end of transmission, stay tuned]

Here Comes AJAX

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.

-John Havlik

[end of transmission, stay tuned]