Send wp-testers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.automattic.com/mailman/listinfo/wp-testers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wp-testers digest..."
Today's Topics:
1. php and word press problems (Marvin Hunkin)
2. Re: php and word press problems (John Blackbourn)
3. Custom post type capabilities not fully set up on
registration (Andrew Macaulay-Brook)
4. Re: Custom post type capabilities not fully set up on
registration (Andrew Nacin)
5. Re: Custom post type capabilities not fully set up on
registration (Andrew Macaulay-Brook)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Oct 2010 10:45:50 +1100
From: "Marvin Hunkin" <[email protected]>
Subject: [wp-testers] php and word press problems
To: <[email protected]>
Message-ID: <2f2863d6f386428c92a68c12cfea4...@marvinpc>
Content-Type: text/plain; charset="iso-8859-1"
?hi.
the person who sent me the code to turn on php.
cold they resend the code to me and the process to get it to work.as
lost
it
.
thank you.
marvin from australia.
------------------------------
Message: 2
Date: Thu, 21 Oct 2010 04:19:09 +0100
From: John Blackbourn
<[email protected]<johnbillion%[email protected]>
Subject: Re: [wp-testers] php and word press problems
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Marvin, the wp-hackers mailing list isn't for support; it's for
discussion on WordPress hacking and core development of the platform.
The information you want is freely available on the web. Try Googling
for any phrase like "how to turn on php" and you'll get hundreds of
thousands of results.
Also, if you're struggling with setting up PHP you might be better off
going with a cheap shared host. There are some recommendations here:
http://wordpress.org/hosting/ .
John
On Thu, Oct 21, 2010 at 12:45 AM, Marvin Hunkin <[email protected]>
wrote:
?hi.
the person who sent me the code to turn on php.
cold they resend the code to me and the process to get it to
work.aslost it
?.
thank you.
marvin from australia.
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
------------------------------
Message: 3
Date: Thu, 21 Oct 2010 12:08:46 +0100
From: Andrew Macaulay-Brook <[email protected]>
Subject: [wp-testers] Custom post type capabilities not fully set up
on registration
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I can't work out whether this is covered by
http://core.trac.wordpress.org/ticket/14122 or not.
I'm using a custom post type called property, assigning capabilities
using
'capability_type' => 'property' and then giving my Editors *_property
and
*_propertys capabilities wherever I can see they already have *_post or
*_posts.
The rationale for all this is that it lets me turn off all the
capabilities
for blog Posts, hiding the Posts menu for Editors, as this site doesn't
use
the blog. I then give my client an Editor level login.
I'm mapping meta-capabilities using Justin Tadlock's code at
http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-types
Problem: Neither my clients, nor the Admin login can Trash custom posts.
It seems that using the argument 'capability_type' => 'property' only
sets
up the following mappings in the post type object:
<!-- Capability mapping: stdClass Object
(
[edit_post] => edit_property
[edit_posts] => edit_propertys
[edit_others_posts] => edit_others_propertys
[publish_posts] => publish_propertys
[read_post] => read_property
[read_private_posts] => read_private_propertys
[delete_post] => delete_property
)
-->
... which I generated using $post_type = get_post_type_object(
$post->post_type ); print_r($post_type->cap);
It looks like the mappings for $post_type->cap->delete_posts and
$post_type->cap->delete_others_posts aren't being set up.
I've got an issue with taxonomy capabilities too, but that's my next
job.
Andrew Macaulay-Brook, BEng MBCS CITP, trading as theburo.net
mailto:[email protected] ? http://www.theburo.net/
------------------------------
Message: 4
Date: Thu, 21 Oct 2010 07:29:13 -0400
From: Andrew Nacin <[email protected]>
Subject: Re: [wp-testers] Custom post type capabilities not fully set
up on registration
To: [email protected]
Message-ID:
<[email protected]<aanlktincxxjucdok-pw%[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 21, 2010 at 7:08 AM, Andrew Macaulay-Brook <[email protected]
wrote:
I can't work out whether this is covered by
http://core.trac.wordpress.org/ticket/14122 or not.
I'm using a custom post type called property, assigning capabilities
using
'capability_type' => 'property' and then giving my Editors *_property
and
*_propertys capabilities wherever I can see they already have *_post or
*_posts.
The rationale for all this is that it lets me turn off all the
capabilities
for blog Posts, hiding the Posts menu for Editors, as this site doesn't
use
the blog. I then give my client an Editor level login.
I'm mapping meta-capabilities using Justin Tadlock's code at
http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-types
Problem: Neither my clients, nor the Admin login can Trash custom
posts.
It seems that using the argument 'capability_type' => 'property' only
sets
up the following mappings in the post type object:
<!-- Capability mapping: stdClass Object
(
[edit_post] => edit_property
[edit_posts] => edit_propertys
[edit_others_posts] => edit_others_propertys
[publish_posts] => publish_propertys
[read_post] => read_property
[read_private_posts] => read_private_propertys
[delete_post] => delete_property
)
-->
... which I generated using $post_type = get_post_type_object(
$post->post_type ); print_r($post_type->cap);
It looks like the mappings for $post_type->cap->delete_posts and
$post_type->cap->delete_others_posts aren't being set up.
This is indeed the same ticket at issue.
If you read Justin's post again, you'll see that he deliberately sets up
those additional capabilities by overloading what gets passed to the
capabilities array.
I haven't yet got around to committing my meta capabilities patch for
3.1
yet, basically because after a few attempts I don't think I've quite
nailed
it yet.
But what you'll see is when map_meta_cap is true (a new flag for
register_post_type), then these additional capabilities will need to be
set
up, or WordPress will do it for you, based on capability_type.
Hope that makes sense.
Nacin
------------------------------
Message: 5
Date: Thu, 21 Oct 2010 12:44:49 +0100
From: Andrew Macaulay-Brook <[email protected]>
Subject: Re: [wp-testers] Custom post type capabilities not fully set
up on registration
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Thanks Andrew - depends on how literally you read Justin's post I guess.
I
read "I?ve also added in a couple of extra capabilities that were not
shown
in my previous tutorial on post types: delete_posts and
delete_others_posts." and didn't mentally add "because WordPress doesn't
do
it." :-)
I'll use the overloading instead of being lazy and look out for the
patch -
is it looking definite for 3.1?
A.
On 21 Oct 2010, at 12:29, Andrew Nacin wrote:
On Thu, Oct 21, 2010 at 7:08 AM, Andrew Macaulay-Brook <[email protected]
wrote:
I can't work out whether this is covered by
http://core.trac.wordpress.org/ticket/14122 or not.
I'm using a custom post type called property, assigning capabilities
using
'capability_type' => 'property' and then giving my Editors *_property
and
*_propertys capabilities wherever I can see they already have *_post
or
*_posts.
The rationale for all this is that it lets me turn off all the
capabilities
for blog Posts, hiding the Posts menu for Editors, as this site
doesn't
use
the blog. I then give my client an Editor level login.
I'm mapping meta-capabilities using Justin Tadlock's code at
http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-types
Problem: Neither my clients, nor the Admin login can Trash custom
posts.
It seems that using the argument 'capability_type' => 'property' only
sets
up the following mappings in the post type object:
<!-- Capability mapping: stdClass Object
(
[edit_post] => edit_property
[edit_posts] => edit_propertys
[edit_others_posts] => edit_others_propertys
[publish_posts] => publish_propertys
[read_post] => read_property
[read_private_posts] => read_private_propertys
[delete_post] => delete_property
)
-->
... which I generated using $post_type = get_post_type_object(
$post->post_type ); print_r($post_type->cap);
It looks like the mappings for $post_type->cap->delete_posts and
$post_type->cap->delete_others_posts aren't being set up.
This is indeed the same ticket at issue.
If you read Justin's post again, you'll see that he deliberately sets
up
those additional capabilities by overloading what gets passed to the
capabilities array.
I haven't yet got around to committing my meta capabilities patch for
3.1
yet, basically because after a few attempts I don't think I've quite
nailed
it yet.
But what you'll see is when map_meta_cap is true (a new flag for
register_post_type), then these additional capabilities will need to be
set
up, or WordPress will do it for you, based on capability_type.
Hope that makes sense.
Nacin
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
Andrew Macaulay-Brook, BEng MBCS CITP, trading as theburo.net
mailto:[email protected] ? http://www.theburo.net/
------------------------------
_______________________________________________
wp-testers mailing list
[email protected]
http://lists.automattic.com/mailman/listinfo/wp-testers
End of wp-testers Digest, Vol 68, Issue 5
*****************************************
