[wp-hackers] DO NOT WRITE ME AGAIN
Lucia Lan
lan.lucia at yahoo.com
Sun Nov 21 18:21:28 UTC 2010
--- On Mon, 6/21/10, wp-hackers-request at lists.automattic.com <wp-hackers-request at lists.automattic.com> wrote:
From: wp-hackers-request at lists.automattic.com <wp-hackers-request at lists.automattic.com>
Subject: wp-hackers Digest, Vol 65, Issue 48
To: wp-hackers at lists.automattic.com
Date: Monday, June 21, 2010, 2:03 PM
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. Re: Math Comment Spam Protection plugin 2.2 doesn't work with
WP 3.0 (Michel Bozgounov)
2. Re: wp-hackers Digest, Vol 65, Issue 47 (Ash Goodman)
3. Re: Math Comment Spam Protection plugin 2.2 doesn't work with
WP 3.0 (Frank Bueltge)
4. Re: support for custoim post types + custom feilds (Jeremy Clarke)
5. new menu management 3.0 (Ash Goodman)
6. Re: new menu management 3.0 (Japh)
7. Re: new menu management 3.0 (Piyush Mishra)
8. Re: new menu management 3.0 (ErisDS)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Jun 2010 15:08:05 +0300
From: Michel Bozgounov <info at optimiced.com>
Subject: Re: [wp-hackers] Math Comment Spam Protection plugin 2.2
doesn't work with WP 3.0
To: wp-hackers at lists.automattic.com
Message-ID: <4C1F5625.2080102 at optimiced.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
--------------------------------------
From: Frank Bueltge <frank at bueltge.de>
Subject: Re: [wp-hackers] Math Comment Spam Protection plugin 2.2
doesn't work with WP 3.0
only a fast view from me; i think its a problem with the $user_ID in
the plugin, this var is in WP3.0 0, not isset.
i attached a version with small changes, please test it.
Hi, Frank,
Thanks for the hint!
Unfortunately, I do not see an attachment here -- are attachments to
messages automatically removed from the list (or I don't see it)? Can
you post the php file/code somewhere, with a link? Many thanks!! :)
Cheers,
--M.
------------------------------
Message: 2
Date: Mon, 21 Jun 2010 20:31:16 +0800
From: Ash Goodman <ash at thinkinginvain.com>
Subject: Re: [wp-hackers] wp-hackers Digest, Vol 65, Issue 47
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTilUSIJi8WC7fIAJWxQ5wwrr8q78MsABDvw9CptV at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Dion, no worries about basic, I am still a learner :)
Here is the output:
array(2) { [0]=> string(7) "canread" ["singleseat"]=> string(1) "1" }
array(1) { [0]=> string(10) "singleseat" }
Thanks for looking at this.
Ash
On 21 June 2010 20:00, <wp-hackers-request at lists.automattic.com> wrote:
> What about this? I realise it may seem basic, i'm just trying to figure
> out where the cause could be in this case.
>
> global $current_user;
> var_dump($current_user->allcaps, $current_user->roles);
------------------------------
Message: 3
Date: Mon, 21 Jun 2010 15:14:31 +0200
From: Frank Bueltge <frank at bueltge.de>
Subject: Re: [wp-hackers] Math Comment Spam Protection plugin 2.2
doesn't work with WP 3.0
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTinwY0u09m0lxZpBeMB6X_UcM-fPh--uAbWjyRr0 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
ok, i send the attached zip directly to you.
On Mon, Jun 21, 2010 at 2:08 PM, Michel Bozgounov <info at optimiced.com>wrote:
>
> --------------------------------------
> From: Frank Bueltge <frank at bueltge.de>
>
> Subject: Re: [wp-hackers] Math Comment Spam Protection plugin 2.2
> doesn't work with WP 3.0
>
> only a fast view from me; i think its a problem with the $user_ID in the
> plugin, this var is in WP3.0 0, not isset.
> i attached a version with small changes, please test it.
>
>
> Hi, Frank,
>
> Thanks for the hint!
>
> Unfortunately, I do not see an attachment here -- are attachments to
> messages automatically removed from the list (or I don't see it)? Can you
> post the php file/code somewhere, with a link? Many thanks!! :)
>
> Cheers,
> --M.
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
------------------------------
Message: 4
Date: Mon, 21 Jun 2010 09:21:09 -0400
From: Jeremy Clarke <jer at simianuprising.com>
Subject: Re: [wp-hackers] support for custoim post types + custom
feilds
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTilo5s9Y6gGbAS9et0OpaoqUpXk1jXYPugUYgC_0 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Jun 19, 2010 at 12:04 PM, scribu <scribu at gmail.com> wrote:
> On Sat, Jun 19, 2010 at 6:39 AM, Ash Goodman <ash at thinkinginvain.com>
> wrote:
>
> > For corporate/mission critical websites plugins are an iffy solution at
> > best.
> >
>
> So, I'm guessing corporate sites don't use WP Super Cache (or any other
> caching plugin) because it's a plugin, right?
>
>
Scribu I'm bummed to hear you asking a leading question like that. I think
its clear that most sites will have some kind of sliding scale of importance
v. risk that they use to decide which plugins are worth it. Core WP needs to
assess each need and decide whether its fit for inclusion in core. Implying
that everything should be a plugin because some things have to be plugins is
not a good way to deal with feature requests.
Also: Super Cache, as has been constantly debated and pointed out, is a
particularly poignant example of functionality that by all rights
*should*be included in core but which isn't because it's too complex
and
server-dependent to be appropriate. Lots of people want caching in WP but
when faced with the realities and complexities we all agree that it should
stay plugins to save everyone extra headaches.
Compared to caching this proposal for a non-UI API for registering custom
fields is a perfect example of some functionality that should be carefully
considered for inclusion in core because its so simple, obvious and
appropriate. Not only would many theme and custom-plugin developers use the
functions in their implementations but public-plugin developers could use
the new API in their GUI plugins, standardizing the process and making those
plugins more future-proof than ever.
Unlike caching there aren't many good reasons to avoid this idea. Do you
know of any?
IMHO pointing out that there are already plugins that accomplish something
is not a reason not to put it in core, it is a reason to consider it even
harder! If the test for inclusion in core is "Are there already popular
plugins that do this job, proving that there is user desire?" then a custom
fields API is something that has had enough proof of its value since WP 1.5.
--
Jeremy Clarke
Code and Design | globalvoicesonline.org
------------------------------
Message: 5
Date: Mon, 21 Jun 2010 21:25:17 +0800
From: Ash Goodman <ash at thinkinginvain.com>
Subject: [wp-hackers] new menu management 3.0
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTindC-jsvdUuQ7vhmSMQSB9EdFfeV0HjE9DiZ6Ob at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
I am playing around with 3.0 and the new menu system. I love it but I
have noticed it doesn't play well with the existing menu management
features.
Forgive me if this has been brought up before. On the page editor
screen if you select a parent page from the drop down this is not
respected by the new menus interface and vice versa. I understand why
(what with categories and custom post types etc), but shouldn't the
old ways of managing the menus be hidden if the new way is activated?
Maybe something that happens when a theme is activated that declares
support for the new menu system?
I can just imagine users banging their heads against the wall trying
to edit the menu from the page editor. Telling them, 'oh I know those
controls are still there, but they don't work, use the other instead'
isn't going to cut it. Its opening the door for unnecessary confusion.
Even better I think would be if some way could be found to handle menu
management *both* on the page editor screen and using the new
interface. It makes sense from a usability viewpoint that you would be
able to assign the page to a menu and a location within that menu when
creating the page without having to go to a separate interface to do
it. But it also makes sense to be able to edit menus en masse from one
location. I think if we can have the ideal solution we need both
options.
Just my 2 cents please don't flame!
Ash
------------------------------
Message: 6
Date: Mon, 21 Jun 2010 14:34:44 +0100
From: Japh <japhie at gmail.com>
Subject: Re: [wp-hackers] new menu management 3.0
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTimpwnFXv2DDv0uSiwjVmd4HkGHhwLMC5mtjpp_6 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Great point, Ash! I completely agree with all the points you raise, and
would like to add one of my own, though mine is really more of a feature
request.
It would be great if you could set the top level pages for a menu, and then
tell it to automatically drill-down through child pages as well, rather than
having to manually create the entire multi-tiered menu structure and then
also maintain that. Also, it's slightly misleading that the default
behaviour for Twenty Ten if you add pages but no menu, is to fallback to
wp_page_menu and output a nice multi-tiered menu... but then when you create
a menu of top-level pages only, this automatic behaviour disappears. Like
Ash said, I understand why, I just think it's counter-intuitive.
At the moment, while I applaud the effort that has gone into menus for WP
3.0, I wouldn't consider them to be production-ready and there's a lot of
work left to be done.
Cheers,
Japh
On 21 June 2010 14:25, Ash Goodman <ash at thinkinginvain.com> wrote:
> Hi all,
>
> I am playing around with 3.0 and the new menu system. I love it but I
> have noticed it doesn't play well with the existing menu management
> features.
>
> Forgive me if this has been brought up before. On the page editor
> screen if you select a parent page from the drop down this is not
> respected by the new menus interface and vice versa. I understand why
> (what with categories and custom post types etc), but shouldn't the
> old ways of managing the menus be hidden if the new way is activated?
> Maybe something that happens when a theme is activated that declares
> support for the new menu system?
>
> I can just imagine users banging their heads against the wall trying
> to edit the menu from the page editor. Telling them, 'oh I know those
> controls are still there, but they don't work, use the other instead'
> isn't going to cut it. Its opening the door for unnecessary confusion.
>
> Even better I think would be if some way could be found to handle menu
> management *both* on the page editor screen and using the new
> interface. It makes sense from a usability viewpoint that you would be
> able to assign the page to a menu and a location within that menu when
> creating the page without having to go to a separate interface to do
> it. But it also makes sense to be able to edit menus en masse from one
> location. I think if we can have the ideal solution we need both
> options.
>
> Just my 2 cents please don't flame!
>
> Ash
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
------------------------------
Message: 7
Date: Mon, 21 Jun 2010 19:07:40 +0530
From: Piyush Mishra <me at piyushmishra.com>
Subject: Re: [wp-hackers] new menu management 3.0
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTilX_2upAGyNTEQH8ZhxfOfIJVmoBsusheJdhqmm at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
as far as i can make out, presently the menu is static and completely
separate from the general logic of the site. all other features work
as is. this helps in making custom menus and IMHO it would be cool to
have intelligent menu features like the ones u stated but we should
not treat it like a bug but as an enhancement...
On 6/21/10, Ash Goodman <ash at thinkinginvain.com> wrote:
> Hi all,
>
> I am playing around with 3.0 and the new menu system. I love it but I
> have noticed it doesn't play well with the existing menu management
> features.
>
> Forgive me if this has been brought up before. On the page editor
> screen if you select a parent page from the drop down this is not
> respected by the new menus interface and vice versa. I understand why
> (what with categories and custom post types etc), but shouldn't the
> old ways of managing the menus be hidden if the new way is activated?
> Maybe something that happens when a theme is activated that declares
> support for the new menu system?
>
> I can just imagine users banging their heads against the wall trying
> to edit the menu from the page editor. Telling them, 'oh I know those
> controls are still there, but they don't work, use the other instead'
> isn't going to cut it. Its opening the door for unnecessary confusion.
>
> Even better I think would be if some way could be found to handle menu
> management *both* on the page editor screen and using the new
> interface. It makes sense from a usability viewpoint that you would be
> able to assign the page to a menu and a location within that menu when
> creating the page without having to go to a separate interface to do
> it. But it also makes sense to be able to edit menus en masse from one
> location. I think if we can have the ideal solution we need both
> options.
>
> Just my 2 cents please don't flame!
>
> Ash
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
--
Regards
Piyush Mishra
------------------------------
Message: 8
Date: Mon, 21 Jun 2010 15:02:52 +0100
From: ErisDS <erisds at gmail.com>
Subject: Re: [wp-hackers] new menu management 3.0
To: wp-hackers at lists.automattic.com
Message-ID:
<AANLkTilYNuiU5DfmaHXGAHWZ6w76iW3aqfjr4PJWD95y at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I don't think anyone is trying to say that these are bugs. The menu system,
as is, works perfectly.
However, parts of it are a bit unintuitive, especially when considering
training a client.
I agree with Japh that if I setup a top-level menu it would be nice to *have
the option* to tell the menu to auto-populate the children (and keep them
updated when a new child is created).
The user could still go to the menu page and use the nice drag and drop
interface to remove or add items... but the basic structure would be
populated automatically.
Again, I don't think these are bugs, but I do agree that whilst the efforts
of the WP team on the menu system are awesome, and that it is perfect for
smaller custom menus, when it comes to the main navigation on a large
page-heavy site, it currently doesn't cut the mustard in terms of features
and intuitiveness.
At the end of the day, we sell Wordpress to our clients because it's
easy-to-use, because they don't have to do things manually, so I'm going to
continue using wp_list_pages, and the PageMash and Page Links Manager
plugins to manage main navigation.
Just my 2p
Eris
On Mon, Jun 21, 2010 at 2:37 PM, Piyush Mishra <me at piyushmishra.com> wrote:
> as far as i can make out, presently the menu is static and completely
> separate from the general logic of the site. all other features work
> as is. this helps in making custom menus and IMHO it would be cool to
> have intelligent menu features like the ones u stated but we should
> not treat it like a bug but as an enhancement...
>
> On 6/21/10, Ash Goodman <ash at thinkinginvain.com> wrote:
> > Hi all,
> >
> > I am playing around with 3.0 and the new menu system. I love it but I
> > have noticed it doesn't play well with the existing menu management
> > features.
> >
> > Forgive me if this has been brought up before. On the page editor
> > screen if you select a parent page from the drop down this is not
> > respected by the new menus interface and vice versa. I understand why
> > (what with categories and custom post types etc), but shouldn't the
> > old ways of managing the menus be hidden if the new way is activated?
> > Maybe something that happens when a theme is activated that declares
> > support for the new menu system?
> >
> > I can just imagine users banging their heads against the wall trying
> > to edit the menu from the page editor. Telling them, 'oh I know those
> > controls are still there, but they don't work, use the other instead'
> > isn't going to cut it. Its opening the door for unnecessary confusion.
> >
> > Even better I think would be if some way could be found to handle menu
> > management *both* on the page editor screen and using the new
> > interface. It makes sense from a usability viewpoint that you would be
> > able to assign the page to a menu and a location within that menu when
> > creating the page without having to go to a separate interface to do
> > it. But it also makes sense to be able to edit menus en masse from one
> > location. I think if we can have the ideal solution we need both
> > options.
> >
> > Just my 2 cents please don't flame!
> >
> > Ash
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> >
>
>
> --
> Regards
>
> Piyush Mishra
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>
------------------------------
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers
End of wp-hackers Digest, Vol 65, Issue 48
******************************************
More information about the wp-hackers
mailing list