[wp-hackers] Development Process

Sat Jul 29 15:21:03 GMT 2006

 I'd say that the most important issue isn't whether or how to implement
this type of system. But rather, a really concise explanation of plugin
architecture for "dummies", (aka the general user base, as opposed to those
with an inclination for development and adventure on their own) which is
available both in the codex plugins area AND the plugins download/extend
area of the site - something like - "before using plugins, Read Me First" - 
then, an explanation like :

TO users - if you're considering installing a plugin, please be aware that
there are two general ways which plugins function, {...} for the types of
plugins which are "benign" in nature and will have no potential security
impact, OR {....} these types of plugins have the potential to interact with
the backend functionality of WP, and thus depending on the particular plugin
authors implementation may expose this functionality to unwanted users, so
please be sure and check with the plugin author/documentation to be sure
that the plugin you'd like to use has been written in such a way to prevent
this unwanted behavior. Otherwise, use at your own risk. The WP team is
working on implementing a notification/update system for plugins which will
eventually notify you about updates/patches and enhancements to plugins you
have installed via the dashboard. 

TO Plugin Authors - As you may be aware, if your plugin presents admin panel
access to the user, you must exercise caution in your implementation. The
following guidelines for these types of plugins outlines a proper and secure
implementation {.......proper example and instructions on how to implement
current_user_can()...} Please don't forget to document your plugin as
completely as possible before releasing it to the public. In addition,
please take some time to go back and check your previously released plugins
to ensure a secure implementation. 

To digress for a moment, I'm pretty heavily involved with another OSS
project - xoops --, if you're not familiar with xoops go ahead and take a
look at xoops.org, I'm not going to go into details here except to highlight
the following - I primarily use three web based cms systems for sites I
manage and develop, and as far as advising clients. They are (in order of
complexity) wordpress, xoops, and typo3. For most 'simple' sites I use WP it
provides plenty of functionality. When a more powerful solution is required
(heavy reliance on complex functionality provided by things like osCommerce,
phpAdds, etc) I use xoops. I bring up xoops as an example because the
"plugin" called a module at xoops architecture is really tight. It is very
rigid, in that all "modules" are installed by the xoops backend system and
are controlled tightly. In many ways I like the Wp system better, it's
really lightweight ant flexible, however it leaves room for lots of problems
- for example, when you "deactivate" a wp plugin, if the plugin created any
db tables/rows, etc. the uninstall process at WP doesn't force the plugin to
clean up after itself, by contrast all xoops modules must clean up after
themselves if "uninstalled".  xoops also provides an "update" mechanism for
modules, although most module authors don't make use of the capability to
provide automattic updates, and It's not "forced" by xoops, it is there if
someone wishes to use it. As many of you may be aware, wordpress (currently
up to v 2.0.2) is available as a xoops module, a site can even be
constructed for example, where it appears to be running on WP, but is back
ended by xoops. Many of my sites operate in this manner. Full wp plugin
capability is of course supported. However, security wise, the xoops system
overrides the wp system, so that the types of "holes" we've been discussing
here are eliminated (so far as I have been able to test). I bring this up
because maybe it's time to consider a somewhat more rigid plugin system that
would enforce certain rules, which would eliminate potential holes created
by plugins. The idea of an optional notification or update system which
provides some type of notice or update capability through the dashboard is a
great idea, although wouldn't need to be forced upon users or plugin
authors. Plugin authors however would be required to write their plugins so
that they pass "install" and "uninstall" checks which would be designed to
ensure that they a) don't expose the security issues, and b) clean up after
themselves. This approach really takes the worry off of the plate of users,
and the responsibility off of the plate of the wordpress community and
places it with the plugin author instead, which is where it belongs in the
first place. In other words, if you want to hack something into your own WP
install, go right ahead, however as a community, we're not going to let you
allow users to install a plugin that doesn't meet our 'standards'. Which as
I would define them are 1) Plugin meets security requirements and checks
during activation/install and 2)Plugin cleans up after itself if a user
uninstalls/deactivates. Then optional plugin features become, 1)
update/patch notification via dashboard and 2) update capability from
"manage plugins". 

This requires some work on the part of the WP community to implement:
1) The plugin checks for security and cleanup/uninstall features needs to be
written/implemented in the plugin code. 
2) An interface for "update/patch" notification through the dashboard needs
to be implemented. 
3) An interface for updates via "manage plugins" needs to be implemented. 

Beyond that, WP in itself is a pretty secure environment if implemented
properly as it is, which is why I'm quite comfortable advising clients to
migrate from other systems to WP, or to use it as a simple CMS system for
their sites. Using this type approach, the WP development community can
focus on improving WP, performance, new features, etc. as opposed to
worrying about these other issues. And, as I mentioned in a previous post,
something like the FUD type posts can easily be addressed as - WP is a
secure environment, and checks all plugins prior to install against WP
security requirements. 

/**************************************
Christopher J. Hradil
chradil at comcast.net
http://www.hradil.us
**************************************/

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Matt Mullenweg
Sent: Friday, July 28, 2006 8:17 PM
To: wp-hackers at lists.automattic.com
Subject: Re: [wp-hackers] Development Process

Sam Angove wrote:
> But, whatever. This discussion went nowhere last time it came up, so I 
> don't see the point talking about it further unless a yay or nay comes 
> down from on high. Sad but true.

Actually it went to the "no one is willing to work on this right now" 
bin, it's obviously a good idea we want to do someday. This isn't a bad
thing, good ideas tend to continually resurface, it's darwinian.

Anyone can and has created cool services or enhancements that get official
blessing later, like the new themes site or plugins that we've included over
the years. Usually the constraining factor is personal commitment behind the
idea, not resources or infrastructure or holy water.

--
Matt Mullenweg
  http://photomatt.net | http://wordpress.org http://automattic.com |
http://akismet.com _______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers