[wp-hackers] Forum: High query count
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
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
| 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