Re: cleanup weblog entries plugins

[Anil Gangolli <an...@busybuddha.org>]

Sorry for entering this conversation a bit late.

How about shipping these plugins but not enabling them by default.  For 
example, I'd rather they ship as part of the normal install but we just 
comment them out in roller.properties.

I don't mind reorganizing them into a different package and even a different 
jar but I'd really like to ship them along with Roller.

--a.


----- Original Message ----- 
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Thursday, August 31, 2006 9:07 AM
Subject: Re: cleanup weblog entries plugins


>
>
> Dave Levy wrote:
>> I can see why you create your lists as you do, but I agree with both the 
>> amendments. I use the topic plugin all the time and occasionally the 
>> smiley plugin. (I will document it some time and would use it more if I 
>> knew how to invoke some of the odder smileys (particularly the smug 
>> one.))
>
> Actually, the smiley plugin would be one of the harder ones to remove 
> since it also has images in it, so maybe we should just leave that one as 
> well.
>
>
>>
>> I personally think the ConvertLineBreaksPlugin produces terrible HTML and 
>> is hard to incorporate into a theme and inhibits the formating of code 
>> and tables (which I also oppose in blog articles), so would suggest that 
>> it is an extra not core.
>
> I think that's just a case where you do things that don't work well with 
> the plugin and so it makes sense that you don't apply it.  I still think 
> it's valuable to most people and in the years of blogging that I've done 
> I'd say that 99% of the time I just write paragraphs and include <A> and 
> <IMG> tags and that's it, so this plugin is very useful in simply taking 
> plain text paragraphs and converting them to html.  I have never once put 
> a <table> in an entry and i don't think most people do.
>
>
>>
>> The customers, i.e. people who make the plugins available for use are the 
>> site managers, but removing it would mean that people will have to learn 
>> HTML. You can survive with <P>, <A> and <IMG> though how hard is that?
>
> The point of removing them from the Roller core is because they are things 
> that possibly *shouldn't* be enabled by default, they are plugins and 
> hence are meant to be added on to extend functionality.  I think that we 
> would technically be justified in removing all of them and forcing all 
> admins to manually pick and enable all the plugins they want, but that 
> seems unreasonable.
>
> So this is what I am going with unless there are other opinions ...
>
> keep in core:
> ConvertLineBreaksPlugin
> ObfuscateEmailPlugin
> TopicTagPlugin
> SimleyPlugin
>
> make optional:
> WikipediaLinkPlugin
> GoogleLinkPlugin
> TextilePlugin
> AcronymsPlugin
> BookmarkPlugin
>
> I plan to do this later today.
>
> -- Allen
>
>
>>
>> Dave Johnson wrote:
>>> On 8/29/06, Allen Gilliland <al...@sun.com> wrote:
>>>> 2. Move all plugins which are shipped with Roller into the core src
>>>> directory so they are actually part of the main build.
>>>>
>>>> 3. Remove all plugins which are *not* going to be shipped with Roller
>>>> from being included in a standard build.  They can stay in the contrib
>>>> area and just be built separately, or possibly moved elsewhere like the
>>>> Roller support project.
>>>>
>>>> anyone object to any of these steps?
>>>
>>> +1 on this idea
>>>
>>>> keep in core:
>>>> ConvertLineBreaksPlugin
>>>> BookmarkPlugin
>>>> ObfuscateEmailPlugin
>>>
>>> I'd replace the BookmarkPlugin with TopicTagPlugin, based on popularity.
>>>
>>> - Dave
>>
> 

Re: cleanup weblog entries plugins

[Craig L Russell <Cr...@Sun.COM>]

Hi Allen,

On Sep 4, 2006, at 4:28 PM, Allen Gilliland wrote:
> Craig L Russell wrote:
>> Hi Allen,
>> On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
>>> for the current set of plugins I think that's fine, we can just  
>>> move all the current plugins in to the core src tree and then  
>>> modify the config to only enable a subset of them.  i'll go ahead  
>>> and take this approach since it really is the easiest in our  
>>> current situation.
>> It sounds like you've chosen the right approach.
>>>
>>> the main reason i proposed this though is that i believe very  
>>> strongly that moving forward it's not our job to maintain all the  
>>> plugins directly in the src tree.  we don't have many people who  
>>> do this right now, but eventually we want to build a user  
>>> community that really does create and share plugins and that has  
>>> to happen outside of the core project.  we already have 10  
>>> plugins, what happens if the list grows to 20, 50, etc?
>> I'd like to understand your concern better. Simply developing a  
>> plugin doesn't require core knowledge of Roller, just the  
>> interfaces exposed by the callbacks. If someone wants to develop a  
>> plugin, under the current regime, a committer would have to test  
>> and commit the plugin to the src tree. So do we *not* want "plugin  
>> developers" to eventually become part of the committer list for  
>> Roller?
>
> My concern may be a little premature, but the potential problem I  
> see is that if all the plugins are part of the core build then we  
> are 1) bloating the core application with code that may never be used

good point

> and 2) since plugins are not part of core functionality it is much  
> easier for people to neglect them over time and not maintain them

good point

> and thus 3) the core developers feel obligated to maintain the  
> plugin code which makes things harder on us.

I understand.
>
> I don't really care if we allow people to develop plugins directly  
> in the core project, but I don't see why we would want *all*  
> plugins to be built and packaged with the core build.  That defeats  
> the purpose of a plugin.

It seems that there might be a "core" set of plugins that make sense  
to develop in the core, but I understand the issues with the other  
plugins. Especially since over time, the plugin interface that we  
expose will likely change, and obsolete plugins will have to be fixed  
before we evolve the interface.
>
>
>>>
>>> as long as we make it easy for people to add in a plugin then i  
>>> think it's best that they be developed and maintained outside of  
>>> the core src.
>> If this is the case, perhaps it makes sense to create a new  
>> project just for plugins. But this might be construed as anti- 
>> community-building ("core developers" versus "plugin developers").
>> Personally, I think that building the community is a good thing,  
>> and a developer starting out developing plugins is a good thing.  
>> Once the number of quality contributions of plugins and patches by  
>> a contributor is significant, the contributor should be considered  
>> for committer status even though they don't work in the core. Just  
>> my two cents.
>
> We have started a roller_support project at java.net specifically  
> for this

seems like a good idea especially if it is well advertised.

Craig


> so that users who are only interested in themes, plugins, and  
> custom editors can easily work on those things and download them  
> separately.
>
> I agree that we want to build community, but in my opinion pushing  
> these addons out of the core application does just that.  It places  
> the responsibility in the hands of the community instead of leaving  
> it like it is now, where us core developers are the only ones  
> really working on the them.
>
> -- Allen
>
>
>> Craig
>>>
>>> -- Allen
>>>
>>>
>>> Sean Gilligan wrote:
>>>> Anil Gangolli wrote:
>>>>>
>>>>> Sorry for entering this conversation a bit late.
>>>>>
>>>>> How about shipping these plugins but not enabling them by  
>>>>> default.  For example, I'd rather they ship as part of the  
>>>>> normal install but we just comment them out in roller.properties.
>>>> Or we could have an admin page to enable them like for editor  
>>>> pages.
>>>> -- Sean
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: cleanup weblog entries plugins

[Allen Gilliland <Al...@Sun.COM>]

Craig L Russell wrote:
> Hi Allen,
> 
> On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:
> 
>> for the current set of plugins I think that's fine, we can just move 
>> all the current plugins in to the core src tree and then modify the 
>> config to only enable a subset of them.  i'll go ahead and take this 
>> approach since it really is the easiest in our current situation.
> 
> It sounds like you've chosen the right approach.
>>
>> the main reason i proposed this though is that i believe very strongly 
>> that moving forward it's not our job to maintain all the plugins 
>> directly in the src tree.  we don't have many people who do this right 
>> now, but eventually we want to build a user community that really does 
>> create and share plugins and that has to happen outside of the core 
>> project.  we already have 10 plugins, what happens if the list grows 
>> to 20, 50, etc?
> 
> I'd like to understand your concern better. Simply developing a plugin 
> doesn't require core knowledge of Roller, just the interfaces exposed by 
> the callbacks. If someone wants to develop a plugin, under the current 
> regime, a committer would have to test and commit the plugin to the src 
> tree. So do we *not* want "plugin developers" to eventually become part 
> of the committer list for Roller?

My concern may be a little premature, but the potential problem I see is 
that if all the plugins are part of the core build then we are 1) 
bloating the core application with code that may never be used and 2) 
since plugins are not part of core functionality it is much easier for 
people to neglect them over time and not maintain them and thus 3) the 
core developers feel obligated to maintain the plugin code which makes 
things harder on us.

I don't really care if we allow people to develop plugins directly in 
the core project, but I don't see why we would want *all* plugins to be 
built and packaged with the core build.  That defeats the purpose of a 
plugin.


>>
>> as long as we make it easy for people to add in a plugin then i think 
>> it's best that they be developed and maintained outside of the core src.
> 
> If this is the case, perhaps it makes sense to create a new project just 
> for plugins. But this might be construed as anti-community-building 
> ("core developers" versus "plugin developers").
> 
> Personally, I think that building the community is a good thing, and a 
> developer starting out developing plugins is a good thing. Once the 
> number of quality contributions of plugins and patches by a contributor 
> is significant, the contributor should be considered for committer 
> status even though they don't work in the core. Just my two cents.

We have started a roller_support project at java.net specifically for 
this so that users who are only interested in themes, plugins, and 
custom editors can easily work on those things and download them separately.

I agree that we want to build community, but in my opinion pushing these 
addons out of the core application does just that.  It places the 
responsibility in the hands of the community instead of leaving it like 
it is now, where us core developers are the only ones really working on 
the them.

-- Allen


> 
> Craig
> 
>>
>> -- Allen
>>
>>
>> Sean Gilligan wrote:
>>> Anil Gangolli wrote:
>>>>
>>>> Sorry for entering this conversation a bit late.
>>>>
>>>> How about shipping these plugins but not enabling them by default.  
>>>> For example, I'd rather they ship as part of the normal install but 
>>>> we just comment them out in roller.properties.
>>> Or we could have an admin page to enable them like for editor pages.
>>> -- Sean
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
> 

Re: cleanup weblog entries plugins

[Craig L Russell <Cr...@Sun.COM>]

Hi Allen,

On Sep 1, 2006, at 9:14 AM, Allen Gilliland wrote:

> for the current set of plugins I think that's fine, we can just  
> move all the current plugins in to the core src tree and then  
> modify the config to only enable a subset of them.  i'll go ahead  
> and take this approach since it really is the easiest in our  
> current situation.

It sounds like you've chosen the right approach.
>
> the main reason i proposed this though is that i believe very  
> strongly that moving forward it's not our job to maintain all the  
> plugins directly in the src tree.  we don't have many people who do  
> this right now, but eventually we want to build a user community  
> that really does create and share plugins and that has to happen  
> outside of the core project.  we already have 10 plugins, what  
> happens if the list grows to 20, 50, etc?

I'd like to understand your concern better. Simply developing a  
plugin doesn't require core knowledge of Roller, just the interfaces  
exposed by the callbacks. If someone wants to develop a plugin, under  
the current regime, a committer would have to test and commit the  
plugin to the src tree. So do we *not* want "plugin developers" to  
eventually become part of the committer list for Roller?
>
> as long as we make it easy for people to add in a plugin then i  
> think it's best that they be developed and maintained outside of  
> the core src.

If this is the case, perhaps it makes sense to create a new project  
just for plugins. But this might be construed as anti-community- 
building ("core developers" versus "plugin developers").

Personally, I think that building the community is a good thing, and  
a developer starting out developing plugins is a good thing. Once the  
number of quality contributions of plugins and patches by a  
contributor is significant, the contributor should be considered for  
committer status even though they don't work in the core. Just my two  
cents.

Craig

>
> -- Allen
>
>
> Sean Gilligan wrote:
>> Anil Gangolli wrote:
>>>
>>> Sorry for entering this conversation a bit late.
>>>
>>> How about shipping these plugins but not enabling them by  
>>> default.  For example, I'd rather they ship as part of the normal  
>>> install but we just comment them out in roller.properties.
>> Or we could have an admin page to enable them like for editor pages.
>> -- Sean

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: cleanup weblog entries plugins

[Allen Gilliland <al...@sun.com>]

Thats a good point.  Given that in the current model it's expected that 
the plugin is initialized each time its used we may not be able to 
follow the init once strategy.  It would be nice if we can work towards 
that though.

In any case, the bigger issue is if we can remove access to the 
rendering model in plugins.  I still think that's important and 
something we should do for 3.0.

-- Allen


Anil Gangolli wrote:
> 
> I remember running into essentially this problem before.
> 
> Plugins like bookmark plugin could be initialized per website, but do 
> need access to site-specific (bookmark) data.  The topictag plugin can 
> refer to bookmarks as well, but I think most people run with this 
> disabled because it is not efficient.
> 
> The instantiation and initialization model are coupled, since one 
> expects that the plugin may store instance data/references at 
> initialization time, and use it when called subsequently to process the 
> entry.  If the call to process the entry could pass in enough contextual 
> information to relieve the plugin from keeping this state, it would 
> allow sharing instances of the plugins and initialize them only once.  
> In other words, init should pass in server-wide configuration 
> information, and the call to process the entry should pass in all 
> contextual references necessary.
> 
> --a.
> 
> 
> ----- Original Message ----- From: "Allen Gilliland" 
> <al...@sun.com>
> To: <ro...@incubator.apache.org>
> Sent: Friday, September 01, 2006 11:14 AM
> Subject: Re: cleanup weblog entries plugins
> 
> 
>> okay, this has been committed to the 3.0 branch.
>>
>> there is one more important little change that i would like to propose 
>> with regards to the entry plugins.  the entry plugin architecture was 
>> cleaned up quite a bit for 3.0, but one thing was left which i would 
>> like to address.  the current entry plugin interface has this method ...
>>
>> public void init(WebsiteData weblog, Map model) throws RollerException;
>>
>> ... which initializes the plugin for the given weblog.  i would like 
>> to change this method signature to not pass in the model Map to 
>> plugins for a few reasons ...
>>
>> 1. security.  giving a plugin access to the model is potentially 
>> dangerous because a plugin could then remove/modify existing items in 
>> the model or add potentially harmful or inappropriate items to the 
>> model.  we have specifically designed the rendering model architecture 
>> to accomplish this task.  Model objects are what should be added to 
>> the rendering model, not random items via entry plugins.
>>
>> 2. simplicity.  i don't think plugins need the model to do their job. 
>> they are currently only meant to take the entry content and transform 
>> it in some way and that shouldn't require access to the model.
>>
>> 3. performance.  technically if a plugin doesn't need to be 
>> initialized each time with model data relevant to a given request then 
>> it would be possible to initialize the plugins only once and then 
>> reuse them.
>>
>> also note, right now the only plugin that even makes use of the model 
>> that is passed in at init time is the Textile plugin, which i have not 
>> included in the core src tree as a supported plugin mainly because it 
>> requires an additional library and i think those kinds of plugins 
>> really should be added on externally.
>>
>> what do others think?
>>
>> -- Allen
>>
>>
>> Allen Gilliland wrote:
>>> for the current set of plugins I think that's fine, we can just move 
>>> all the current plugins in to the core src tree and then modify the 
>>> config to only enable a subset of them.  i'll go ahead and take this 
>>> approach since it really is the easiest in our current situation.
>>>
>>> the main reason i proposed this though is that i believe very 
>>> strongly that moving forward it's not our job to maintain all the 
>>> plugins directly in the src tree.  we don't have many people who do 
>>> this right now, but eventually we want to build a user community that 
>>> really does create and share plugins and that has to happen outside 
>>> of the core project.  we already have 10 plugins, what happens if the 
>>> list grows to 20, 50, etc?
>>>
>>> as long as we make it easy for people to add in a plugin then i think 
>>> it's best that they be developed and maintained outside of the core src.
>>>
>>> -- Allen
>>>
>>>
>>> Sean Gilligan wrote:
>>>> Anil Gangolli wrote:
>>>>>
>>>>> Sorry for entering this conversation a bit late.
>>>>>
>>>>> How about shipping these plugins but not enabling them by default.  
>>>>> For example, I'd rather they ship as part of the normal install but 
>>>>> we just comment them out in roller.properties.
>>>>
>>>> Or we could have an admin page to enable them like for editor pages.
>>>>
>>>> -- Sean
>>
> 

Re: cleanup weblog entries plugins

[Anil Gangolli <an...@busybuddha.org>]

I remember running into essentially this problem before.

Plugins like bookmark plugin could be initialized per website, but do need 
access to site-specific (bookmark) data.  The topictag plugin can refer to 
bookmarks as well, but I think most people run with this disabled because it 
is not efficient.

The instantiation and initialization model are coupled, since one expects 
that the plugin may store instance data/references at initialization time, 
and use it when called subsequently to process the entry.  If the call to 
process the entry could pass in enough contextual information to relieve the 
plugin from keeping this state, it would allow sharing instances of the 
plugins and initialize them only once.  In other words, init should pass in 
server-wide configuration information, and the call to process the entry 
should pass in all contextual references necessary.

--a.


----- Original Message ----- 
From: "Allen Gilliland" <al...@sun.com>
To: <ro...@incubator.apache.org>
Sent: Friday, September 01, 2006 11:14 AM
Subject: Re: cleanup weblog entries plugins


> okay, this has been committed to the 3.0 branch.
>
> there is one more important little change that i would like to propose 
> with regards to the entry plugins.  the entry plugin architecture was 
> cleaned up quite a bit for 3.0, but one thing was left which i would like 
> to address.  the current entry plugin interface has this method ...
>
> public void init(WebsiteData weblog, Map model) throws RollerException;
>
> ... which initializes the plugin for the given weblog.  i would like to 
> change this method signature to not pass in the model Map to plugins for a 
> few reasons ...
>
> 1. security.  giving a plugin access to the model is potentially dangerous 
> because a plugin could then remove/modify existing items in the model or 
> add potentially harmful or inappropriate items to the model.  we have 
> specifically designed the rendering model architecture to accomplish this 
> task.  Model objects are what should be added to the rendering model, not 
> random items via entry plugins.
>
> 2. simplicity.  i don't think plugins need the model to do their job. they 
> are currently only meant to take the entry content and transform it in 
> some way and that shouldn't require access to the model.
>
> 3. performance.  technically if a plugin doesn't need to be initialized 
> each time with model data relevant to a given request then it would be 
> possible to initialize the plugins only once and then reuse them.
>
> also note, right now the only plugin that even makes use of the model that 
> is passed in at init time is the Textile plugin, which i have not included 
> in the core src tree as a supported plugin mainly because it requires an 
> additional library and i think those kinds of plugins really should be 
> added on externally.
>
> what do others think?
>
> -- Allen
>
>
> Allen Gilliland wrote:
>> for the current set of plugins I think that's fine, we can just move all 
>> the current plugins in to the core src tree and then modify the config to 
>> only enable a subset of them.  i'll go ahead and take this approach since 
>> it really is the easiest in our current situation.
>>
>> the main reason i proposed this though is that i believe very strongly 
>> that moving forward it's not our job to maintain all the plugins directly 
>> in the src tree.  we don't have many people who do this right now, but 
>> eventually we want to build a user community that really does create and 
>> share plugins and that has to happen outside of the core project.  we 
>> already have 10 plugins, what happens if the list grows to 20, 50, etc?
>>
>> as long as we make it easy for people to add in a plugin then i think 
>> it's best that they be developed and maintained outside of the core src.
>>
>> -- Allen
>>
>>
>> Sean Gilligan wrote:
>>> Anil Gangolli wrote:
>>>>
>>>> Sorry for entering this conversation a bit late.
>>>>
>>>> How about shipping these plugins but not enabling them by default.  For 
>>>> example, I'd rather they ship as part of the normal install but we just 
>>>> comment them out in roller.properties.
>>>
>>> Or we could have an admin page to enable them like for editor pages.
>>>
>>> -- Sean
> 

Re: cleanup weblog entries plugins

[Allen Gilliland <al...@sun.com>]

okay, this has been committed to the 3.0 branch.

there is one more important little change that i would like to propose 
with regards to the entry plugins.  the entry plugin architecture was 
cleaned up quite a bit for 3.0, but one thing was left which i would 
like to address.  the current entry plugin interface has this method ...

public void init(WebsiteData weblog, Map model) throws RollerException;

... which initializes the plugin for the given weblog.  i would like to 
change this method signature to not pass in the model Map to plugins for 
a few reasons ...

1. security.  giving a plugin access to the model is potentially 
dangerous because a plugin could then remove/modify existing items in 
the model or add potentially harmful or inappropriate items to the 
model.  we have specifically designed the rendering model architecture 
to accomplish this task.  Model objects are what should be added to the 
rendering model, not random items via entry plugins.

2. simplicity.  i don't think plugins need the model to do their job. 
they are currently only meant to take the entry content and transform it 
in some way and that shouldn't require access to the model.

3. performance.  technically if a plugin doesn't need to be initialized 
each time with model data relevant to a given request then it would be 
possible to initialize the plugins only once and then reuse them.

also note, right now the only plugin that even makes use of the model 
that is passed in at init time is the Textile plugin, which i have not 
included in the core src tree as a supported plugin mainly because it 
requires an additional library and i think those kinds of plugins really 
should be added on externally.

what do others think?

-- Allen


Allen Gilliland wrote:
> for the current set of plugins I think that's fine, we can just move all 
> the current plugins in to the core src tree and then modify the config 
> to only enable a subset of them.  i'll go ahead and take this approach 
> since it really is the easiest in our current situation.
> 
> the main reason i proposed this though is that i believe very strongly 
> that moving forward it's not our job to maintain all the plugins 
> directly in the src tree.  we don't have many people who do this right 
> now, but eventually we want to build a user community that really does 
> create and share plugins and that has to happen outside of the core 
> project.  we already have 10 plugins, what happens if the list grows to 
> 20, 50, etc?
> 
> as long as we make it easy for people to add in a plugin then i think 
> it's best that they be developed and maintained outside of the core src.
> 
> -- Allen
> 
> 
> Sean Gilligan wrote:
>> Anil Gangolli wrote:
>>>
>>> Sorry for entering this conversation a bit late.
>>>
>>> How about shipping these plugins but not enabling them by default.  
>>> For example, I'd rather they ship as part of the normal install but 
>>> we just comment them out in roller.properties.
>>
>> Or we could have an admin page to enable them like for editor pages.
>>
>> -- Sean

Re: cleanup weblog entries plugins

[Allen Gilliland <al...@sun.com>]

for the current set of plugins I think that's fine, we can just move all 
the current plugins in to the core src tree and then modify the config 
to only enable a subset of them.  i'll go ahead and take this approach 
since it really is the easiest in our current situation.

the main reason i proposed this though is that i believe very strongly 
that moving forward it's not our job to maintain all the plugins 
directly in the src tree.  we don't have many people who do this right 
now, but eventually we want to build a user community that really does 
create and share plugins and that has to happen outside of the core 
project.  we already have 10 plugins, what happens if the list grows to 
20, 50, etc?

as long as we make it easy for people to add in a plugin then i think 
it's best that they be developed and maintained outside of the core src.

-- Allen


Sean Gilligan wrote:
> Anil Gangolli wrote:
>>
>> Sorry for entering this conversation a bit late.
>>
>> How about shipping these plugins but not enabling them by default.  
>> For example, I'd rather they ship as part of the normal install but we 
>> just comment them out in roller.properties.
> 
> Or we could have an admin page to enable them like for editor pages.
> 
> -- Sean

Re: cleanup weblog entries plugins

[Sean Gilligan <se...@msgilligan.com>]

Anil Gangolli wrote:
> 
> Sorry for entering this conversation a bit late.
> 
> How about shipping these plugins but not enabling them by default.  For 
> example, I'd rather they ship as part of the normal install but we just 
> comment them out in roller.properties.

Or we could have an admin page to enable them like for editor pages.

-- Sean