#10654 closed task (blessed) (fixed)
Remove Classic and Kubrick Themes
Reported by: | technosailor | Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 2.9 |
Component: | Themes | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
Remove the classic and kubrick themes from core. Add them to the .org directory.
Only copy the most recent theme (i.e. twentyten) during automatic upgrades. Rely on the plugin and theme upgraders where possible and stop copying wp-content during automatic upgrades.
SVN users will lose default and classic on svn up. Ensure that there is code in the upgrader to switch to twentyten being the new active theme if necessary.
Attachments (2)
Change History (51)
#2
@
15 years ago
- Keywords remove-classic-theme added
Every time I do a new install or upgrade an existing install, I delete this theme and the Hello Dolly plugin immediately.
I personally would like to see it removed. It could still be available from the Extend section if someone wanted to download it, but I don't think it needs to be distributed with the core package.
#3
follow-up:
↓ 7
@
15 years ago
Reality is, WP provides semantic classnames throughout now so the need for Classic for the sake of child themes is greatly reduced.
In addition, removing it from core does not remove it from installs in the wild unless someone overtly deletes it from their own file tree.
The biggest argument, though, is that it somehow inherently notes an endorsement of "this is how themes are meant to be" by inclusion. And I think we all agree this is NOT how themes are meant to be in 2009...
#5
@
15 years ago
- Milestone changed from Unassigned to 2.9
Also in favor of removing it from Core. It just doesn't belong there anymore.
If people still want to use it, I'm sure there will be someone willing to maintain it on Extend.
#7
in reply to:
↑ 3
@
15 years ago
Replying to technosailor:
The biggest argument, though, is that it somehow inherently notes an endorsement of "this is how themes are meant to be" by inclusion. And I think we all agree this is NOT how themes are meant to be in 2009...
Exactly, and you can one-click install themes from the admin area.
#8
@
15 years ago
The problem is that Default is too filled with cruft to be suitable as a basis for creating one's own theme, and there's no way to tell from browsing which among those in the repository are good examples (many if not most are problematic).
Classic shows how to do the basics, and it's good to have a basic example. If you think its example is bad, patch it or suggest a replacement. But please don't argue that you're concerned about having a bad example and then leave Default as the only one or suggest sending people out to the repository.
Personally, I'd take the defunct Sandbox, strip out the dated widgets and semantics functions and replace them with up-to-date equivalents, and replace Classic with it. Maybe someone can suggest a current, better example.
#9
@
15 years ago
- Milestone changed from 2.9 to Future Release
I want to see the default themes changed, but I think that's being discussed for 3.0 at earliest rather than 2.9.
#10
@
15 years ago
- Cc hd-J added
With the upcoming release of 2010, I believe this ticket is more valid than ever. I don't know if the question was raised in another ticket, but what is the plan for Kubrick, should it be removed as well?
#11
follow-up:
↓ 13
@
15 years ago
-1 to removing the 'default' theme, at least for now. A large number of examples in Codex and the Forums reference that theme.
#12
@
15 years ago
I don't see a reason to remove Kubrick (yet), but the Classic theme is super archaic.
#13
in reply to:
↑ 11
;
follow-up:
↓ 19
@
15 years ago
Replying to michaelh:
-1 to removing the 'default' theme, at least for now. A large number of examples in Codex and the Forums reference that theme.
So, edit the Codex!
#14
follow-up:
↓ 15
@
15 years ago
I'm willing to bet that the styling and markup of the "classic" theme is a lot easier for beginners to understand and customize than "default."
Not to mention there are some questionable choices of styling and markup in default that make it a poor example to learn from.
#15
in reply to:
↑ 14
;
follow-up:
↓ 16
@
15 years ago
Replying to filosofo:
I'm willing to bet that the styling and markup of the "classic" theme is a lot easier for beginners to understand and customize than "default."
Alright, it may be easier to understand, but isn't it why we decided to go for a new 2010 theme? Create a modern and easy to understand theme that shows to the beginners all what you can do with WordPress?
Imo "classic" does not give a good image of WordPress to beginners. 2010 should be the theme you learn from, not "classic".
#16
in reply to:
↑ 15
;
follow-up:
↓ 17
@
15 years ago
Replying to hd-J:
Replying to filosofo:
I'm willing to bet that the styling and markup of the "classic" theme is a lot easier for beginners to understand and customize than "default."
Alright, it may be easier to understand, but isn't it why we decided to go for a new 2010 theme? Create a modern and easy to understand theme that shows to the beginners all what you can do with WordPress?
2010 is not a good example for beginners. It's obvious if you just compare loop.php in 2010 to index.php in Classic.
What is the main concern here? The extra filesize? It's insignificant. That WP will look bad? The name "Classic" makes it obvious that the look isn't meant to be cutting-edge.
#17
in reply to:
↑ 16
;
follow-up:
↓ 18
@
15 years ago
Replying to filosofo:
What is the main concern here? The extra filesize? It's insignificant. That WP will look bad? The name "Classic" makes it obvious that the look isn't meant to be cutting-edge.
I completely agree with you here: filsize should not matter, and people will realize that theme isn't cutting-edge when they are going to activate it.
What bothers me here (but maybe it's just me, I'd be happy to hear others' thoughts about that) is that "Classic" is the base for all beginners who are looking to develop their own theme.
It means that if "Classic" remains, we are likely to see themes based on "Classic" on the Internet. The question is; is that what we want, or do we want the users to look into another default theme such as 2010, and start using some of the WordPress functions developed since the release of "Classic"?
Ultimately, it's about the image of WordPress online: if people see advanced WordPress sites, they will realize the potential behind it. If they keep seeing classic blogs, or if they get the idea that WordPress needs lots of plugins and custimzations to look like a proper site, they won't necessarily consider using WordPress.
But maybe I am completely wrong here... In that case sorry to bring this up.
#18
in reply to:
↑ 17
@
15 years ago
Replying to hd-J:
What bothers me here (but maybe it's just me, I'd be happy to hear others' thoughts about that) is that "Classic" is the base for all beginners who are looking to develop their own theme.
Beginners have to start somewhere, preferably with something simple. 2010 is not simple.
It means that if "Classic" remains, we are likely to see themes based on "Classic" on the Internet.
Ha. It's been five years since WP 1.5 came out with Kubrick as the bundled theme. If this was going to be a problem, it would have already shown up.
The question is; is that what we want, or do we want the users to look into another default theme such as 2010, and start using some of the WordPress functions developed since the release of "Classic"?
A better question is, "does Classic do something wrong?" If so, then let's fix it (should be trivial enough since not much is there). There's nothing wrong with not using the latest whiz-bang features; you can look elsewhere (perhaps 2010) to see those.
Ultimately, it's about the image of WordPress online: if people see advanced WordPress sites, they will realize the potential behind it. If they keep seeing classic blogs, or if they get the idea that WordPress needs lots of plugins and custimzations to look like a proper site, they won't necessarily consider using WordPress.
This argument would have had more traction in February 2005 at the advent of Kubrick, when WordPress was just an upstart in the blogging world. Today there are numerous multi-million-dollar businesses built around WordPress theming. It's less a question of "can it be done" than "how can it be done."
But maybe I am completely wrong here... In that case sorry to bring this up.
My concern is mainly that beginners will lose a ready example of a basic theme. Kubrick and much of the free theme repository make bad educational examples. Others, like 2010, are too complicated for beginners. And how do beginners even know where to look?
#19
in reply to:
↑ 13
;
follow-up:
↓ 20
@
15 years ago
Replying to technosailor:
Replying to michaelh:
-1 to removing the 'default' theme, at least for now. A large number of examples in Codex and the Forums reference that theme.
So, edit the Codex!
Good idea! Note, I'm not arguing to "never" delete the default theme, but suggesting it be deferred until the 2010 theme gets some traction in blogs and the forum, and after your excellent suggestion of updating Codex gets implemented.
#20
in reply to:
↑ 19
;
follow-up:
↓ 22
@
15 years ago
Replying to michaelh:
Good idea! Note, I'm not arguing to "never" delete the default theme, but suggesting it be deferred until the 2010 theme gets some traction in blogs and the forum, and after your excellent suggestion of updating Codex gets implemented.
Agreed. twentyten in WP 3.0 then I'll be fighting hard to have the classic removed. I don't think it serves anyone to handicap *beginners* with Classic when good docs and education on twentyten will suffice. Leave default in there (rename it though) and then let's offer classic as a separate theme that isn't bundled for those that still need or want it. But as an organization, let's push people in a positive direction.
@
15 years ago
Here's an idea. Make Classic a child theme of twentyten to demonstrate how easy it is to do child themes and push people in that direction. Give a man a fish or teach a man to fish.
#21
@
15 years ago
Modifying Classic is a very bad idea. For example on WordPress.com we have 3 themes that are classic templates:
$ ack 'Template: classic'
banana-smoothie/style.css
7:Template: classic
blue-green/style.css
8:Template: classic
silver-black/style.css
8:Template: classic
#22
in reply to:
↑ 20
@
15 years ago
- Cc mikeschinkel@… added
Replying to technosailor:
Agreed. twentyten in WP 3.0 then I'll be fighting hard to have the classic removed. I don't think it serves anyone to handicap *beginners* with Classic when good docs and education on twentyten will suffice. Leave default in there (rename it though) and then let's offer classic as a separate theme that isn't bundled for those that still need or want it. But as an organization, let's push people in a positive direction.
+1
#23
@
15 years ago
- Component changed from General to Themes
- Description modified (diff)
- Keywords needs-patch added; remove-classic-theme removed
- Milestone changed from Future Release to 3.0
- Summary changed from Remove Classic Theme to Remove Classic and Kubrick Themes
- Type changed from enhancement to task (blessed)
#24
@
15 years ago
I want to remove both Classic and Default. Put them in the Themes Directory so that upgrades will be available. Those who svn up will lose them after upping, but some upgrade code that switches to twentyten if default or classic disappear will suffice. svn uppers who use classic or default probably only use them for testbeds.
Shipping stuff in wp-content is lame. We have to ship one theme, but the Themes Directory should be used for all others.
#25
@
15 years ago
Sounds great to me.
People upgrading (manually or via automatic) will end up with Classic, WordPress Default (aka Kubrick), and TwentyTen. While not perfect, it's acceptable and won't break anything (child themes, etc) or be confusing to the user at all (their good ol' default
folder will still be there).
New installs will have only TwentyTen and won't be confused by default
. They also won't get exposed to the very dated Kubrick codebase either.
#26
@
15 years ago
- Cc aaron@… added
I'm very +1.
If possible, this should be included in the e-mail that goes out to all theme and plugin developers as they are more likely to run off of svn.
#27
@
15 years ago
The other option is to leave these themes as Externals in SVN, same for akismet, and just not include externals in the zip archives.
That'd allow for the themes to be kept in the themes to be included for dev purposes, and only the latest theme (say, twentyten) included in the bundled downloads.
Result would be
- New Installs: Only twentyten available
- Upgrade Installs (SVN): All 3 available, 2 via SVN external, 1 via normal svn
- Upgrtade Install (Core Upgrade): All 3 available(Twentyten + what the user had previously)
#28
@
14 years ago
Using externals and doing svn export --ignore-externals during packaging is a neat idea. Might be a good for 3.0 so that we can give everyone some warning before we remove them completely in 3.x.
#29
follow-up:
↓ 30
@
14 years ago
I'll be working on moving Classic and Default over to the theme directory with the (tentative) theme names, WordPress Classic and WordPress Default, as user wordpressdotorg.
#30
in reply to:
↑ 29
@
14 years ago
Replying to iandstewart:
I'll be working on moving Classic and Default over to the theme directory with the (tentative) theme names, WordPress Classic and WordPress Default, as user wordpressdotorg.
Sounds great. I would go with "WordPress Kubrick" IMO, with a description that explains it was the default from 1.5 - 2.9. I imagine the themes update API could probably be configured to return WordPress Kubrick if WordPress Default is requested.
#31
@
14 years ago
I'd suggest 'WordPress Classic' and 'WordPress Default' simply because those are the mostly likely to be recognized by users who are looking for them. I suspect there are very few users who know anything about Kubrick.
#32
@
14 years ago
Though I can understand not wanting to use 'Default' in the name. If we can come up with something else that conveys the same idea I'd be cool with that.
#35
@
14 years ago
The slugs have to remain classic and default for upgrade to work, yes?
Unfortunately this is the case for Themes (Plugins do not suffer this shortcoming IIRC).
#36
follow-up:
↓ 37
@
14 years ago
WordPress Classic and WordPress Default are in the Theme Directory.
WordPress Classic:
http://wordpress.org/extend/themes/wordpress-classic
WordPress Default:
http://wordpress.org/extend/themes/wordpress-default
#37
in reply to:
↑ 36
@
14 years ago
Themes so nice, I named them twice. :)
#39
@
14 years ago
Maybe related #12771 where comments stop working. Not an ideal situation for a multitude of users who do not move on from "Default" and instead lodge support requests on the forums asking why x and y has stopped working.
That particular thing seems to relate to a change from some time ago, but one can see a number of users sticking with Default post 3.0 and then wondering why things stop working in future builds.
Maybe there could be some kind of one-off message post updates to 3.0 that introduces and recommends moving to the 2010 theme?
#40
follow-up:
↓ 41
@
14 years ago
Is it possible to add externals like with Akismet? That should help keeping current while doning dev-work in core.
#41
in reply to:
↑ 40
@
14 years ago
Replying to hakre:
Is it possible to add externals like with Akismet? That should help keeping current while doning dev-work in core.
What we would like to end up moving towards is not bundling anything at all in wp-content. That goes for akismet as well.
#42
follow-up:
↓ 43
@
14 years ago
That said, removing Akismet will be more difficult, as that is actually used by a lot of people on svn, versus say classic and default. Ignoring externals on packaging would need to leave Akismet for now.
I think the long term goal is a core plugin for spam (that includes Akismet and other services as well, IIRC). Then we could stop packaging Akismet in core, and phase it out as an external.
Bottom line is, we'll need to take this in steps.
#43
in reply to:
↑ 42
;
follow-up:
↓ 44
@
14 years ago
Replying to nacin:
That said, removing Akismet will be more difficult, as that is actually used by a lot of people on svn, versus say classic and default. Ignoring externals on packaging would need to leave Akismet for now.
Well same goes for users of Classic and Default which are current _not_ downloading it spereately - being it via svn, http or ftp.
I think the long term goal is a core plugin for spam (that includes Akismet and other services as well, IIRC). Then we could stop packaging Akismet in core, and phase it out as an external.
That sounds reasonable to me.
Bottom line is, we'll need to take this in steps.
So here are the SVN externals for Classic / Default for those who might want to use it but I was not able to find the SVN for those themes. No more version control for them? Last one in the 2.9 trunk? Any Ideas?
#44
in reply to:
↑ 43
;
follow-up:
↓ 45
@
14 years ago
Replying to hakre:
So here are the SVN externals for Classic / Default for those who might want to use it but I was not able to find the SVN for those themes. No more version control for them? Last one in the 2.9 trunk? Any Ideas?
Scroll up. Both themes have already been moved over to the themes SVN repository.
http://themes.svn.wordpress.org/default/[[BR]]
http://themes.svn.wordpress.org/clasic/
#47
@
14 years ago
- Keywords needs-patch removed
- Resolution set to fixed
- Status changed from new to closed
Isn't this finished now? Any Idea why this ticket is still open? Themes are in the .org repository already and removed from trunk:
Removal Changeset(s):
[13879]
.org Repository:
http://wordpress.org/extend/themes/classic
http://wordpress.org/extend/themes/default
.org SVN:
http://themes.svn.wordpress.org/classic/
http://themes.svn.wordpress.org/default/
I truly do not understand what's left here so this is obviously to be closed IMHO.
#48
@
14 years ago
This is done.
We don't need/want the externals - existing sites will upgrade and keep the themes fine unless run purely from svn.
If you run from svn and want them back the checkout urls are up above.
Some people still use it. Maybe not nakedly, but with CSS-only "child" themes. And it doesn't really cost us much. Others may disagree, so I'll leave it open for feedback.