[theme-reviewers] Questions regarding theme review process

Fri Jan 21 10:23:33 UTC 2011

>
> #3 - i found text widgets to be more of a proper use for these, but hey, if
> it's in the design i'm not going to argue

For sidebar-ads - widget will be a good choice.
For banner, adding a simple textarea will be more optimized rather than
converting header into widgetized area.

all of which again, recommendations are not 'do it or else it won't get
> accepted' they're only something that we need to put in there to have you
> think about possibly switching to that method in the future
>
Glad to know that. :-)
You guys always suggest something very useful. Last time also, suggestion
made by you & Chip for post-thumbnails helped us a lot.
There is really no point in reinventing the wheel. Its just sometime we
don't know what options we have until someone else bring them to our
attention.

child themes at this time are still not approved to be placed on the
> repository

Sad to know that. I hope fate of child themes will be decided soon. :-)

==

It will be heaven if theme developers get SVN access like plugin developers
have.

There are many times when small edits to a theme needs, mostly enhancement.
Somehow I feel bad asking WPTRT to spend time on my minor releases and so I
am waiting for WordPress 3.1 when I will upload our theme's
newer version with post-formats feature and enhancements we recently made.

--
Rahul Bansal | Founder & CEO | rtCamp Solutions Pvt. Ltd.
Mobile: +91-9860501882 | Web: http://rtcamp.com/

On Fri, Jan 21, 2011 at 3:31 PM, Philip M. Hofer (Frumph) <philip at frumph.net
> wrote:

>  #1 - it's fine, inside the theme is okay
>
> #2 - if it's a theme-design thing,  no problem
>
> #3 - i found text widgets to be more of a proper use for these, but hey, if
> it's in the design i'm not going to argue
>
>
> all of which again, recommendations are not 'do it or else it won't get
> accepted' they're only something that we need to put in there to have you
> think about possibly switching to that method in the future
>
> --- As for child theme deployment
>
> The guidelines are not set and the WPTRT discussion is continueing right
> now, we'll open it up on the make.wordpress.org/themes site soon as we get
> a proper grasp of what it entails,  however i posted a preliminary list on
> this mailing list last night, it's only just some thoughts to mull over and
> give your opinion on since at this moment nothing is set in stone, child
> themes at this time are still not approved to be placed on the repository
>
>
> ----- Original Message -----
> *From:* Rahul Bansal <rahul286 at gmail.com>
> *To:* theme-reviewers at lists.wordpress.org
> *Sent:* Friday, January 21, 2011 1:56 AM
> *Subject:* Re: [theme-reviewers] Questions regarding theme review process
>
> Hi Philip,
>
> Thanks for details.
>
> I even believe myself not everything that can be done via plugin should be
> done inside theme.
> When wordpress-seo by yoast came, we removed our SEO options and now
> display "list of recommended plugins" in theme options pages.
> We support many plugins like subscribe-to-comments, YARPP's related post,
> etc.
>
> Main concern is - some tiny plugins. I will explain this bit with more
> examples.
>
> *#1 - Align RSS plugins (
> http://wordpress.org/extend/plugins/align-rss-images/)*
> Wordpress adds classes like .alignleft and .alignright for which we add
> some codes in style.css
> Now when these wordpress-generated classes goes into RSS feed content,
> image alignment do not work as style.css cannot be loaded by feed-readers.
> Just 2-3 lines in theme can replace 'class=alignright' with
> "style=float:left" in feed-output.
>
> *There are few more plugins which "fixes" something. Personally, I believe
> these fixes should be added inside wordpress-core!*
> *
> *
> *#2 - Sharing icons*
> Since facebook/twitter shares icons gets displayed on front-end, having
> theme control their dimension and other aspects can improve
> theme aesthetically.
> Most plugin which latch on fliters ruin themes output. Then a user is
> forced to add function call himself in theme codes to get desired placement
> of these buttons.
>
> *#3 - Advertising *
> An average blog sells ad via 3rd party. He only want a place to put some
> HTML/JS codes given to him.
> If theme provides textareas for common ad-slots, that will save him from
> using bloated plugins which counts impressions and do plenty of other
> things.
> Such stats are already provided by ad-networks so why to waste CPU power &
> database space of server.
>
> I observed that, plugins which adds HTML/CSS/JS on front-end generally
> miss preciseness. In that case, user starts altering code and a single
> biggest mistake they make is adding function provided by plugin
> without surrounding it via if(function_exists('example')) block.
>
> Using WordPress API is of highest priority here. In fact, rather than
> relying in codex documentation, we trace wordpress core cods to find
> functions which we can reuse always!
>
>  On sidenote, as a theme-developer, while adding such functionality, I
> will keep it disabled by default and will provide an option for user to
> enable it if they like to.
>
> Only thing I expect from WPTRT is freedom for theme-developers to decide
> on functionality they want to add inside theme.
>
> ==
>
> Please someone clear my doubts regarding parent-child theme deployment.
>
> --
> Rahul Bansal | Founder & CEO | rtCamp Solutions Pvt. Ltd.
> Mobile: +91-9860501882 | Web: http://rtcamp.com/
>
>
>
> On Fri, Jan 21, 2011 at 2:55 PM, Philip M. Hofer (Frumph) <
> philip at frumph.net> wrote:
>
>>  While timthumb has been banned, that doesnt mean other internal
>> functionality will ever be banned as such.     You might come across
>> recommendations that said functionality should be a plugin, but it is only
>> that a recommendation.
>>
>> To answer your list.
>>
>> 1. Fine - recommend plugin
>> 2. Fine - recommend plugin
>> 3. Fine
>> 4. Definately Ok.
>> 5. Absolutely Ok.
>> 6. Fine - recommend plugin
>>
>> While the push for developers to strive to utilize as much api and plugins
>> that do the load of the work that you are describing, there's nothing that
>> you wrote there that would be not-accepted;  however, that being said it is
>> in the developers interest to utilize as much of the plugin to theme control
>> as possible and more importantly the WordPress API itself.
>>
>> Frameworks at this time are finalizing the guidelines for it.  Chip is
>> probably the best person to respond about that. - as for integration as you
>> speak of, that one client doesn't justify the large number of possible users
>> to the theme that might want a different functionality from a plugin
>> instead.   It is in my opinion better to cater to the wider audience then
>> the single one, giving the audience which uses the themes/derivatives/child
>> themes a wider variety of possibilities goes quite a long way.
>>
>> On a side note, I used to believe integrating everything was the right
>> choice as well.. .until something occured with an update of WordPress which
>> made one single function not behave as it should which ruined the theme for
>> everyone who upgraded.
>>
>> ^ My 2cents, nothing more.
>>
>>
>>
>>
>> My concern is, for our next theme, which is actually our internal
>> base-theme (sort of framework) and contains features like:
>>
>>    1. Social bookmarking/Sharing controls (twitter/facebook/etc buttons)
>>    2. Advertising options (like Google AdSense/BuySellAds/Kontera etc)
>>    3. Typography options (font-faces/font-sizes/etc)
>>    4. Layout Options (2-column/3-column/etc)
>>    5. Content Options (Thumbnail size/summaries/read-more settings)
>>    6. Other options like feedburner integration, favicon/logo upload
>>
>> There were SEO options also which we plan to retire in favor of
>> wordpress-seo plugin by yoast.
>>
>> To give you better ideas, just think of themes at themeforest which
>> provides theme-options.
>> We have many clients on themeforest for which above said internal
>> framework has been maintained and continuously updated from a year.
>>
>> Now question is - if we decide to release our framework in open-source,
>> which features we need to remove (if any) to maintain compliances here?
>>
>> Also, can we upload themes we have developed for themeforest here?
>> Will there be any extra regulations regarding features & options themes at
>> themeforest provides?
>> Just a note - themeforest publishers are very aggressive. On one instant a
>> client sent us list of 30+ plugins which he wanted to integrate in a
>> wordpress-theme!
>>
>> We have many themes in our repo, originally developed for themeforest but
>> never launched for various reasons (most common is client defaulting
>> payment).
>> We are owners of all graphics/code which we want to release on wordpress
>> theme repo, of course under GPL :-)
>>
>> ==
>>
>> My second question is regarding parent-child theme.
>>
>> Here is what we want to achieve.
>>
>>    1. Our base theme (framework) is common across all our themes [Parent]
>>
>>    2. Each theme has its own set of local changes [Child]
>>
>> We want to leverage power of parent-child theme to push updates. If there
>> is any change in base-framework - all child theme users should get a
>> notification about new update of parent theme.
>>
>> Not sure if possible here, specially as SVN access is not available on
>> theme-repo (like we have access to SVN on plugin-repo).
>>
>> Regarding release - should we release parent and child theme separately?
>> Is there any extra guideline on parent-child theme release.
>>
>> Also while answering please consider 3-level relationship =>
>> parent-child-grandchild as well!
>>
>> ==
>>
>> The only purpose of asking all questions in advance here is to save
>> our development efforts and also precious time of theme review team.
>>
>> I hope to get some good suggestions/guidance/inputs here.
>>
>> Thanks All,
>> -Rahul
>>
>>
>> --
>> Rahul Bansal | Founder & CEO | rtCamp Solutions Pvt. Ltd.
>> Mobile: +91-9860501882 | Web: http://rtcamp.com/
>>
>>  ------------------------------
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>>
>  ------------------------------
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110121/ab655166/attachment-0001.htm>