[wp-hackers] Re: missing custom fields

Wed Jan 25 03:41:23 GMT 2006

Thanks for the quick response. Hook or not, I don't really see why it should
be limited at all. If I create custom fields I want to be able to use them.
No use limiting the drop selection of them.

Steve

-----Original Message-----
From: wp-hackers-bounces at lists.automattic.com
[mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of
wp-hackers-request at lists.automattic.com
Sent: Wednesday, 25 January 2006 12:49 PM
To: wp-hackers at lists.automattic.com
Subject: wp-hackers Digest, Vol 12, Issue 61

Send wp-hackers mailing list submissions to
	wp-hackers at lists.automattic.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.automattic.com/mailman/listinfo/wp-hackers
or, via email, send a message with subject or body 'help' to
	wp-hackers-request at lists.automattic.com

You can reach the person managing the list at
	wp-hackers-owner at lists.automattic.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wp-hackers digest..."

Today's Topics:

   1. missing custom fields (Stefan Hartweg)
   2. Re: Forum: High query count (Stefano)
   3. Re: missing custom fields (Mark Jaquith)
   4. Re: missing custom fields (Chris Meller)
   5. Re: Forum: High query count (Michel Valdrighi)
   6. Re: Forum: High query count (Chris Meller)
   7. Re: Forum: High query count (Mark Jaquith)
   8. Re: Forum: High query count (Rob)
   9. Re: Forum: High query count (David Chait)

----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Jan 2006 07:03:50 +1000
From: "Stefan Hartweg" <stefan at hartweg.net>
Subject: [wp-hackers] missing custom fields
To: <wp-hackers at lists.automattic.com>
Message-ID: <200601242104.k0OL3xaM001303 at post.webmailer.de>
Content-Type: text/plain;	charset="us-ascii"

Hi,
I have a lot of custom fields (25 or so) in Wordpress 1.5. The problem is
that for some reason only 10 are selectable from the drop down menu 'Add a
new custom field to this post'.
Does anyone know where to change the number of selectable custom fields in
the code (assuming that it's just a problem of not allowing more than 10
fields as a standard setting)?

Thanks.

Steve 

------------------------------

Message: 2
Date: Tue, 24 Jan 2006 22:36:32 +0100
From: Stefano <steagl at people.it>
Subject: Re: [wp-hackers] Forum: High query count
To: wp-hackers at lists.automattic.com
Message-ID: <qc7dt1hb44s5493m68c30uvhlof6a7angq at 4ax.com>
Content-Type: text/plain; charset=us-ascii

Il Tue, 24 Jan 2006 15:54:24 -0500, Chris Meller
<chris at doesnthaveone.com> scrive:

>Yeah, having this information somewhere would be nice. It should be  
>unobtrusive for those who have already seen (and ignored for one  
>reason or another) it... I like Podz's idea about including it in the  
>setup process, but I think there should also be a display in the  
>actual dashboard that shows you this information, so you can see when  
>things may change (like my wp-content no longer being writable after  
>I moved servers... arggghhh!).

+1

I think Podz's idea is great and you addendum it is too. Maybe we can
disucss it with Matt on the IRC Meetup of tomorrow evening

-- 

Stefano Aglietti - StallonIt on IRCnet - ICQ#: 2078431
Email: steve at 40annibuttati.it steagl at people.it
Sites: http://www.40annibuttati.it
       http://www.wordpress-it.it

------------------------------

Message: 3
Date: Tue, 24 Jan 2006 17:39:08 -0500
From: Mark Jaquith <mark.wordpress at txfx.net>
Subject: Re: [wp-hackers] missing custom fields
To: wp-hackers at lists.automattic.com
Message-ID: <30AFB1F2-71FF-4C2D-BFF3-34C5679917C0 at txfx.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 24, 2006, at 4:03 PM, Stefan Hartweg wrote:

> Does anyone know where to change the number of selectable custom  
> fields in
> the code (assuming that it's just a problem of not allowing more  
> than 10
> fields as a standard setting)?

Lines 843-150 in /wp-admin/admin-functions.php (latest SVN checkout):

> function meta_form() {
> 	global $wpdb;
> 	$keys = $wpdb->get_col("
> 			SELECT meta_key
> 			FROM $wpdb->postmeta
> 			GROUP BY meta_key
> 			ORDER BY meta_id DESC
> 			LIMIT 10");

Might be a good place for a hook... $num = apply_filters 
('dropdown_key_number', '10'); and then use $num in the query.  Gives  
us the flexibility to change it, without cluttering the options table  
for everyone.

--
Mark Jaquith
http://txfx.net/

------------------------------

Message: 4
Date: Tue, 24 Jan 2006 17:50:24 -0500
From: Chris Meller <chris at doesnthaveone.com>
Subject: Re: [wp-hackers] missing custom fields
To: wp-hackers at lists.automattic.com
Message-ID: <C9B8E6A6-25CD-4156-A7E3-5A3025F8FCE8 at doesnthaveone.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 24, 2006, at 5:39 PM, Mark Jaquith wrote:

> On Jan 24, 2006, at 4:03 PM, Stefan Hartweg wrote:
>
<snip>
> Might be a good place for a hook... $num = apply_filters 
> ('dropdown_key_number', '10'); and then use $num in the query.   
> Gives us the flexibility to change it, without cluttering the  
> options table for everyone.
>

Hook is a good idea, but I don't think something like this  
(configuration for a built-in feature) should be plugin-dependent.  
Seems there should certainly be an option for this (which doesn't  
preclude the possibility of a hook for it as well for maximum  
flexibility).

--
Chris Meller
chris at doesnthaveone.com

------------------------------

Message: 5
Date: Tue, 24 Jan 2006 23:57:19 +0100
From: Michel Valdrighi <michelv at gmail.com>
Subject: Re: [wp-hackers] Forum: High query count
To: wp-hackers at lists.automattic.com
Message-ID:
	<125fee7f0601241457h505c859ey409a9d0ee6a75cb8 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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.

> 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.

--
Michel Valdrighi
Deviloppeur Web Intraordinaire
http://zengun.org/weblog/

------------------------------

Message: 6
Date: Tue, 24 Jan 2006 18:08:46 -0500
From: Chris Meller <chris at doesnthaveone.com>
Subject: Re: [wp-hackers] Forum: High query count
To: wp-hackers at lists.automattic.com
Message-ID: <FF396DFB-1BD1-4ABA-B9A1-AE9FF1F683BF at doesnthaveone.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 24, 2006, at 5:57 PM, Michel Valdrighi wrote:

> 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.

Big red letters may be a bit much... I dislike software that inspires  
panic with things like that which may or may not be a real issue.  
Still, I think it should be mentioned somewhere. The "Alerts" (or  
similar) tab on the Dashboard would keep it out of the way for people  
who are aware there's a problem, yet still allow you to see what's  
going on.

You could then include the ability to acknowledge or simply close an  
alert (anyone used Veritas Backup Exec? I'm thinking along the lines  
of their alerts here). After you acknowledge a respective error, it  
never shows back up again, or simply suppresses any visible  
notification and is confined to the special panel that displays that  
information exclusively. That way, we could tell people there may be  
something wrong on the Dashboard and point their attention to the  
Alerts area so they could investigate before their entire site blows  
up because their wp-content folder wasn't properly permissioned after  
a server migration (grrrrr again).

>
>
>> 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.

We would certainly want some method for dismissing errors, because  
there are a lot of situations in which this would come up -- if your  
host runs in safe mode and there's no way for you to change it, you  
don't want to get slapped with a big red error message every time you  
load a page.

> 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.

I like this idea, because you're right. A lot of plugin / theme  
authors (myself included) don't do enough error checking -- it works  
on all the setups they've tested just fine, but then again they don't  
have PHP running in safe mode anywhere, so it barfs on some random  
user somewhere and no one knows why. If the plugin could just list a  
few requirements (we'd have to dumb them down, since I imagine a lot  
of people wouldn't know what safe mode allows or prohibits -- myself  
included again) and have WP check against them automagically when the  
plugin is activated, it'd be great.

So, did a certain someone just volunteer to write this code for us? :)

--
Chris Meller
chris at doesnthaveone.com

------------------------------

Message: 7
Date: Tue, 24 Jan 2006 18:11:10 -0500
From: Mark Jaquith <mark.wordpress at txfx.net>
Subject: Re: [wp-hackers] Forum: High query count
To: wp-hackers at lists.automattic.com
Message-ID: <D3A7FA68-90ED-4FBC-B086-AD3A380FBB65 at txfx.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 24, 2006, at 5:57 PM, Michel Valdrighi wrote:

> 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.

But in the vast majority of hosting situations (as most people are  
using shared hosting), this (safe mode) is NOT something that the  
user can fix on their own.

--
Mark Jaquith
http://txfx.net/

------------------------------

Message: 8
Date: Wed, 25 Jan 2006 02:14:50 +0000
From: Rob <powzor at gmail.com>
Subject: Re: [wp-hackers] Forum: High query count
To: wp-hackers at lists.automattic.com
Message-ID: <43D6DF1A.2020306 at robm.me.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Chris Meller wrote:
> Big red letters may be a bit much... I dislike software that inspires 
> panic with things like that which may or may not be a real issue. 
> Still, I think it should be mentioned somewhere. The "Alerts" (or 
> similar) tab on the Dashboard would keep it out of the way for people 
> who are aware there's a problem, yet still allow you to see what's 
> going on.
>
> You could then include the ability to acknowledge or simply close an 
> alert (anyone used Veritas Backup Exec? I'm thinking along the lines 
> of their alerts here). After you acknowledge a respective error, it 
> never shows back up again, or simply suppresses any visible 
> notification and is confined to the special panel that displays that 
> information exclusively. That way, we could tell people there may be 
> something wrong on the Dashboard and point their attention to the 
> Alerts area so they could investigate before their entire site blows 
> up because their wp-content folder wasn't properly permissioned after 
> a server migration (grrrrr again).
I quite like the way Drupal does this. It's been a while since I used 
it, but IIRC: in the admin screen, there's an error log, with the 
severity of the error clearly indicated (notices in white, warnings with 
a yellow triangle and errors with a red X). A description of the error 
and the time it occurred is given, and the user can filter or clear the 
list as they wish.

So long as the descriptions gave enough information for tech-savvy users 
to fix things themselves, and directed less-tech savvy users to places 
where they could find help, it'd be great.

-- 
Rob Miller
http://robm.me.uk/ | http://kantian.co.uk/

------------------------------

Message: 9
Date: Tue, 24 Jan 2006 21:46:53 -0500
From: "David Chait" <davebytes at comcast.net>
Subject: Re: [wp-hackers] Forum: High query count
To: <wp-hackers at lists.automattic.com>
Message-ID: <007001c62159$99b26890$6e01a8c0 at sixfour>
Content-Type: text/plain;	charset="iso-8859-1"

| 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 
queries/features.

-d 

------------------------------

_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers

End of wp-hackers Digest, Vol 12, Issue 61
******************************************