angsuman

Frame Buster or the Javascript code is good so long your users have Javascript enabled.

ElNota

You need to be more specific about what code you are trying to insert and what is exactly happening. I use AdRotator on several sites without issues.

The plugin requires text file to contain one ad per line.

Use a plain text editor like notepad, vi, pico, emacs, jext, jedit etc.

If you would like support for the plugin please post your comment on the plugin site and include more details.

I see. So you want use the XMLRPC interface of WordPress. Search for XMLRPC on this site. Configure Newsgator to use “Movable Type” or “Blogger” API. Point it to http://yoursite/xmlrpc.php

What do you mean by adding newsgator?
Do you want to add rss feeds?

This is not related to SK2.
I wonder if this is an example of exploit of the security vulnerabilities in WP 1.5.1.2 and lower.
What version of WordPress are you running?

Look at secunia. There are now tons of critical security defects in wide ranging PHP products. makes you wonder isn’t it?
I said before php as a language is not vulnerable. But many of its libraries are. Simplicity comes at a price.

@skippy
> please feel free to participate in the discussion as to what “real improvements” you think are necessary.

I am not sure if this is the right place but here it goes.

> I think removing 400 lines of duplicated code in post.php is a real improvement.

That is really refactoring. It doesn’t help the client directly in the short term. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?

> I think more plugin hooks are a real improvement.

Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don’t take much time to add but we shouldn’t indiscriminately go down that path.

BTW: Don’t talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.

> I think a robust user capabilities system is a real improvement over arbitrary user levels.

Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?

One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.

Many important functions are not documented in codex, which I often find in the code.

Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven’t upgraded even today as you can see in the forums. And they are hence open to security vulnerabilities. A patch for their releases would have gone a long way in helping these users.

I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken in this respect for backward compatibility.

WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release. Much of it is grunt work but that’s software development. It is not always about doing the coolest thing.

Themes break everywhere with new releases. Why? We need to find out.

Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.

WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in my blog, couldn’t find time yet to release them as plugins. Another reason is that they shouldn’t be plugins in the first place but part of core code.

WordPress needs to publish its architecture. Serious re-factoring needs to be done in places.

WP community should issue patches, especially for security upgrades. Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blanket statements like it will be tougher for those who modify etc.

I think the above should have higher priority over ajaxian niceties and draggable menus.