[wp-hackers] Forum: High query count

David Chait davebytes at comcast.net
Wed Jan 25 02:46:53 GMT 2006

| On 1/24/06, Mark Jaquith <mark.wordpress at txfx.net> wrote:
| > On Jan 24, 2006, at 10:02 AM, David Chait wrote:
| > > BTW, Ryan, would be nice if the dashboard had in red letters "Your
| > > hosting setup doesn't support caching to disk!" -- no joke,
| That's risking hosts getting angry customers feedback like "they say
| they support WP but WP says the host is not OK!", so the message
| should make it clear that it's something the user could fix by
| herself.

If it is a host-config issue, it should be noted as such.  Given the 'need' 
for caching for optimizing performance of both core and plugins, things like 
this should be flags that the host has a 'bad configuration' of sorts.

Most importantly, if plugins AND wp-core are making assumptions, for good 
reason, that wp-content should (and IMHO must) be writeable, that error 
should be left prominent (again, unless specifically 'dismissed' as others 
have proposed), as it'll affect things in major ways on that system.

Further, given the level of 'crap' in the dashboard (again, IMHO), this is 
something that ISN'T crap.  It should be at the same level as a notification 
of pending security patches or major updates (that is, generally visible 
unless 'turned off' somehow).

(Once more: IMHO! ;) :) )

| > It might be nice to throw up errors for other common problems such
| > as /wp-content/ not being writable.
| >
| It might be even nicer to take this idea further and define "server
| capabilities" flags, that could be used for dependency checking in
| plugins.
| After all, maybe I don't want to have wp-content writable.
| But if I activate a plugin that needs it, it would be better if it got
| deactivated right away with a message telling me that it needs to be
| able to write to wp-content.
| All too often the reality is different: plugin tries to write, fails
| and spews an error, WP's output buffering makes the page blank, user
| is confused. By enabling plugins to prevent such failures, WP would
| become more solid to both plugin developers and users.

Granted, that'd be nice longer-term, but a simple messaging system could 
make it into a build in the near-term.  Very near term -- this isn't 
complex, and the cases to be 'detected' are already being detected.

Also, the onus should be on the plugin >system< to provide standard 
information to plugins, like 'this host cannot write to files', or 'this 
host can write to wp-content' -- well, a standard base set of 


More information about the wp-hackers mailing list