WordPress.org

Make WordPress Themes

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#24907 closed theme (live)

THEME: Zerif Lite – 1.8.2.1

Reported by: codeinwp Owned by: chipbennett
Priority: theme update Keywords: theme-zerif-lite
Cc: support@…, greenshady, emiluzelac, jcastenada, karmatosed, grapplerulrich

Description

Zerif Lite - 1.8.0

Zerif LITE is a free one page Wordpress theme. It’s perfect for web agency business,corporate business,personal and parallax business portfolio, photography sites and freelancer.Is built on BootStrap with parallax support, is responsive, clean, modern, flat and minimal. Zerif Lite is ecommerce (WooCommerce) Compatible, WPML, RTL, Retina-Ready, SEO Friendly and with parallax, full screen image is one of the best business themes.

Theme URL - http://themeisle.com/themes/zerif-lite/
Author URL - http://themeisle.com

SVN - https://themes.svn.wordpress.org/zerif-lite/1.8.0
ZIP - https://wordpress.org/themes/download/zerif-lite.1.8.0.zip?nostats=1

Diff with previous version: https://themes.trac.wordpress.org/changeset?old_path=zerif-lite/1.7.6&new_path=zerif-lite/1.8.0

History:

Ticket Summary Status Resolution Owner
#20384 THEME: Zerif Lite - 1.0.5 closed live karmatosed
#21317 THEME: Zerif Lite - 1.3 closed live catchthemes
#21451 THEME: Zerif Lite - 1.3.1 closed live emiluzelac
#21597 THEME: Zerif Lite - 1.3.9 closed live jcastaneda
#22197 THEME: Zerif Lite - 1.4.0 closed live karmatosed
#22433 THEME: Zerif Lite - 1.4.1 closed live karmatosed
#22574 THEME: Zerif Lite - 1.4.3 closed live jcastaneda
#22756 THEME: Zerif Lite - 1.4.4 closed live nishasingh
#22951 THEME: Zerif Lite - 1.4.5 closed live Milmor
#23105 THEME: Zerif Lite - 1.4.6 closed live grapplerulrich
#23191 THEME: Zerif Lite - 1.4.7 closed live emiluzelac
#23364 THEME: Zerif Lite – 1.5.2 closed live jcastaneda
#23596 THEME: Zerif Lite – 1.5.4 closed live hardeepasrani
#23775 THEME: Zerif Lite – 1.6.0 closed live jcastaneda
#24098 THEME: Zerif Lite – 1.7.1 closed live poena
#24296 THEME: Zerif Lite – 1.7.2 closed live jcastaneda
#24323 THEME: Zerif Lite – 1.7.3 closed live jacenty3590
#24568 THEME: Zerif Lite – 1.7.6 closed live karmatosed
#24907 THEME: Zerif Lite – 1.8.2.1 closed live chipbennett

(this ticket)

#25711 THEME: Zerif Lite – 1.8.2.2 closed live jcastaneda
#26096 THEME: Zerif Lite – 1.8.2.3 closed live chipbennett
#26505 THEME: Zerif Lite2015 – 1.8.2.3 closed not-approved alex27
#26918 THEME: Zerif Lite Nicole – 2.0.1.1 closed not-approved jcastaneda
#26955 THEME: Zerif litez – 2.0.1.2 closed not-approved jcastaneda
#27715 THEME: Zerif Lite mine – 1.8.2.5 closed not-approved jcastaneda
#27836 THEME: Zerif Lite – 1.8.2.4 closed live karmatosed
#27977 THEME: Zerif Lite – 1.8.2.5 closed live jcastaneda
#28112 THEME: Zerif Lite – 1.8.2.6 closed live karmatosed
#28449 THEME: Zerif Lite – 1.8.2.7 closed live karmatosed
#28454 THEME: Zerif Lite – 1.8.2.8 closed live karmatosed
#28637 THEME: Zerif Lite – 1.8.2.9 closed live karmatosed
#28818 THEME: Zerif Lite – 1.8.3.0 closed live karmatosed
#29196 THEME: Zerif Lite – 1.8.3.1 closed live Otto42
#29720 THEME: Zerif Lite – 1.8.3.2 closed live greenshady
#29824 THEME: Zerif Lite – 1.8.3.3 closed live Otto42
#30045 THEME: Zerif Lite – 1.8.3.5 closed live joedolson
#31136 THEME: Zerif Lite – 1.8.3.6 closed live themetracbot
#31326 THEME: Zerif Lite – 1.8.3.7 closed live themetracbot
#31338 THEME: Zerif Lite – 1.8.3.8 closed live themetracbot
#31672 THEME: Zerif Lite – 1.8.4.0 closed live themetracbot
#32649 THEME: Zerif Lite – 1.8.4.1 closed live themetracbot
#33432 THEME: Zerif Lite – 1.8.4.3 closed live themetracbot
#33435 THEME: Zerif Lite – 1.8.4.4 closed live themetracbot
#34821 THEME: Zerif Lite – 1.8.4.5 closed live themetracbot
#35904 THEME: Zerif Lite – 1.8.4.6 closed live themetracbot
#35906 THEME: Zerif Lite – 1.8.4.7 closed closed-newer-version-uploaded grapplerulrich
#35981 THEME: Zerif Lite – 1.8.4.8 closed live themetracbot
#36004 THEME: Zerif Lite – 1.8.4.9 closed live themetracbot
#38196 THEME: Zerif Lite – 1.8.5.5 closed closed-newer-version-uploaded grapplerulrich
#38491 THEME: Zerif Lite – 1.8.5.8 closed live grapplerulrich
#40574 THEME: Zerif Lite – 1.8.5.9 closed live themetracbot
#40631 THEME: Zerif Lite – 1.8.5.10 closed live themetracbot
#40693 THEME: Zerif Lite – 1.8.5.11 closed live themetracbot
#40754 THEME: Zerif Lite – 1.8.5.12 closed live themetracbot
#40959 THEME: Zerif Lite – 1.8.5.13 closed live themetracbot
#40969 THEME: Zerif Lite – 1.8.5.14 closed live themetracbot
#40986 THEME: Zerif Lite – 1.8.5.15 closed live themetracbot
#41931 THEME: Zerif Lite – 1.8.5.16 closed live themetracbot
#42398 THEME: Zerif Lite – 1.8.5.17 closed live themetracbot
#42453 THEME: Zerif Lite – 1.8.5.18 closed live themetracbot
#42609 THEME: Zerif Lite – 1.8.5.19 closed live themetracbot
#42726 THEME: Zerif Lite – 1.8.5.20 closed live themetracbot
#42812 THEME: Zerif Lite – 1.8.5.21 closed live themetracbot
#42914 THEME: Zerif Lite – 1.8.5.22 closed live themetracbot
#42936 THEME: Zerif Lite – 1.8.5.23 closed live themetracbot
#43874 THEME: Zerif Lite – 1.8.5.24 closed live themetracbot
#44274 THEME: Zerif Lite – 1.8.5.25 closed live themetracbot
#45942 THEME: Zerif Lite – 1.8.5.26 closed live themetracbot
#45946 THEME: Zerif Lite – 1.8.5.27 closed live themetracbot
#45953 THEME: Zerif Lite – 1.8.5.28 closed live themetracbot
#46180 THEME: Zerif Lite – 1.8.5.29 closed live themetracbot
#47696 THEME: Zerif Lite – 1.8.5.30 closed live themetracbot
#47965 THEME: Zerif Lite – 1.8.5.31 closed live themetracbot
#48058 THEME: Zerif Lite – 1.8.5.32 closed live themetracbot
#49309 THEME: Zerif Lite – 1.8.5.33 closed live themetracbot


https://themes.svn.wordpress.org/zerif-lite/1.8.0/screenshot.png

Attachments (1)

zerif-lite.1.8.4.0.zip (2.6 MB) - added by johnsmithfirst 20 months ago.

Change History (39)

#1 @nikeo
3 years ago

  • Owner set to nikeo
  • Status changed from new to reviewing

#2 @nikeo
3 years ago

  • Status changed from reviewing to approved

Theme approved. Review based on :

  • diff report
  • visual check on required templates and features
  • javascript console check
  • php developer mode enabled

#3 @chipbennett
3 years ago

  • Status changed from approved to reopened

#4 @codeinwp
3 years ago

Hey Chip,

Let me know what you don't find ok, I was not sure about some things either .

#5 @chipbennett
3 years ago

  • Cc greenshady emiluzelac jcastenada karmatosed grappelulrich added
  • Owner changed from nikeo to chipbennett
  • Status changed from reopened to reviewing

Required

  • Remove template-blog.php and template-blog-large.php. The blog posts index, per the template hierarchy, must use the home template (home.php, index.php).
  • Use get_template_directory_uri() instead of get_stylesheet_directory_uri() for default logo image path in header.php. Otherwise, this will break in a child Theme
    • Apply throughout the Theme, where applicable. I noticed it in several locations
  • The contact form on the static front page is Plugin territory
  • Testimonials, About Us, About Us features, Our Team, and Our Focus Theme options and related custom Widgets are all user content creation, and as such are Plugin territory. (They are essentially CPTs, disguised as custom Widgets.)
  • Custom post meta data, except for presentational meta data, is content creation, and therefore Plugin territory, e.g. author details, team member position, social network profiles, etc.
  • Theme-added custom image sizes must be properly prefixed. However, I am inclined to let this one pass, since users have already created images using the current, un-prefixed names. Changing it now would require thumbnail regeneration
  • Scripts must be bundled with the Theme, and enqueued locally:
    wp_enqueue_script( 'recaptcha', 'https://www.google.com/recaptcha/api.js' );
    
  • Note in the readme that custom background only applies to the blog posts index
  • Provide license statement for all resources, including images (e.g. usplash images), and proper copyright attribution and license (e.g. Font Awesome)

Notes

  • Because these issues are not related to the diff/changes in this ticket, I'll take this one over, to help bring it to resolution
  • There are other content-creation elements of the Theme (social network links, which we allow; company contact information, big title call to action/buttons, etc.). Please hold for further direction, as we are discussing this in the Theme Review Team meetings. (Join us next Tuesday, if you have input/concerns.)

#6 @codeinwp
3 years ago

Hey Chip,

Thank you for the review, I am not sure if I can attend this weekly meeting since I am traveling, however most of the things that you are pointing are really sensitive for 2 reasons :

  • Probably 50% of the most popular themes use some custom content on homepage
  • A lot of things like contact issue or testimonial can't be solved without breaking 100k sites which uses the theme

Regarding this thing :

Testimonials, About Us, About Us features, Our Team, and Our Focus Theme options and related custom Widgets are all user content creation, and as such are Plugin territory. (They are essentially CPTs, disguised as custom Widgets.)

Maybe we both have a different understanding of CPT however in those cases since we don't want a single view, or tags/categories or achieve pages I don't see honestly any reason why we should use a CPT for any of the ones listed above, especially focus/about, doing it will just create a complex and huge admin, a ton of unwanted automatically generated pages etc .

At the end I agree that our approach was a bit different/radical however looks like is something that people really want ( zerif is one of the hottest theme at the moment, with mentions all over the web), I mean most of them want to build a beatiful site in 10 minutes, without any knowledge and with zerif lite they can easily do it, they don't want 10 CPT, 10 required plugins, contact form, captcha plugins for a simple site.

Also what is awesome is that they are also not locked-in with the theme, of course they lose a bit of text from frontpage, but this is all, most of the content added will stay there so for example requiring the user to install a plugin to create 4 our focus widgets will just waste their time in my point of view .

From another point of view, changing /applying the policy is the way you are describing and not offering alternatives ( custom demo pages, theme pages like wp.com - https://theme.wordpress.com/themes/fortune/ ), will just remove a big part of the most successfull themes from the repo ( since update is not possible without breaking) and wp.org can become a useless thing .

I am happy to discuss more on this topic and find solutions that works the best for users and for the sanity of the directory itself. WCEU is close and since a lot of people will be there, we can even share more on the topic f2f with who will come.

Thanks!

#7 @codeinwp
3 years ago

Also the themes are not allowed to create custom blog template pages ? For example we would like 2 have 2 different styles for the blog page, shouldn't we create a new page template for that ?

#8 @chipbennett
3 years ago

The points under required really are required. It is unfortunate that the issues were perpetuated through several iterations of Theme updates, but they were missed originally. Themes hosted in the directory cannot create user content, and that is especially important.

We can certainly work with you to make changes, such as converting the Plugin-territory code into a Plugin, and porting your existing users to it.

As for blog templates: you need to use the home template hierarchy, but you can certainly use Theme options, for example, to make the layout configurable.

#9 @codeinwp
3 years ago

Hey Chip,

Thanks for clarification, my comments are not really about required or not, is about the best solution, are you sure that a plugin which create 5 CPTs is the best option here, or I am getting it wrong and you are thinking about porting the code as it is ?

Also you are realize the amount of work required to do this for 100+ themes installed on million of sites right ? Here are some other examples that are doing it at another level :

https://wordpress.org/themes/accesspress-parallax/
https://wordpress.org/themes/onetone/

and even https://wordpress.org/themes/colorway/ (4 years old) a theme with 700k installs which also impress me with their theme options page and those are just few.

My goal here is not pointing people out, I am looking in working together and finding the best solution, because even if we do the changes and port the options on Zerif,it won't make any difference if everybody else keep doing it or if we break sites and the repo.

Last edited 3 years ago by codeinwp (previous) (diff)

#10 @chipbennett
3 years ago

Sorry for any confusion. I'm not telling you to convert everything to a CPT, just that the functionality, as it exists, needs to be in a Plugin. It would be perfectly fine to convert it as-is.

It has recently come to our attention that possibly several Themes have been approved that may have similar issues. We'll address them as we find them, and work with the developers to come up with a plan to bring the Themes back into conformance with the requirements - just as we'll do here with your Theme.

This is just an opening dialogue, to come up with a plan. I do realize that it may mean considerable work.

#11 follow-up: @codeinwp
3 years ago

Cool sounds good, however I still have questions/ things that I consider important in the process :

  1. Why are you saying to convert it to a plugin ( beside the rules) can you give a certain usecase where this is more useful for the USER ? I am thinking for example if the user switch the theme, he keeps that 2 lines of text however he is required to edit both the theme and and tons of css style to make it work, it saves 10sec of copying the text and it adds 1 day of work to make it work with the new theme, also those 10s gained are lost at the beginning when they need to install the plugin, so where is the user gain here ? Rules are important, however when keeping them just for the sake of it and instead of protect the user we break their experience, I won't do it as a principle, I am doing all of this for creating something and improving users life not ruining it, otherwise my time invested in those products was wasted time. Again, maybe I am wrong, that's why I am asking for 1-2 use cases :)
  1. Doing this will allow us to keep the demo as it is( through mockup text) and once user activate the plugin to change the theme exactly as it is now ? So to require just 1 extra step for the user to have exactly same experience as now.
  1. Can we safely migrate all existing users without requiring any input from their side ? Just install the plugin and theme automatically without breaking the site ?

Maybe there are tools or techniques that I am not aware of however what matters for me the most is the user experience in this case, since is our brand/names out there and people will hate us not you :)

#12 @codeinwp
3 years ago

Same goes for example for contact form, what user will get if this is in a plugin, since without a shortcode built-in is just a basic form that will work just with our theme . Or there is any other reason for which you are saying to move this in a plugin ?

This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.


3 years ago

#14 @codeinwp
3 years ago

Hey Chip,

On a separate note, thinking at the user how can we not delay this particular update which fixes few bugs for few months until I expect everything to be ready, clarified and fixed.

#15 follow-up: @greenshady
3 years ago

Maybe we both have a different understanding of CPT however in those cases since we don't want a single view, or tags/categories or achieve pages I don't see honestly any reason why we should use a CPT for any of the ones listed above, especially focus/about, doing it will just create a complex and huge admin, a ton of unwanted automatically generated pages etc .

I wanted to touch on this because it is possible that you do have a different understanding of CPTs. Many people make the mistake of thinking that CPTs are just different types of posts/pages. That's not really the case.

CPTs may or may not have single views, taxonomies attached to them, or archive pages. Those things are not inherent to CPTs. Nav menu items are a great example of no single/archive pages. CPTs in WordPress are little more than a way to "register" a certain type of content. Registration and Implementation are two entirely different things.

This is speaking strictly about "testimonials". I haven't looked at the other stuff.

This ticket was mentioned in Slack in #themereview by superwinner. View the logs.


3 years ago

#17 follow-up: @tislam100
3 years ago

@chipbennett I thought the "No Custom Content Creation" rule is still up for discussion. Are you guys started forcing it now?

And I remember a few weeks ago, you said devs should use custom widgets to create custom content instead of creating them from theme options panel. Then why is this theme has to remove the custom widgets?

and as a solution, you are suggesting to create a plugin and port all those contents to that plugin. This solution has few flaws:

  1. Few extra steps for users.
  2. The plugin has to reside in wp.org plugin repo. (The plugin has to submitted/reviewd/approved).

And why are you not allowing the page-blog.php page template all of a sudden? why am I not seeing anything in the guideline?

P.S: I am commenting in this ticket because this new rules affects all the developers, including me.

#18 in reply to: ↑ 17 @chipbennett
3 years ago

Replying to tislam100:

@chipbennett I thought the "No Custom Content Creation" rule is still up for discussion. Are you guys started forcing it now?

@tislam100 "no content creation" is not a new rule. It has been part of the guidelines for years. It has always been enforced. Like all parts of the guidelines, it may have been enforced inconsistently, but we are addressing that.

And I remember a few weeks ago, you said devs should use custom widgets to create custom content instead of creating them from theme options panel. Then why is this theme has to remove the custom widgets?

I will reiterate that anything discussed in Slack is merely that: a discussion.

and as a solution, you are suggesting to create a plugin and port all those contents to that plugin. This solution has few flaws:

  1. Few extra steps for users.
  2. The plugin has to reside in wp.org plugin repo. (The plugin has to submitted/reviewd/approved).

Yes, any solution will probably result in some steps for users. We are having this discussion now, to figure out the best path forward, that minimizes impact to users.

And why are you not allowing the page-blog.php page template all of a sudden? why am I not seeing anything in the guideline?

Again, this isn't an "all of a sudden" thing. As for why?

http://www.chipbennett.net/2013/09/14/home-page-and-front-page-and-templates-oh-my/

P.S: I am commenting in this ticket because this new rules affects all the developers, including me.

Nothing being discussed in this ticket is a new rule.

#19 in reply to: ↑ 11 @chipbennett
3 years ago

Replying to codeinwp:

Cool sounds good, however I still have questions/ things that I consider important in the process :

  1. Why are you saying to convert it to a plugin ( beside the rules) can you give a certain usecase where this is more useful for the USER ? I am thinking for example if the user switch the theme, he keeps that 2 lines of text however he is required to edit both the theme and and tons of css style to make it work, it saves 10sec of copying the text and it adds 1 day of work to make it work with the new theme, also those 10s gained are lost at the beginning when they need to install the plugin, so where is the user gain here ? Rules are important, however when keeping them just for the sake of it and instead of protect the user we break their experience, I won't do it as a principle, I am doing all of this for creating something and improving users life not ruining it, otherwise my time invested in those products was wasted time. Again, maybe I am wrong, that's why I am asking for 1-2 use cases :)

Let's say the user has 20 testimonials, a team of 15 people, and 10 services/focuses. We're no longer talking about 10 seconds of work.

  1. Doing this will allow us to keep the demo as it is( through mockup text) and once user activate the plugin to change the theme exactly as it is now ? So to require just 1 extra step for the user to have exactly same experience as now.

The demo isn't really our concern.

  1. Can we safely migrate all existing users without requiring any input from their side ? Just install the plugin and theme automatically without breaking the site ?

This can be done in a way that is seamless to users, and that's what we'll try to accomplish.

  1. Port over all the relevant code to a Plugin, that uses failsafe methods to register the custom Widgets (Pluggable functions, etc.)
  2. Add the Plugin to the wp.org Plugin directory
  3. Have users install the Plugin. (At this point, the failsafe will apply, and the Plugin will do, essentially, nothing, so long as the Theme is active.)
  4. Revise the Theme to extract the Plugin-territory code
  5. Update the Theme in the wp.org Theme directory
  6. Users install the update. The Plugin will ensure that all custom Widgets remain registered.

Maybe there are tools or techniques that I am not aware of however what matters for me the most is the user experience in this case, since is our brand/names out there and people will hate us not you :)

Our main priority is user experience. That's why we're having this discussion: to ensure that our approach does not cause an adverse user experience.

Replying to codeinwp:

Hey Chip,

On a separate note, thinking at the user how can we not delay this particular update which fixes few bugs for few months until I expect everything to be ready, clarified and fixed.

Just to clarify: what we want to do here is agree on a path forward, to bring the Theme into compliance with the Guidelines, in a way that minimizes impact to users. Once we have that, we can figure out what (if any) changes needed to be made right away, and which ones we'll work with you to implement in future updates.

#20 in reply to: ↑ 15 ; follow-up: @codeinwp
3 years ago

Maybe we both have a different understanding of CPT however in those cases since we don't want a single view, or tags/categories or achieve pages I don't see honestly any reason why we should use a CPT for any of the ones listed above, especially focus/about, doing it will just create a complex and huge admin, a ton of unwanted automatically generated pages etc .

I wanted to touch on this because it is possible that you do have a different understanding of CPTs. Many people make the mistake of thinking that CPTs are just different types of posts/pages. That's not really the case.

CPTs may or may not have single views, taxonomies attached to them, or archive pages. Those things are not inherent to CPTs. Nav menu items are a great example of no single/archive pages. CPTs in WordPress are little more than a way to "register" a certain type of content. Registration and Implementation are two entirely different things.

This is speaking strictly about "testimonials". I haven't looked at the other stuff.

Thanks for clarifications Justin! First part of the problem is solved, however another reason why we have used widgets is that they are beautifuly integrated in customizer ( you can easily change order, add content from there or remove ), for CPT I will need to duplicate whole widgets experience and allow users to create cpts, edit/reording within the customizer, is this allowed/possible ? Any tips ? Otherwise users will be affected I believe and I don't think is good.

Why are you saying to convert it to a plugin ( beside the rules) can you give a certain usecase where this is more useful for the USER ? I am thinking for example if the user switch the theme, he keeps that 2 lines of text however he is required to edit both the theme and and tons of css style to make it work, it saves 10sec of copying the text and it adds 1 day of work to make it work with the new theme, also those 10s gained are lost at the beginning when they need to install the plugin, so where is the user gain here ? Rules are important, however when keeping them just for the sake of it and instead of protect the user we break their experience, I won't do it as a principle, I am doing all of this for creating something and improving users life not ruining it, otherwise my time invested in those products was wasted time. Again, maybe I am wrong, that's why I am asking for 1-2 use cases :)

Let's say the user has 20 testimonials, a team of 15 people, and 10 services/focuses. We're no longer talking about 10 seconds of work.

You are right, but we still have some issues/other solutions :

1) Even if the users have those, without any design, shortcode and just hardcoded cpt creation things, the amount of work required to get that content is quite big, even they might need to overwrite plugin code

2)The data is not lost, is in the DB and with the same amount of work as point 1), the user can get the data using get_theme_mod(oldtheme) if the data is in customizer, will be ok if instead of custom widgets we use customizer to store ? Again just applying some rules for everything because they are written as rules is not the best case always .

Doing this will allow us to keep the demo as it is( through mockup text) and once user activate the plugin to change the theme exactly as it is now ? So to require just 1 extra step for the user to have exactly same experience as now.

The demo isn't really our concern.

I don't really agree, when your actions affect others, proposing a solution is important, is important I believe to understand the full impact of the actions that we take here.

Can we safely migrate all existing users without requiring any input from their side ? Just install the plugin and theme automatically without breaking the site ?

This can be done in a way that is seamless to users, and that's what we'll try to accomplish.
Port over all the relevant code to a Plugin, that uses failsafe methods to register the custom Widgets >(Pluggable functions, etc.)
Add the Plugin to the wp.org Plugin directory
Have users install the Plugin. (At this point, the failsafe will apply, and the Plugin will do, >essentially, nothing, so long as the Theme is active.)

What if the users won't install the plugin ? What if they don't wanna waste this extra time, power should rather be in the hands of the users, not in ours.

Now I wanna going back on the initial review and discuss some other things :

Remove template-blog.php and template-blog-large.php. The blog posts index, per the template hierarchy, must use the home template (home.php, index.php).

You are right, template-blog.php is useless, we use home.php as well, however what if users already created pages using those templates? We would break their blogs.

Use get_template_directory_uri() instead of get_stylesheet_directory_uri() for default logo image path in header.php. Otherwise, this will break in a child Theme

You are again right, however we have already 3 popular child themes that are public which uses that logic, changing it will break them and with how trt works, I can't release or force users to simultaneously update.

My solution here is to add another if on file_exist, so if the logo is in child theme use it as default logo, if not use parent .

Custom post meta data, except for presentational meta data, is content creation, and therefore Plugin territory, e.g. author details, team member position, social network profiles, etc.

Is code that we forgot there and will be removed, is not used .

Scripts must be bundled with the Theme, and enqueued locally:
wp_enqueue_script( 'recaptcha', 'https://www.google.com/recaptcha/api.js' );

I have never heard of that and is quite bad idea, what is the logic behind ? Why plugins are allowed to do it ? My main worry is that I need to monitor google changes and release updates for the theme ( while there are a lot of people who don't wanna/can't update themes because of custom code )

The contact form on the static front page is Plugin territory

Again what is the logic behind ? I don't get it, just copy pasting this code in a plugin won't help anybody I guess.

We will send an update fixing what can be fixed without affecting the users ( after you help me understand if proposed solution is ok ) and if we can merge that, while discussing and clarifying the plan for next months will be great!

Other questions

The solution that some people are using and you are proposing to just put everything in a plugin I find it quite useless, what can be useful is to have a plugin that is generic, that can be extended, re-used, that have shortcodes and stlyles for everything, otherwise, just copy-pasting the code we won't help anybody, just the 'rules'.

I will be happy to implement all the things in the upcoming theme ( after we clarify why is good and what is the best way), however honestly I am a bit reticent about updating this one, force 100k users to install a plugin and risk a lot, but instead force the guideline for upcoming themes or themes that have way too much things in theme itself ( which should not be the case I think ) .

Discussing a solution for theme owners who don't wanna comply with this for different reasons will be great ( like remove the themes from repo etc ), so we can make sure that everyone is on the same line. Another question that I was wondering about is if TRT/WP.org can update a theme ( keeping same name/author ) without the acceptance of the author, basically affecting author brand.

Is not the case here, however is something that is not clear for me :).

This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.


3 years ago

#22 in reply to: ↑ 20 @chipbennett
3 years ago

Replying to codeinwp:

Thanks for clarifications Justin! First part of the problem is solved, however another reason why we have used widgets is that they are beautifuly integrated in customizer ( you can easily change order, add content from there or remove ), for CPT I will need to duplicate whole widgets experience and allow users to create cpts, edit/reording within the customizer, is this allowed/possible ? Any tips ? Otherwise users will be affected I believe and I don't think is good.

I don't think anyone is even suggesting that you use CPTs, or change anything of what you have currently into CPTs.

1) Even if the users have those, without any design, shortcode and just hardcoded cpt creation things, the amount of work required to get that content is quite big, even they might need to overwrite plugin code

Porting existing Widget code into a Plugin would cause zero issues for users. You can keep the Widget CSS in your Theme, so that, regardless of how the Widget is registered (Theme or Plugin), it still looks exactly the same. The content would stay the same. The integration into your Theme would stay the same. The Widgets would remain available when switching Themes, even if the Widgets aren't styled the same in a different Theme.

2)The data is not lost, is in the DB and with the same amount of work as point 1), the user can get the data using get_theme_mod(oldtheme) if the data is in customizer, will be ok if instead of custom widgets we use customizer to store ? Again just applying some rules for everything because they are written as rules is not the best case always .

From the user's perspective, the amount of work goes from zero (Plugin-registered Widgets) to considerable (Theme-registered Widgets).

The whole intent of not allowing Themes to define creation of content is because it is not acceptable to tell users that they need to figure out how to pull their content, that they have created, out of the DB. That's not good user experience. That's Theme lock-in.

The demo isn't really our concern.

I don't really agree, when your actions affect others, proposing a solution is important, is important I believe to understand the full impact of the actions that we take here.

You can always host a demo site, and point users to it. How the Theme looks on the wp.org demo is really not something that we have much control over, and in the future, we will have even less control.

What if the users won't install the plugin ? What if they don't wanna waste this extra time, power should rather be in the hands of the users, not in ours.

If users refuse to install the Plugin, then they can keep using their current version of the Theme. That's their choice.

Now I wanna going back on the initial review and discuss some other things :

Remove template-blog.php and template-blog-large.php. The blog posts index, per the template hierarchy, must use the home template (home.php, index.php).

You are right, template-blog.php is useless, we use home.php as well, however what if users already created pages using those templates? We would break their blogs.

I would propose something like so:

  1. Modify the two templates, so that they do nothing but include the home.php template (e.g. include( get_home_template() );
  2. Notify users that the two templates are deprecated, and instruct them to use the core settings
  3. Then, in the next update, remove the templates

    Use get_template_directory_uri() instead of get_stylesheet_directory_uri() for default logo image path in header.php. Otherwise, this will break in a child Theme

    You are again right, however we have already 3 popular child themes that are public which uses that logic, changing it will break them and with how trt works, I can't release or force users to simultaneously update.

    My solution here is to add another if on file_exist, so if the logo is in child theme use it as default logo, if not use parent .

  1. Update the Child Themes with failsafe code
  2. Update the parent Theme with correct usage of get_template_directory_uri()
  3. Update the Child Themes to accommodate the change to the parent Theme

Scripts must be bundled with the Theme, and enqueued locally:
wp_enqueue_script( 'recaptcha', 'https://www.google.com/recaptcha/api.js' );

I have never heard of that and is quite bad idea, what is the logic behind ? Why plugins are allowed to do it ? My main worry is that I need to monitor google changes and release updates for the theme ( while there are a lot of people who don't wanna/can't update themes because of custom code )

The contact form on the static front page is Plugin territory

Again what is the logic behind ? I don't get it, just copy pasting this code in a plugin won't help anybody I guess.

These two go together.

The only external API calls we allow Themes to make is the Google Fonts API.

The recaptcha API would not be used if not for the contact form. The contact form is user content/site functionality that the user would reasonably expect to exist regardless of chosen Theme.

Again, make it part of the companion Plugin, and you should be good to go. Note: I don't know the Plugin review requirements regarding external API calls. I assume it would be okay.

The solution that some people are using and you are proposing to just put everything in a plugin I find it quite useless, what can be useful is to have a plugin that is generic, that can be extended, re-used, that have shortcodes and stlyles for everything, otherwise, just copy-pasting the code we won't help anybody, just the 'rules'.

You're welcome to flesh out the Plugin as much or as little as you want. Make it as great as you want it to be. But at a minimum, it can and should be used to port Plugin-territory code from the Theme.

Note: we generally only recommend going this route for Themes that are already approved, when found to be creating content or implementing non-Theme functionality. Ideally, these things are caught in the initial review, prior to initial approval. If you don't already have users using the Theme, it's much easier to find alternate solutions.

I will be happy to implement all the things in the upcoming theme ( after we clarify why is good and what is the best way), however honestly I am a bit reticent about updating this one, force 100k users to install a plugin and risk a lot, but instead force the guideline for upcoming themes or themes that have way too much things in theme itself ( which should not be the case I think ) .

That Themes must not be used to define user content creation or site functionality has been a very long-standing requirement, for very good reason. While we're certainly looking at clarifying it, so that everyone understands what constitutes creation of content, the requirement itself is well-established.

Done properly, there should be zero risk or impact to current users by porting Plugin-territory functionality from the Theme into a Plugin. That is our goal.

Discussing a solution for theme owners who don't wanna comply with this for different reasons will be great ( like remove the themes from repo etc ), so we can make sure that everyone is on the same line. Another question that I was wondering about is if TRT/WP.org can update a theme ( keeping same name/author ) without the acceptance of the author, basically affecting author brand.

Is not the case here, however is something that is not clear for me :).

If that is possible, it is well above the pay grade of the TRT admins.

#23 follow-up: @greenshady
3 years ago

Thanks for clarifications Justin! First part of the problem is solved, however another reason why we have used widgets is that they are beautifuly integrated in customizer ( you can easily change order, add content from there or remove ), for CPT I will need to duplicate whole widgets experience and allow users to create cpts, edit/reording within the customizer, is this allowed/possible ? Any tips ? Otherwise users will be affected I believe and I don't think is good.

No, that's a bit too much. No need to recreate all that. In the theme, assuming the testimonial plugin doesn't already have this, you'd simply need to build a testimonial widget. You could let the user choose from a <select> which testimonial to display.

Use get_template_directory_uri() instead of get_stylesheet_directory_uri() for default logo image path in header.php. Otherwise, this will break in a child Theme

You are again right, however we have already 3 popular child themes that are public which uses that logic, changing it will break them and with how trt works, I can't release or force users to simultaneously update.
My solution here is to add another if on file_exist, so if the logo is in child theme use it as default logo, if not use parent.

That's a perfectly valid solution:

$file_uri = file_exists( $stylesheet_file ) ? $stylesheet_file_uri : $template_file_uri;

The guideline is that you must be child-theme friendly. This accomplishes that goal.

#24 follow-up: @codeinwp
3 years ago

Thanks for clarifications Justin! First part of the problem is solved, however another reason why we have used widgets is that they are beautifuly integrated in customizer ( you can easily change order, add content from there or remove ), for CPT I will need to duplicate whole widgets experience and allow users to create cpts, edit/reording within the customizer, is this allowed/possible ? Any tips ? Otherwise users will be affected I believe and I don't think is good.

I don't think anyone is even suggesting that you use CPTs, or change anything of what you have currently into CPTs.

Ok, so just be sure using widgets is ok if we use them in a separate plugin right ?

Even if the users have those, without any design, shortcode and just hardcoded cpt creation things, the amount of work required to get that content is quite big, even they might need to overwrite plugin code

Porting existing Widget code into a Plugin would cause zero issues for users. You can keep the Widget CSS in your Theme, so that, regardless of how the Widget is registered (Theme or Plugin), it still looks exactly the same. The content would stay the same. The integration into your Theme would stay the same. The Widgets would remain available when switching Themes, even if the Widgets aren't styled the same in a different Theme.

Will cause 0 issues indeed ( if we do it automatically, otherwise will be an extra step ), however the question is what user will gain ? He will keep some useless widgets in 99% of the cases

The whole intent of not allowing Themes to define creation of content is because it is not acceptable to tell users that they need to figure out how to pull their content, that they have created, out of the DB. That's not good user experience. That's Theme lock-in.

How is different get_posts from get_theme_mod on about us section for example which you say it should be in a plugin ? Getting the content out of the cpt will be much faster for those 3 blocks of text ?

For updates I see a mistake that you are making, you assume that the users really update, there is any data that we can see for Zerif Lite for example ? If we look at plugins, it takes 2 months to get 70% of the users updated, for themes I suspect is lower than 50% in 2 months, so things will break and this will affect both WordPress and us ( why WordPress doesn't simply drop versions lower than 4 after asking people to update ? ), I think what you are saying is completely unreasonable, I don't see the point to make the updates if 1% of the users will be affected, nobody should do that and say "I said you to update."

About this update, after we clarify things next week, can we push the bugs fixed live and see how we proceed for the future things ?

The contact form is user content/site functionality that the user would reasonably expect to exist regardless of chosen Theme.

since that is used just on homepage, even if we put it on a plugin, how the user can use it in another theme ? I honestly can;t understand.

#25 in reply to: ↑ 23 @codeinwp
3 years ago

Replying to greenshady:

Thanks for clarifications Justin! First part of the problem is solved, however another reason why we have used widgets is that they are beautifuly integrated in customizer ( you can easily change order, add content from there or remove ), for CPT I will need to duplicate whole widgets experience and allow users to create cpts, edit/reording within the customizer, is this allowed/possible ? Any tips ? Otherwise users will be affected I believe and I don't think is good.

No, that's a bit too much. No need to recreate all that. In the theme, assuming the testimonial plugin doesn't already have this, you'd simply need to build a testimonial widget. You could let the user choose from a <select> which testimonial to display.

Use get_template_directory_uri() instead of get_stylesheet_directory_uri() for default logo image path in header.php. Otherwise, this will break in a child Theme

You are again right, however we have already 3 popular child themes that are public which uses that logic, changing it will break them and with how trt works, I can't release or force users to simultaneously update.
My solution here is to add another if on file_exist, so if the logo is in child theme use it as default logo, if not use parent.

That's a perfectly valid solution:

$file_uri = file_exists( $stylesheet_file ) ? $stylesheet_file_uri : $template_file_uri;

The guideline is that you must be child-theme friendly. This accomplishes that goal.

Thanks for explanations, makes sense.

#26 follow-up: @tislam100
3 years ago

@chipbennett

Is this post falls under theme review guideline? I see this post in your personal blog, how do devs know this is a guideline?
http://www.chipbennett.net/2013/09/14/home-page-and-front-page-and-templates-oh-my/

and kindly please elaborate the "blog page template creation not allowed" rule. I dont know anything about it.

#27 in reply to: ↑ 26 @chipbennett
3 years ago

Replying to tislam100:

@chipbennett

Is this post falls under theme review guideline? I see this post in your personal blog, how do devs know this is a guideline?
http://www.chipbennett.net/2013/09/14/home-page-and-front-page-and-templates-oh-my/

and kindly please elaborate the "blog page template creation not allowed" rule. I dont know anything about it.

It falls under correct usage of core template hierarchy, and usage of core settings rather than working around them. The blog post merely explains what "correct usage" of the template hierarchy is in the context of the blog posts index and site front page.

This ticket was mentioned in Slack in #themereview by chipbennett. View the logs.


3 years ago

#29 @greenshady
3 years ago

I would propose something like so:

  1. Modify the two templates, so that they do nothing but include the home.php template (e.g. include( get_home_template() );
  2. Notify users that the two templates are deprecated, and instruct them to use the core settings
  3. Then, in the next update, remove the templates

I was thinking about this. The template is saved in post meta as the actual file name. So, I'd do these steps:

  • Remove Template Name: Example from the file header. This way it can't be selected for new pages but should still work for users who have it saved.
  • Modify the templates to simply include( get_home_template() );.
  • Notify users that the two templates are deprecated, and instruct them to use the core settings.
  • In the next update, remove the templates.

Anyway, I'd give that a try.

#30 @codeinwp
3 years ago

Thank you for the suggestion Justin.

#31 in reply to: ↑ 24 @chipbennett
3 years ago

Trying to make sure I've answered everything. If I repeat anything, I apologize.

Replying to codeinwp:

Ok, so just be sure using widgets is ok if we use them in a separate plugin right ?

Absolutely, and this one should be one of the easiest to port. You literally just have to register the Widget, as-is, in the Plugin. Put a failsafe around it, and the user will never know the difference.

Will cause 0 issues indeed ( if we do it automatically, otherwise will be an extra step ), however the question is what user will gain ? He will keep some useless widgets in 99% of the cases

The Widgets wouldn't be useless. They can be placed in any dynamic sidebar. Also, if the user wants to port those data to something else (maybe into a page, or a CPT from a Plugin, or whatever), all the unused Widgets are there, and make copying/pasting easier.

About this update, after we clarify things next week, can we push the bugs fixed live and see how we proceed for the future things ?

Absolutely. Let's clarify what will need to change, and what won't, and lay out a plan/timeline for implementing everything. Bear in mind that there are things other than content creation that need to be addressed. So, we'll either need to fix those now, before pushing live, or agree to a path for those, as well.

In either case, let's wait until after Tuesday's meeting, and then make a decision on this ticket.

since that is used just on homepage, even if we put it on a plugin, how the user can use it in another theme ? I honestly can;t understand.

Contact forms are site functionality. They are pretty straight-forward Plugin territory. You're welcome to put it in the same Plugin as the Widgets, or release your own contact-form Plugin (in either case, adding in code in the Theme to display it if present - i.e. typical Plugin integration), or even integrate support for one of the many existing contact form Plugins.

#32 @themetracbot
3 years ago

  • Summary changed from THEME: Zerif Lite – 1.8.0 to THEME: Zerif Lite – 1.8.1

Zerif Lite - 1.8.1

Zerif LITE is a free one page Wordpress theme. It&#8217;s perfect for web agency business,corporate business,personal and parallax business portfolio, photography sites and freelancer.Is built on BootStrap with parallax support, is responsive, clean, modern, flat and minimal. Zerif Lite is ecommerce (WooCommerce) Compatible, WPML, RTL, Retina-Ready, SEO Friendly and with parallax, full screen image is one of the best business themes.

Theme URL - http://themeisle.com/themes/zerif-lite/
Author URL - http://themeisle.com

SVN - https://themes.svn.wordpress.org/zerif-lite/1.8.1
ZIP - https://wordpress.org/themes/download/zerif-lite.1.8.1.zip?nostats=1

Diff with previous version: https://themes.trac.wordpress.org/changeset?old_path=zerif-lite/1.8.0&new_path=zerif-lite/1.8.1

History:

Ticket Summary Status Resolution Owner
#20384 THEME: Zerif Lite - 1.0.5 closed live karmatosed
#21317 THEME: Zerif Lite - 1.3 closed live catchthemes
#21451 THEME: Zerif Lite - 1.3.1 closed live emiluzelac
#21597 THEME: Zerif Lite - 1.3.9 closed live jcastaneda
#22197 THEME: Zerif Lite - 1.4.0 closed live karmatosed
#22433 THEME: Zerif Lite - 1.4.1 closed live karmatosed
#22574 THEME: Zerif Lite - 1.4.3 closed live jcastaneda
#22756 THEME: Zerif Lite - 1.4.4 closed live nishasingh
#22951 THEME: Zerif Lite - 1.4.5 closed live Milmor
#23105 THEME: Zerif Lite - 1.4.6 closed live grapplerulrich
#23191 THEME: Zerif Lite - 1.4.7 closed live emiluzelac
#23364 THEME: Zerif Lite – 1.5.2 closed live jcastaneda
#23596 THEME: Zerif Lite – 1.5.4 closed live hardeepasrani
#23775 THEME: Zerif Lite – 1.6.0 closed live jcastaneda
#24098 THEME: Zerif Lite – 1.7.1 closed live poena
#24296 THEME: Zerif Lite – 1.7.2 closed live jcastaneda
#24323 THEME: Zerif Lite – 1.7.3 closed live jacenty3590
#24568 THEME: Zerif Lite – 1.7.6 closed live karmatosed
#24907 THEME: Zerif Lite – 1.8.2.1 closed live chipbennett

(this ticket)

#25711 THEME: Zerif Lite – 1.8.2.2 closed live jcastaneda
#26096 THEME: Zerif Lite – 1.8.2.3 closed live chipbennett
#26505 THEME: Zerif Lite2015 – 1.8.2.3 closed not-approved alex27
#26918 THEME: Zerif Lite Nicole – 2.0.1.1 closed not-approved jcastaneda
#26955 THEME: Zerif litez – 2.0.1.2 closed not-approved jcastaneda
#27715 THEME: Zerif Lite mine – 1.8.2.5 closed not-approved jcastaneda
#27836 THEME: Zerif Lite – 1.8.2.4 closed live karmatosed
#27977 THEME: Zerif Lite – 1.8.2.5 closed live jcastaneda
#28112 THEME: Zerif Lite – 1.8.2.6 closed live karmatosed
#28449 THEME: Zerif Lite – 1.8.2.7 closed live karmatosed
#28454 THEME: Zerif Lite – 1.8.2.8 closed live karmatosed
#28637 THEME: Zerif Lite – 1.8.2.9 closed live karmatosed
#28818 THEME: Zerif Lite – 1.8.3.0 closed live karmatosed
#29196 THEME: Zerif Lite – 1.8.3.1 closed live Otto42
#29720 THEME: Zerif Lite – 1.8.3.2 closed live greenshady
#29824 THEME: Zerif Lite – 1.8.3.3 closed live Otto42
#30045 THEME: Zerif Lite – 1.8.3.5 closed live joedolson
#31136 THEME: Zerif Lite – 1.8.3.6 closed live themetracbot
#31326 THEME: Zerif Lite – 1.8.3.7 closed live themetracbot
#31338 THEME: Zerif Lite – 1.8.3.8 closed live themetracbot
#31672 THEME: Zerif Lite – 1.8.4.0 closed live themetracbot
#32649 THEME: Zerif Lite – 1.8.4.1 closed live themetracbot
#33432 THEME: Zerif Lite – 1.8.4.3 closed live themetracbot
#33435 THEME: Zerif Lite – 1.8.4.4 closed live themetracbot
#34821 THEME: Zerif Lite – 1.8.4.5 closed live themetracbot
#35904 THEME: Zerif Lite – 1.8.4.6 closed live themetracbot
#35906 THEME: Zerif Lite – 1.8.4.7 closed closed-newer-version-uploaded grapplerulrich
#35981 THEME: Zerif Lite – 1.8.4.8 closed live themetracbot
#36004 THEME: Zerif Lite – 1.8.4.9 closed live themetracbot
#38196 THEME: Zerif Lite – 1.8.5.5 closed closed-newer-version-uploaded grapplerulrich
#38491 THEME: Zerif Lite – 1.8.5.8 closed live grapplerulrich
#40574 THEME: Zerif Lite – 1.8.5.9 closed live themetracbot
#40631 THEME: Zerif Lite – 1.8.5.10 closed live themetracbot
#40693 THEME: Zerif Lite – 1.8.5.11 closed live themetracbot
#40754 THEME: Zerif Lite – 1.8.5.12 closed live themetracbot
#40959 THEME: Zerif Lite – 1.8.5.13 closed live themetracbot
#40969 THEME: Zerif Lite – 1.8.5.14 closed live themetracbot
#40986 THEME: Zerif Lite – 1.8.5.15 closed live themetracbot
#41931 THEME: Zerif Lite – 1.8.5.16 closed live themetracbot
#42398 THEME: Zerif Lite – 1.8.5.17 closed live themetracbot
#42453 THEME: Zerif Lite – 1.8.5.18 closed live themetracbot
#42609 THEME: Zerif Lite – 1.8.5.19 closed live themetracbot
#42726 THEME: Zerif Lite – 1.8.5.20 closed live themetracbot
#42812 THEME: Zerif Lite – 1.8.5.21 closed live themetracbot
#42914 THEME: Zerif Lite – 1.8.5.22 closed live themetracbot
#42936 THEME: Zerif Lite – 1.8.5.23 closed live themetracbot
#43874 THEME: Zerif Lite – 1.8.5.24 closed live themetracbot
#44274 THEME: Zerif Lite – 1.8.5.25 closed live themetracbot
#45942 THEME: Zerif Lite – 1.8.5.26 closed live themetracbot
#45946 THEME: Zerif Lite – 1.8.5.27 closed live themetracbot
#45953 THEME: Zerif Lite – 1.8.5.28 closed live themetracbot
#46180 THEME: Zerif Lite – 1.8.5.29 closed live themetracbot
#47696 THEME: Zerif Lite – 1.8.5.30 closed live themetracbot
#47965 THEME: Zerif Lite – 1.8.5.31 closed live themetracbot
#48058 THEME: Zerif Lite – 1.8.5.32 closed live themetracbot
#49309 THEME: Zerif Lite – 1.8.5.33 closed live themetracbot


https://themes.svn.wordpress.org/zerif-lite/1.8.1/screenshot.png

#33 @codeinwp
3 years ago

@chipbennett we changed the readme for images and font awesome license, we removed the Custom post meta data which was not used in the theme and checked if the logo images exists in the child theme, as suggested above. Beside that, we fixes some other issues , and did some improvements.

#34 @themetracbot
3 years ago

  • Summary changed from THEME: Zerif Lite – 1.8.1 to THEME: Zerif Lite – 1.8.2.1

Zerif Lite - 1.8.2.1

Zerif LITE is a free one page Wordpress theme. It&#8217;s perfect for web agency business,corporate business,personal and parallax business portfolio, photography sites and freelancer.Is built on BootStrap with parallax support, is responsive, clean, modern, flat and minimal. Zerif Lite is ecommerce (WooCommerce) Compatible, WPML, RTL, Retina-Ready, SEO Friendly and with parallax, full screen image is one of the best business themes.

Theme URL - http://themeisle.com/themes/zerif-lite/
Author URL - http://themeisle.com

SVN - https://themes.svn.wordpress.org/zerif-lite/1.8.2.1
ZIP - https://wordpress.org/themes/download/zerif-lite.1.8.2.1.zip?nostats=1

Diff with previous version: https://themes.trac.wordpress.org/changeset?old_path=zerif-lite/1.8.1&new_path=zerif-lite/1.8.2.1

History:

Ticket Summary Status Resolution Owner
#20384 THEME: Zerif Lite - 1.0.5 closed live karmatosed
#21317 THEME: Zerif Lite - 1.3 closed live catchthemes
#21451 THEME: Zerif Lite - 1.3.1 closed live emiluzelac
#21597 THEME: Zerif Lite - 1.3.9 closed live jcastaneda
#22197 THEME: Zerif Lite - 1.4.0 closed live karmatosed
#22433 THEME: Zerif Lite - 1.4.1 closed live karmatosed
#22574 THEME: Zerif Lite - 1.4.3 closed live jcastaneda
#22756 THEME: Zerif Lite - 1.4.4 closed live nishasingh
#22951 THEME: Zerif Lite - 1.4.5 closed live Milmor
#23105 THEME: Zerif Lite - 1.4.6 closed live grapplerulrich
#23191 THEME: Zerif Lite - 1.4.7 closed live emiluzelac
#23364 THEME: Zerif Lite – 1.5.2 closed live jcastaneda
#23596 THEME: Zerif Lite – 1.5.4 closed live hardeepasrani
#23775 THEME: Zerif Lite – 1.6.0 closed live jcastaneda
#24098 THEME: Zerif Lite – 1.7.1 closed live poena
#24296 THEME: Zerif Lite – 1.7.2 closed live jcastaneda
#24323 THEME: Zerif Lite – 1.7.3 closed live jacenty3590
#24568 THEME: Zerif Lite – 1.7.6 closed live karmatosed
#24907 THEME: Zerif Lite – 1.8.2.1 closed live chipbennett

(this ticket)

#25711 THEME: Zerif Lite – 1.8.2.2 closed live jcastaneda
#26096 THEME: Zerif Lite – 1.8.2.3 closed live chipbennett
#26505 THEME: Zerif Lite2015 – 1.8.2.3 closed not-approved alex27
#26918 THEME: Zerif Lite Nicole – 2.0.1.1 closed not-approved jcastaneda
#26955 THEME: Zerif litez – 2.0.1.2 closed not-approved jcastaneda
#27715 THEME: Zerif Lite mine – 1.8.2.5 closed not-approved jcastaneda
#27836 THEME: Zerif Lite – 1.8.2.4 closed live karmatosed
#27977 THEME: Zerif Lite – 1.8.2.5 closed live jcastaneda
#28112 THEME: Zerif Lite – 1.8.2.6 closed live karmatosed
#28449 THEME: Zerif Lite – 1.8.2.7 closed live karmatosed
#28454 THEME: Zerif Lite – 1.8.2.8 closed live karmatosed
#28637 THEME: Zerif Lite – 1.8.2.9 closed live karmatosed
#28818 THEME: Zerif Lite – 1.8.3.0 closed live karmatosed
#29196 THEME: Zerif Lite – 1.8.3.1 closed live Otto42
#29720 THEME: Zerif Lite – 1.8.3.2 closed live greenshady
#29824 THEME: Zerif Lite – 1.8.3.3 closed live Otto42
#30045 THEME: Zerif Lite – 1.8.3.5 closed live joedolson
#31136 THEME: Zerif Lite – 1.8.3.6 closed live themetracbot
#31326 THEME: Zerif Lite – 1.8.3.7 closed live themetracbot
#31338 THEME: Zerif Lite – 1.8.3.8 closed live themetracbot
#31672 THEME: Zerif Lite – 1.8.4.0 closed live themetracbot
#32649 THEME: Zerif Lite – 1.8.4.1 closed live themetracbot
#33432 THEME: Zerif Lite – 1.8.4.3 closed live themetracbot
#33435 THEME: Zerif Lite – 1.8.4.4 closed live themetracbot
#34821 THEME: Zerif Lite – 1.8.4.5 closed live themetracbot
#35904 THEME: Zerif Lite – 1.8.4.6 closed live themetracbot
#35906 THEME: Zerif Lite – 1.8.4.7 closed closed-newer-version-uploaded grapplerulrich
#35981 THEME: Zerif Lite – 1.8.4.8 closed live themetracbot
#36004 THEME: Zerif Lite – 1.8.4.9 closed live themetracbot
#38196 THEME: Zerif Lite – 1.8.5.5 closed closed-newer-version-uploaded grapplerulrich
#38491 THEME: Zerif Lite – 1.8.5.8 closed live grapplerulrich
#40574 THEME: Zerif Lite – 1.8.5.9 closed live themetracbot
#40631 THEME: Zerif Lite – 1.8.5.10 closed live themetracbot
#40693 THEME: Zerif Lite – 1.8.5.11 closed live themetracbot
#40754 THEME: Zerif Lite – 1.8.5.12 closed live themetracbot
#40959 THEME: Zerif Lite – 1.8.5.13 closed live themetracbot
#40969 THEME: Zerif Lite – 1.8.5.14 closed live themetracbot
#40986 THEME: Zerif Lite – 1.8.5.15 closed live themetracbot
#41931 THEME: Zerif Lite – 1.8.5.16 closed live themetracbot
#42398 THEME: Zerif Lite – 1.8.5.17 closed live themetracbot
#42453 THEME: Zerif Lite – 1.8.5.18 closed live themetracbot
#42609 THEME: Zerif Lite – 1.8.5.19 closed live themetracbot
#42726 THEME: Zerif Lite – 1.8.5.20 closed live themetracbot
#42812 THEME: Zerif Lite – 1.8.5.21 closed live themetracbot
#42914 THEME: Zerif Lite – 1.8.5.22 closed live themetracbot
#42936 THEME: Zerif Lite – 1.8.5.23 closed live themetracbot
#43874 THEME: Zerif Lite – 1.8.5.24 closed live themetracbot
#44274 THEME: Zerif Lite – 1.8.5.25 closed live themetracbot
#45942 THEME: Zerif Lite – 1.8.5.26 closed live themetracbot
#45946 THEME: Zerif Lite – 1.8.5.27 closed live themetracbot
#45953 THEME: Zerif Lite – 1.8.5.28 closed live themetracbot
#46180 THEME: Zerif Lite – 1.8.5.29 closed live themetracbot
#47696 THEME: Zerif Lite – 1.8.5.30 closed live themetracbot
#47965 THEME: Zerif Lite – 1.8.5.31 closed live themetracbot
#48058 THEME: Zerif Lite – 1.8.5.32 closed live themetracbot
#49309 THEME: Zerif Lite – 1.8.5.33 closed live themetracbot


https://themes.svn.wordpress.org/zerif-lite/1.8.2.1/screenshot.png

#35 @codeinwp
3 years ago

Hey,

Akamai just reported an XSS vulnerability ( https://wordpress.org/support/topic/vulnerability-in-theme?replies=2 ) that we though we have fixed a month ago, however we have missed the textarea field back then, now this was fixed and is up to you if it makes sense to push this live.

Considering the fact that none of the reported 'issues' were introduced if I would have the authority my call would be to push this live.

#36 @grapplerulrich
3 years ago

  • Cc grapplerulrich added; grappelulrich removed
  • Resolution set to live
  • Status changed from reviewing to closed

Due to the security risk I approving the update and setting it live. We can still continue the discussion/review in the ticket.

This ticket was mentioned in Slack in #themereview by poena. View the logs.


3 years ago

This ticket was mentioned in Slack in #themereview by codeinwp. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.