Add .info files to themes (and improve/clean up the theme system)

A decent run-through of the code gets a +1 from me; though I am not quite alert enough to do a proper code review, I am very much in favor of this.

i, too, am too tired for a proper, careful review, and i haven't tried applying and testing anything with this patch. but, a once-through the code looks great to me, and i'm *all* in favor of this change. +1 in principle, but i can't RTBC without more time (and sleep) for a real review.

I never thought I did found it *that* horny to see my name appear in the themes list when a default drupal install was made.

Only regarding to that, I would even +1 this patch!

(Just kidding, subscribing and giving the patch a good intensive test/review)

subscribing

Steven, well done!

First off, I agree, parse_ini() of current *.info files sucks. I've run into so many problems, I'm glad to see Steven has written a very nice parser that gives a lot more power. Kudos!

Next up, review:

+ 'left' => 'Left sidebar',
+ 'right' => 'Right sidebar',

Is there any reason these are left sidebar and right sidebar still? I've run into problems where it's confusing which value to use -- often the key and the value being the same makes things easier. I would advocate doing this as well to keep things easier, however, that shouldn't stop this patch.

What about themes and subthemes? Right now, they each get their own info file, but it seems to me, using the package attribute might make sense. I imagine Zen one day with 20 subthemes, being able to group these would go a long ways. However, since there are dependencies with themes (since defaults are provided), perhaps that is a bit overzealous.

Question, it wasn't clear to me that if you override regions it adds to defaults or replaces. Example:

+name = Chameleon
+description = Designed by Dries Buytaert.
+regions[left] = Left sidebar
+regions[right] = Right sidebar
+features[] = logo

Is that saying there are *only* 2 regions, or adding those into the defaults, in which that would be redundant since they are already defined.

Otherwise, patch looks great, +1

I don't like storing configuration parameters in the .ini file. This was something we decided against, and a good reason not to use a custom ini parser. If we start storing this information in the .ini file, then where do we draw the line? Soon, modules will want to add all kinds of metadata to their .ini files too, and all of a sudden, we find ourselves with two systems to specify configuration options, and a new syntax to learn. The proper, consistent, cruft-free and best performing Drupal solution is to use a _hook that returns an array ...

I'm giving this a tentative -1, although I might just take some time getting used to.

Years ago, we also agreed on not providing design credit. We'd have to do the same for modules, which simply isn't feasible or fair in a collaboratively maintained project.

I'm with Steven on both of these topics; when you look at the licenses that have grown up around code vs design, the creator of the design is much more important than the author of code. I think it's ok to give designers credit in a place like this.

And I think if this is a slight change in direction for Drupal, then it is a good one. Respecting design and art needs to become a priority.

As Steven said, the .ini file isn't being used to store settable parameters by the user or admin, but instead being used to store important information specific information to that theme.

Why would we want to know what regions a theme support, or whether it supports a logo, when the theme is not actually enabled? We only need to load the enabled themes, whether they are actually used or not. This seems consistent with the module behavior, and can be accomplished with a regular hook. Why do we want to query that information without enabling the theme? From what I can tell, we're not taking advantage of it, at all.

(This patch removes 177 lines of code, but adds 281 lines of new code. So while it removes some code, it adds more -- and not exactly pretty code.)

Dries: Because theme designers are not developers. Every time we can make a theme designer get more with less code, we are making it a little easier for a theme designer to do a good job.

I agree with Steven's comments, I don't think his code is ugly at all, and if you factor out the new parse_ini(), you'll see this patch is really just removing cruft.

Having mytheme.info to say what regions my supports is the same as having forum.module say it depends on taxonomy and comment. Both of those *could* live in the PHP code, but then you have to parse lots of PHP code just to get the simple information you need. Saying theme.info can't support this is supporting the fact that modules shouldn't state dependencies in info files. We already saw Chad Hunmonks code which implemented this in code (about 20 lines worth)...

Now, I am on the fence including the author name of the theme. Generally themes tend to be by one person/designer, where are modules have lots of developers. A theme is kind of built once--then, it doesn't really change, and only small bugs are fixed, if any. It kind of ends.

Because of that, it *could* have an author. Authorship also encourages more users to give back themes--themes tend to be the most propietary thing about a site.

to add more technical weight to why themes should have .info files:

1. the packaging script could tell themes what version they are (just like we do for modules), enabling site admins to actually see what versions of themes they're running. the version info on the modules page is a big hit in 5.x, and we could extend that to the theme page in 6.x. (as a separate patch of course... this issue is just the enabler).
2. update_status could be made to work with themes, alerting sites if their themes are out of date (and of all the security holes in contrib, i'm guessing some of the most horrifying problems are actually in the themes).
3. we could therefore record usage data about different themes, and all the quality metrics stuff we're working towards could cover this other vital aspect of the contributions world.

i'm all in favor of a more powerful ini-like parser that has more reasonable syntax and allows more functionality. in fact, i'm guessing that i'm going to be rammed into using ini-like syntax for the file in install profiles that tells the packaging script what versions of what contribs and themes to include in the tarball for full install profiles. having a better parser in core will make that task easier and better, and make it easier for install profile maintainers to get it right.

yeah, regexps can be a little tricky to read if you're not used to it, but it's not like we're asking every contrib maintainer to write their own. ;) this is 1 function, that most people will never actually look at. there are plenty of us in the core development circle who can make sense of this code. and, as regexp-heavy code goes, this is extremely high quality, easy to follow, well commented, etc. i really don't see what's the big deal.

• Sorry, but I don't like individual credit for themes. This gets thorny down the road when Joe P. Designer has moved on in life, and jane. G. Designer comes along and re-works most of his old code. Then who gets the credit? Ego-stroking imo goes against the collaborative nature of a software project such as Drupal; I actually like the fact that my changes to user.module are indistinguishable from others' changes to user.module apart from careful perusing of commit messages: it shows that we're all collaborating together on making something great, rather than trying to call attention to our individual contributions.
• It strikes me that array syntax is probably very weird for non-PHP coders to grasp. Why not:
  

  [Regions]
  left = Left sidebar
  right = Right sidebar
  
  [Features]
  logo = yes
  site slogan = no
  foo = yes
  bar = yes
  

  The parse_ini docs indicate that this would be parsed into an array. This would both be simple to read/edit for non-technical people, and also retain the parse_ini syntax which Dries is so opposed to losing.

• I personally have never found a huge hairy deal with the parse_ini syntax *except* for quotes in module descriptions and dollar signs in version strings. But I've yet to encounter something that couldn't be solved by double-quoting the string. Maybe I'm just in the minority here.

Oh, more technical reasons to have .info files, per dww's post:

1. It would enable CSS-only themes that work off of the default XHTML generated by core (or a contributed theme, such as Zen). Currently, you need at least a page.tpl.php file, which means PHP coding.
2. We could (potentially) build a little table for each theme in the downloads page so people could find all themes that were 2-column, fixed-width themes. If this didn't happen in project.module on Drupal.org, at least someone could parse this information from contrib and build a nice table.

I'm +1 for .info files. I'm just trying to offer an alternative that might satisfy everyone.

And finally, in the interest of a technical argument vs. an opinion one... I think everyone would universally agree that:

"A fixed-width theme that supports up to three columns."

is a much more useful description than:

"Designed by Foo Bar"

:P

More technical reasons for .info files:

A future patch could (and will, if this or something like this gets in =) allow themes to

1) Specify their stylesheet(s). Why depend on style.css at all?

2) Specify their theme engine. Right now the engine dependency is on page.tpl.php which is obscure.

3) Specify a super theme. Think sub-themes of zen, but without requiring the sub-theme to be in the same directory. In fact, this could be a great way to teach new designers to modify a theme without modifying the original theme. They just set up their theme and .info file to be a sub-theme of whatever, add a style-sheet, and start tweaking.

4) As has been stated before but is worth stating again, we don't want designers to need to know PHP at all. With the .info file, this is a fairly readable, easy to understand file format that lets them work easily.

I'm not sure how I feel about the 'features' part of this; I think I'd like to let it go into this patch and rethink the entire concept of theme settings/features. It's a little hacked in there.

I agree with webcheck:

[Regions]
left = Left sidebar
right = Right sidebar

Is an easier, more familiar syntax to understand.

Summary of a 10-minute rant with chx:

If ego-stroking is important, add theme authors to MAINTAINERS.txt for their given theme(s). Leave descriptions for functional descriptions, so they match with module descriptions.

ego stroking is very important but I agree -- it has nothing to do on the theme screen. Can you imagine the module screen listing CCK contributors or even just the maintainers? :)

+1 to info files for themes.

+1 to things like regions being defined there. In fact, I might even go as far as suggesting that the info file specify any additional CSS files beyond style.css that the theme uses. With the CSS aggregator in Drupal 5+, zapping those all up at once and aggregating them is faster/easier than futzing around in template.php, especially if you're an HTML/CSS guru instead of a PHP guru. These are things about a theme that the theme author should be responsible for, and theme authors don't necessarily have more than a passing knowledge of PHP. (Maybe we could even specify CSS files to exclude? Now I'm just throwing out things that I know the themers I work with have a hard time with. :-) )

Big +1 to descriptions for themes. I can go either way on the designer credit question.

That said, if we're concerned about the gnarliness or size of a regex parser for our own custom syntax, then I have to ask why we're inventing a syntax? If you're a non-programmer defining a config file, how much difference is there between:

name = Forum
description = Enables threaded discussions about general topics.
dependencies[] = taxonomy
dependencies[] = comment
package = Core - optional
version = VERSION
regions[left] = left sidebar
regions[right] = right sidebar

and

$name = 'Forum';
$description = "Enables threaded discussions about general topics."
$dependencies[] = 'taxonomy';
$dependencies[] = 'comment';
$package = 'Core - optional';
$version = VERSION;
$regions['left'] = 'left sidebar';
$regions['right'] = 'right sidebar';

OK, OK, nasty PHP evil, but parsing that is 5 lines of code instead of over a hundred. It's more expressive, faster to parse, and no more fragile. (Both formats will break if badly formed.) One of the reasons for using ini files in the first place was for simplicity. This .info file is already aiming to be more complex than a module .info file, to the point that we're writing a custom parser for a new language syntax, albeit a small one. Is just using a small PHP file that's almost the same so much of a problem? It's no more complex code than we already require for doing anything interesting with PHPTemplate template files.

+1 to http://drupal.org/node/132018#comment-221536.

@Dries: for example, module.weight is something that does not belong into any hook -- for most modules it would be perfect to be in .info actually. More than once I would actually be happy if I would be able to see what blocks I will get from a module -- it's not like some defaults for hook_block op info can't find a happy home in a .info.

So is theme. Whether a theme supports two sidebars and a logo is not something you can ever change but the user needs to know before she switches it on.

OK, I'm gonna stick my neck out on this thread:

@steven : i hear your frustratoin with the ini syntax limitations - however I'm -1 on making up our own syntax in general ... especially when it's /sorta/ like something that folks are likely already familiar with.

So. Here's an alternative:

http://www.yaml.org/ - it's a text-based, "human readable" format for exactly this kind of config-file scenario. Most folks probably recognize it as the format that rails uses (e.g.) . It also (afaict) supports all of the features that we could need from such files. Plus, it's well defined in an open & public manner.

If we're gonna build custom parsers - let's do it around formats that are out there, open and (potentially) familiar to others coming to the project.

Can I get an amen?

Well, it may be way overkill now. But wait until color3.module when we have to have that other new feature. If we can get some consensus - a yaml.inc would probably only be a couple hundred lines of code - and could be very selectively loaded. And we'd have a well documented info file format (that we could read *and* write). A conversion script from 5.x .info to 6.x .info files should be trivial.

Heck... if you ask nice i'd even write the parser.

How do others feel?

Color me interested in a yaml parser. Or, something close to that. Nested structures, multilines and all supported in a little, 43 line parser. Everything else is comments, testing code, wrapper.

I'm going to go both ways on this patch. Certain ideas are great. But it might be too much all at once.

+1 Theme .info files in general
+1 Attribution for designers. Name recognition is what artists build their career on. Designers typically work individually or with minimal help because it is their individual piece of art. You don't see many paintings, product designs or photographs by more than a single individual. These are the kind of people that make themes and attribution will encourage a thriving theming community.

-1 Custom INI parser. I don't find the syntax any intuitive than the standard format. I also don't know of any languages outside of PHP which use this funky method for appending to arrays ($array[] = 'value'), on which the INI parser is based. If the method webchick describes works for defining arrays we should stick with that. I too haven't found any problems with the current system outside of the quoting.
-1 Defining regions in INI files. Unlike modules, themes are usually downloaded as a starting point. Most end-users will modify a tpl.php file or template.php as necessary to fit their needs. Including regions in INI files means it's another location that end users are going to manipulate whenever necessary.

Maybe these regexps are a bit better -- too many ways to skin a cat, really.

Okay, I'm just going to come out and say this, because this is getting ridiculous: get over it Dries, now. Your insistence of parse_ini_file() in the last patch has caused significant loss of time, and all because you "don't like regexps". Module authors got frustrated with the restrictive syntax, and documentation had to be written to explain how to work around the stupid quote thing. It was stupid, pointless and completely avoidable, as we had a working alternative available then and there. Regular expressions are valid programming tools. They are very compact ways of writing state machines, and are compiled into very fast pieces of code. I'd expect a computer scientist to realize this of all people.

This is ridiculous, and won't go into that.

Anyway, let's focus on the main point here: why are we inventing a new mechanism (our own language), that looks almost exactly PHP? And while it looks like .ini, it isn't even parsable using any of the available .ini parsers.

I'm OK with .info files so we can store a description and a version, but I don't see a problem with having to load enabled themes to extract regions. Most of the time, people have only one theme enabled. Even if you have 5 themes enabled, loading them is not a big deal.

Why do we insist on not having to load the theme? We've never had a problem with that, AFAIK. Why do we insist on having our own language?

Plus, what if I want to make a theme with dynamic regions? What if the theme had a setting where people could pick different layouts (with different regions as a result)?

@quicksketch:

Name recognition is what artists build their career on.

Interesting debate, this one is. What do you think I built my career on if not name recognition?

-1 Custom INI parser. I don't find the syntax any intuitive than the standard format. -- And what about YAML? The array syntax is weird.

-1 Defining regions in INI files. Unlike modules, themes are usually downloaded as a starting point. -- then it will be another theme dependening on the original. This argument does not stand.

Another short conversation with chx in IRC:

No conclusive arguments against YAML. The main problem seems to be dependencies on multiple types of Drupal infrastructure, i.e. both themes and modules.

About designers vs. programmers, the hypothetical situation was posted:

[02:22am] chx: you design something in Photoshop, it's award winning quality
[02:22am] chx: someone comes and makes HTML/CSS out of it
[02:22am] chx: puts this under GPL
[02:22am] chx: some third guy comes and makes a Drupal theme out of it
[02:23am] chx: who's guilty?
...
[02:23am] quicksketch: "Designed by" sounds like the guy that made the photoshop theme
...
[02:24am] quicksketch: there is rarely more than one designer, often more than one programmer
[02:25am] chx: that's the first valid claim i heard
[02:25am] chx: please add this to the issue -- indeed the design itself is very likely to belong to one person

And so the debate can continue :)

Good idea. I'll take a crack at this as time permits. I'd not be able to review as many patches then, but I'm sure others are willing to help with that. Either way, I'd love to experiment with this myself.

subscribe.

Steven is right; given the way phptemplate the theme engine operates, it is currently not possible to load multiple themes from the same theme engine simultaneously. This means you, currently, have to be in the theme you are configuring in order to configure it, which does seem a little odd.

I'm not sure how a theme under our current system could support dynamic regions at all. It's a nice idea, I suppose, but it seems ... less than likely.

I'm on the fence about yaml. I don't find it particularly easy to read. On the other hand, the PHP-style array syntax isn't either, from the perspective of a non-programmer. Is there really no other good way to get nested arrays out of INI style syntax? I guess getting 2 levels deep isn't too bad, but a 3rd level does seem really rough.

Regarding just using PHP, I hadn't considered the security on d.o question. No one brought that up when we were discussing module .info files; they were just "eew, PHP". :-) I'll concede that point.

As for YAML, Big -1. It's a huge and nasty mess. The only system I've toyed with that uses it is Symfony, and it translates it down to XML anyway. YAML is a pointless, less expressive mutant.

But if we want to go that direction... Why not XML? We already have our own XML parser buried in there somewhere, I believe.

<theme name="Garland" version="VERSION" package="Core-optional">
  <description>A pretty Web 2.0-y theme</description>
  <dependency>taxonomy</dependency>
  <dependency>comment</dependency>
  <region name="left">left sidebar</region>
  <region name="right">left sidebar</region>
</theme>

Themers who don't already know rudimentary XML haven't been using HTML lately. It requires no PHP knowledge. It's a well-established format. It's expressive. It's easily extensible for both modules and themes. It's non-executable. We already have a parser for it (that can or should easily swap out to SimpleXML under PHP 5) so the additional code overhead isn't that large.

I guess I'm OK with a semi-ini with custom parser, and I'd prefer that to YAML, but I just hate to go creating our own YAML when there are other options.

The only workarounds I can envision are something like:

[color_set_1]
name = Belgian chocolate
base_color = #d5b048
link_color = #6c420e
header_top = #331900
header_bottom = #971702
text_color = #494949

[color_set_2]
name = Mercury
base_color = #788597
...

I don't know enough about color.module's storage though to know why it needs to be nested and what info would be nested there. It doesn't seem to be in the patch for Garland.

I'm not sure how a theme under our current system could support dynamic regions at all. It's a nice idea, I suppose, but it seems ... less than likely.

It's definitely possible. I have it working in an unpublished copy of my theme but it's a bit of a kludge so it may be removed.

I don't see it as a deal breaker to setting regions in the .info file but if everything else was equal and I had to choose between the two approaches, I'd vote for not using .info for setting regions.

Setting regions may be confusing to some currently but it dwarfs by comparison to all the other factors in getting a theme published.

Sure, that's cool. As I said, I was simply trying to come up with a compromise solution... keeping the original ini syntax that Dries wants along with the .info features that you want. The only other thing we could try is defer the more expressive parser + syntax to the "Make colour module really kick ass" patch, but it sounds like you've made the case for having nesting at this stage anyway.

I'll stfu from now on. :P

Hi Steven

Just tagging along here and think I've missed the use-case for nested arrays. Could you please give an example (or a place to look at one) that is not supported by: arrayname = value1, value2, value3 syntax?

Steven, what about the (pseudo) YAML parser I posted? It supports multidimensional structures just fine.

Steven, would you be able to do what you need to do with color module using just XML? I still think avoiding writing our own new syntax, even if it's a small syntax, is something to strive for. Themers do know how to handle a few nested tags and attributes, or else they won't be able to handle theming Drupal anyway.

Some notes: Steven hopped on IRC to answer me -- my YAML parser is a bit broken and I while do read the issue but really, this was your first reply about my implementation, not a YAML parser in general.

On the other hand, sime, no druplipoints for you, because the answer is right above your followup -- have you read that?

So, the goal is to represent associative arrays in a human-readable construct? Well, [] scares people.

Seems like there are many better options using normal english punctuation and/or layperson's math symbols. Take the following:
regions = left: Left Region; right: Right Region; header: Header Area;

And if it all goes pear-shaped, +1 for Crell's XML suggestion, for flexibility and being standard (if arguably not very readable).

personally, i don't care that much about the specifics of the syntax, i mostly care about having .info files for themes, for all the technical reasons Steven, myself, merlin, and others have all pointed out. It would be tragic if this patch languished in the queue for months and missed the 6.x code freeze because it got hung up in a mostly pointless debate about the specifics of the syntax.

-1 to parse_ini_file() -- it's simply not expressive enough (no nesting) for what we need. end of story.
-1 to XML -- it looks like crap, and is much more painful for humans to read, understand, and manipulate.

that leaves us with UnConeD's version, and chx's tiny YAML-subset parser. so, compare:

UnConeD:

; $Id$
name = Chameleon
description = 3 column, fixed-width, with neutral colors.
designer = Dries Buytaert
regions[left] = Left sidebar
regions[right] = Right sidebar
features[] = logo
features[] = favicon
features[] = name
features[] = slogan

vs.

YAML-lite:

# $Id$
name: Chameleon
description: 3 column, fixed-width, with neutral colors.
designer: Dries Buytaert
regions:
  - left: Left sidebar
  - right: Right sidebar
features:
  - logo
  - favicon
  - name
  - slogan

(assuming that's a valid description of Chameleon -- i've never used it so i have no idea).

personally, i find the later easier to read, but not by much. the underlying parsing code is on the same order of magnitude in size and complexity (again: not very large or complex).

re: design credit. i don't feel too strongly, but my personal preference would be to have it as a separate keyword in the .info file (as my examples show) and then we can display it or not in the admin/build/theme page (or anywhere else) however we see fit. i agree with webchick that having a valid description is useful, so let's just define both. not a reason to hold up this patch -- that particular change should happen as a followup issue, but since we're arguing about it here, i felt compelled to comment.

so, back to reality... can we quickly get some resolution on the (mostly irrelevent) syntax debate, and make progress here again? myself or chx can fix the YAML-lite parser if folks think that's a reasonable alternative. otherwise, let's just commit Steven's original patch, and start to build on top of all the goodness and power that .info files will enable (no sense repeating myself about that here).

thanks,
-derek

p.s. as a slightly bogus example of what the packaging script might automatically append to these .info files to illustrate further nesting in the two syntax options, compare:

signature[md5] = 7552a661dbefc09055af3183197d229d
signature[size][lines] = 2249
signature[size][words] = 10394
signature[size][bytes] = 74208

vs.

signature:
  - md5: 7552a661dbefc09055af3183197d229d
  - size:
    - lines: 2249
    - words: 10394
    - bytes: 74208

For anyone who missed the chx's parser code (ok, I did, the description threw me) see #33.
So now that I've got some clues, IMO:
- .info files are good.
- The YAML-lite format is good.
- "designer credit" discussion is for another time.

Il buono

Because you can change a theme's settings without actually using that theme to view the configuration page. Think administration theme. Forcing a theme's settings to be displayed in that theme would be a stupid step back: that page is a very "adminny" one, with wide content (color.module) and complicated forms (fieldsets with file upload).

I also think forcing the block administration page to be displayed in the theme it is for is silly for the same reason, because there is a giant table in there

This is pure genius. IMO the main reason to see this patch in core... along with CCS only themes.

Il brutto

I realize this is a bit weird at first, as there is no way to specify a theme that has no regions or features, but I don't think anyone will ever need that. It also means existing themes need much less effort to keep working.

This is a little bit scary. What about one column layout? I know I can not print blocks on my page.tpl.php but really there's no way to let themers specify no regions or features?.

Il cattivo
Designer credit: It would be cool but descriptions would be much better and I agree that such a thing doesn't stick with a project like Drupal and if you go with it for designer is a countersense to not have it for coders (who decides that xhtml/Css coding is art and php is not? Themes development is not only photoshop or painting naked girls as coding is not only geekery).

Retracting my complaints to help come to a consensus:
+ I see the benefit to regions in .info files so nix my complaint there.
+ If we're going to have to do a custom INI parser then I like Steven's implementation more than YAML (psuedo or a full implementation). I'm unclear as to whether or not the YAML would require tabs, spaces, or work with both. But given the poor consistency in contrib already, I'd like to avoid the issue altogether and not use indentation based markup. I find Stevens INI easier to read, more familiar, and no one has to worry about spaces vs. tabs when writing it.

I'm for Stevens patch as posted.

I don' t think that this question got answered :

Question, it wasn't clear to me that if you override regions it adds to defaults or replaces.

Does it add or replace ?

Sorry for joining this late, but I cant shy away from my 10 years in design.

1) The discussion here is ridiculous and making it sound like web designers are idiots and unable to follow code patterns. Ask yourselves, if they cope fine with HTML & CSS, don't you think they understand the concept of brackets / parenthesis?
+1 Steven's style code (#4) or XML if it comes down to it. However, I want to see what Dries comes up with first.

2) The result of a session on "Photoshop" or "Painting" are driven by ego. Yes, it's a personal and expressive medium - there's no right or wrong way of doing it and you don't get PHP errors slapping you in the face. Code however, requires following rules - a lot of rules. Please don't mix "Art" or "Graphic Design" with "Web Design". The moment you introduce GPL code (whether HTML or CSS) you open the door to collaboration because of a simple fact: code is poetry. At this point, its grossly unfair to shine the spotlight on theme authors (who will undoubtedly abuse the free ad space) while the real credit should be given to the people who's contrib code runs these sites. No so called "Web Designer" can produce a 100% stable and perfect theme that works on all major browsers, with/without JS, with/without alpha transparency, with fluid/fixed layouts etc straight out of the box. Someone will always step in and find a bug, contribute a patch, and a heap of other scenarios as outlined above by webchick and a few others.
-1 for design credit. Use the space for a brief description as suggested by webchick.

3) I think we should re-evaluate why we created .info for modules and use that same approach to do the .info for themes. We don't want an overly complex system just for the sake of "making it easy for designers". Steven, it seems you're cooking something in private which depends on some aspects of this patch going into core. While I appreciate the energy, don't lose sight of what's absolutely necessary for Drupal as a framework. There's no point introducing something that will not be used by the vast majority e.g. color.module and farbtastic but back on topic,
+1 for including regions in the .info files. But I'm still unclear over it's full advantage, I need to re-read this thread again.

As step #1, we could get .info files for themes that do _exactly_ the same as what .info files for modules do, using the exact same syntax.

Here are three decisions to simplify the discussion:

a. -1 for YAML -- we won't get that in core. It's not consistent with the module .info files, which I think is important.

b. -1 for designer credits. Lot's of people share that opinion, because it is not consistent with the module .info files.

c. -1 for XML -- unless we update the module.info files to use XML too.

What remains:

a. Do we want the .info file to just store metadata, or do we want to use them for programming construct (i.e. to define regions and features)?

b. Depending on the answer to (a), we can argue about the syntax and the parsing.

My view is that we shouldn't define regions in the .info files because it opens a can of worms, and it introduces a new mechanism for dealing with variables, hooks, etc. I don't want to go there ...

The only real argument I saw so far is "designers are not capable of implementing a hook but they can do nested arrays in a .ini file". I think this somewhat exaggerated. Both systems require them to learn something, or to copy-paste something.

I suggest that we go forward with a PHP hook. Then, we can always choose to move the hook to a .ini file later on. Like that, we can start moving forward and get some early feedback from designers. We'd get versions for themes, and we'd be able to track theme updates.

(I still intend to work on this, but I'm currently on vacation.)

@Steven: Finally: I'd like to point out that in spite of this buzz, I've been the only one to actually roll a patch for this issue. Isn't it fun when everyone works together?

Steven, please get off your martyr box. chx and I have been actively trying to help see this thread through to RTBC, and yes, we wrote some code, too, if that's your (ridiculous) criteria to qualify for "working together". No, we didn't completely re-roll the patch, since it would have been a pointless waste of time if the YAML parser isn't going to be the way to go. I used to be actively concerned about how frustrated you're feeling as a result of this and other threads, but now I'm not so sure.

It's easy to feel embattled and bitter if you can't even see, much less appreciate, the help and effort your allies are trying to give you.

@Dries: Steven is absolutely right: whatever format we use for theme .info files would be the same for modules. And, of course, the .info files for install profiles, where people define what other modules to include in the tarball. That part absolutely requires nested meta data, since at the very least, we need a list of dependent modules, each one including an official version string, and most likely, a location in the directory structure where the packagaing script should put it...

p.s. Sorry, I really hate to do this, but this patch includes teaser.js and therefore needs re-rolling...

To clarify my stance:

+1 on regions in the info file, for the reasons Steven stated.
+1 on module info files using the same syntax/parser as theme info files, whatever it ends up being.
-1 on YAML. It's big and ugly and nasty.

The only place where I disagree is that if we need something more expressive than ini syntax, I'd rather use XML than yet another Drupal markup language that we have to write and debug our own parser for. No offense to Steven and his regex skills, but more lines of code = more places where bugs could creep in. XML is quite expressive and for the sort of thing we'd need it for is no more difficult to learn than HTML, but the parser for it already exists. I can accept the pseudo-ini format, but I'd rather just use something more standard.

As for rolling my own patch on this issue, it's of sufficient size that I don't want to redo everything Steven is doing needlessly. That's a waste of both his time and mine. That's why I generally don't try to jump in with big rewrites on large patches until we know exactly what they are going to do.

I know I said I would stfu, but...

It seems to me that this patch is getting held up for the same reason that the new admin interface patch in 5.x got held up for weeks: namely, that it's trying to do too many things at once.

As others have pointed out, .info files already have value just on their own: we can now have useful theme descriptions without enabling every single theme and trying it out, and we can also use versioning info like with modules.

So what if we focus on just getting THAT part of the patch in at this stage? We can move "make theme regions settable in .info files" to a separate patch, and rework the parser there to allow for setting these, if required (else, punt that part until "make color.module kick ass" patch, when nested sets are actually going to be needed).

And in the spirit of collaboration, I tried to make a re-roll with my suggestions, but I got horribly confused... :( The theme system is not something I have any real experience in. :( If no one else gets to it, I can try again Saturday.

Sorry. Didn't mean to change status.

Ok.

My two cents here.

PHPTemplate was originally designed to use .info files for the templates, for specifying features, which engine to use, and which themes they depended on (for style based themes).

This code was also in the first few iterations of the templates patch, back in the day.

All this was REMOVED at Dries' behest, because he didn't want to introduce a text file format (which has _always_ been the simplest, cleanest and most user-friendly way to implement this. always).

That's where the weird template finding mechanism came in, and more weirdness crawled in over time because of Dries' dislike of meta data for modules/themes.

We got regions support, and quite frankly .. the regions support has _always_ been far weaker and more complex than it should have been, because we didn't have the .info files for themes.

This has _always_ been needed, and Dries has always not liked it, and it took considerable effort and time to get Dries to even consent to having .info files for modules , the same way it took forever to get him to consent to modules in their own directories. Both of these have been really important into getting the system into a more easily maintainable state.

Beyond that, PHPTemplate and the entire theme system, is _designed_ from the ground up , to only ever have one theme loaded at any one time. It is _impossible_ to configure this to work in any other way. Template.php is _never_ loaded unless it's the actual theme you are looking at.

A lot of the time it is _impossible_ to load more than one template.php file at the same time, because you get namespace conflicts.

Using the theme name namespace inside the template.php file is a kludge, and breaks copyability of the templates. Template.php and the phptemplate_ namespace were created precisely for the reason of allowing templates to be easily copied, without having to modify files.

The features also don't work for phptemplate based themes. Because once again, template.php is, and can, only be loaded if you are viewing that specific theme.

This means that regions and features have been broken this entire time, because Dries didn't want us to implement the simplest , cleanest and friendliest mechanism for doing this. I still don't understand his reasons for not wanting this meta-data be more easily accessible and editable for the very people who need that accessibility the most (designers).

This has a big +1 in my book.

I'm pretty new to drupal development, but I've been following this thread closely.

It sounds to me like everyone agrees that .info files are needed for themes. On that basis, you should stop arguing about what other features can be added at the same time and concentrate on getting the simplest update incorporated. The .info files used for modules are ok for most people, so if you use the same format, then you have a very worthwhile update that could be incorporated into core now... IMO.

That will at least give people a chance to try it out and have a good think about what other information is required (or not) in the .info files.

While I'm here, I don't know a huge amount about the ini format, but surely it could be made multi-level by simple specifying a parent:

[signature]
md5 = 7552a661dbefc09055af3183197d229d

[size]
parent = signature
lines = 2249
words = 10394
bytes = 74208

This keeps the ini format that Dries wants and also allows nesting. Please correct me if I'm wrong :)

I've watched this entire conversation. The primary objection appears to be that the [] syntax is awkward.

I basically agree, but I feel it's acceptable. It's not ideal, but I don't think anything is. I think there is a proven need for it; I completely agree with Steven that region and feature info (among other things) should be in the .info file.

I believe this patch should be committed.

I do also think that there is no "perfect" format for this kind of metadata files. It's basically a matter of personal preference, IMO, One likes yaml because it uses : instead of =, the other one prefers xml over anything, etc.
I don't think it's worth to discuss this endlessly.

I'd just commit steven's patch. It has the needed functionality, and it provides an acceptable format for the info files. And this is what IMO is important, to have a more powerful format for info files and to have info files for themes.

To be honest, the only little thing that looks really weird in this format is the way numeric arrays are noted, e.g.:

dependencies[] = comment
dependencies[] = taxonomy
dependencies[] = menu

So, what I propose is to use Steven's format, but to introduce one change to the regex to allow comma-seperated lists as a simple way to note numeric arrays, e.g.
dependencies = comment, taxonomy, menu
or
features = logo, favicon, name, "a feature, with a comma in it"
If a normal value has a comma in it, it would have to be surrounded by quotes, which I think is acceptable.

This would combine the ease of use for simple notations (e.g. for dependencies and features) and Steven's great and powerful way to note nested arrays.

adrian: not quite sure what point you are trying to make -- we _all_ agree that we need .info files for themes, we trying to decide on the format. Your comment reads much like an anti-Dries rant that adds very little to the discussion. Bleh.

Steven: feel free to ignore my feedback, to know it better, and to commit this patch. I was looking forward to work on this (as soon I had some time) but not anymore. I'm done with this issue, as it only helps spread your bitterness.

Dries: Unfortunately for us, Steven has already expressed that he feels he cannot commit his own patch. So that leaves us in kind of an awkward position, where the one thing we absolutely don't want -- .info files not getting committed at all -- becomes the most likely scenario.

merlin: I'd be happy to test and commit the patch when Steven marks it RTBC. I'm not going to make any decisions though -- I leave that up to Steven and the rest of the community.

Only two comments:
* .info files should use the same format / syntax between modules and themes
* it sucks to be creating "Yet Another Drupalism" in a format, but it doesn't look like there are "standards" in this area, it needs to be cut and paste simple for themers, and XML is overkill

Based on Dries' last comment, I see it as up to the rest of us to get consensus with Steven on the format (we're close...let's look at rationalizing with module .info files), he'll RTBC when that's done, and Dries will press the magic commit button.

This patch uses the same format for module files as theme files. So that part's taken care of.

Well, I might have overlooked something but the original did not work at all: system.install lacked a few crucial changes, like changing description to owner and adding info in the original install not just the update. Also Garland info was not loaded and that provoked some errors. All this is now fixed and to me it looked like working.

I just want to publicly apologize for the last comment I made.

It was hurtful, and far angrier in tone than I ever intended to have it sound. I need to learn to not post when I am sleep deprived, but that's still no excuse.

I'm sorry.

1. I love *.info files. The directory structures in Drupal 5 are simple and clean.

2. Because of this proposal, are we going to end up with *.info files in two separate syntaxes? Because that would be bad.

3. My $0.02: Use XML for the syntax of all *info files.

(a) If people, designers especially, can understand HTML, they can understand XML.

(b) With XML you get validation, which will become more important if (when!) the complexity of metadata increases and the need to debug info files increased. (You get validation only with a schema, but RelaxNG has a simple and easy syntax, unlike the bloated and monstrous W3C schema syntax.)

(c) If you want processing of the *.info files, whether for display or transmission, then there are lots of tools available in the XML world; XSLT besides CSS, for example.

In general, it seems to me that *.info files are all about being declarative (whereas *.module files are all about being procedural). Technically and culturally, that is what the XML world is all about.

If anybody seconds the motion, I'd be happy to work with them on this.

NOTE +1 on putting designers names in MAINTAINERS.txt, as webchick suggests. Yes, egoboost is important, as is a portfolio, but if the designer isn't willing to maintain the design...

@shunting: please read the comments carefully before posting.

1. for the Nth time: themes and modules will have the same format whenever this patch is committed.
2. XML has already been ruled out by numerous replies above: it's too heavy-weight, and harder for humans to read and manipulate.

the *only* open question at this point is Steven's modified .ini syntax or chx's "YAML-lite". now that chx has a working version of the Steven-syntax that includes a proper upgrade path, etc, we could just commit that and put this thread out of its misery... i'd mark it RTBC, in fact, but i need to do more testing of the latest patch before i'd do that. i'd also like to write some mockup .info files for install profiles, and see how easy/hard it is to express what we need in the 2 syntaxes.

dww: actually, YAML-lite was ruled out, XML was not.

I tried to sift through the evidence now, but this thread became far too long in the meantime. Maybe someone can write up a summarisation of the things that are still in question.

However, like dww partially suggested and like webchick already mentioned, we can shorten the procedure by implementing .info files for themes with the same syntax of .info files for modules. It might not be possible to define regions (associative arrays in general) this way, but we'll have a solid basis for further improvements that we can discuss afterwards.

The current syntax of module .info files is able to provide a title, description, dependencies, features and a version for themes. That's great and f.e. allows site admins to get informed when there is a new release of a theme if the Update status or Release monitor module is installed.

So:
+1 for .info files for themes
-1 for a different syntax than module .info file syntax
+1 for moving the discussion about a new syntax suitable for modules and themes to a new issue

Q: Why are regions defined as associative arrays at all? Just because to have a region name with spaces in admin/build/block ? Sounds like overkill. I don't need 'beautiful region names' there and if someone needs them, don't forget we still have t().

@sun: Here's my summary of the status here.

- Themes need .info files. All are agreed.
- Theme .info files and module .info files should/will use the same format, whatever it is. If install profiles ever get .info files, they'll also use the same format. All are agreed.
- "Credit" info probably shouldn't be in info files, but for now that's punted to later.
- The format, whatever it is, needs to support more than simple key-value pairs. It needs to potentially support more than 2-level arrays (which basic ini will do) so that we can expand to fancier stuff without having to change the format yet again later.
- For themes, regions should be defined in the info file. I think we've settled on this at this point.

As far as the format goes, there are two remaining options on the table:

- Custom pseudo-ini. This would be parsed by Steven's regex parser (in the patch somewhere) and would look like a hybrid between ini files and PHP array syntax. Pro: Very simple. Con: Requires yet another custom parser, and if we tweak the format later it may require changing the parser, too.

- XML. This would be parsed using our existing XML parsing utilities, or probably SimpleXML in PHP 5. Pro: No need for a new parser, well-known extensible syntax. Con: XML is verbose.

Personally, I favor XML. I really don't buy the "XML is too confusing" argument. I'm not talking about some complex system with namespaces. I'm talking about a simple 5-line file. There's probably not even a reason to have a formal validator or DTD/Schema for it. Our themers can handle XML files. If they can't handle 5 lines of XML, then they're already going to be horribly lost the first time they open up page.tpl.php.

I think the format question is the only outstanding technical issue, emotional questions aside.

I do not see a reason for CNW.

Second. -1 for XML, as big -1 as I am entitled to. It's nor human readable nor human writeable. And that's a problem.

I do not see a reason for CNW.

Second. -1 for XML, as big -1 as I am entitled to. It's nor human readable nor human writeable. And that's a problem.

So I just did an informal survey around the office. The sample group includes 1 programmer with about 4 weeks Drupal experience, 1 themer with about 6 months Drupal experience, and 2 themers with about 4 weeks Drupal experience.

- The programmer favored XML on the grounds that it was easier to parse.
- The more experienced themer favored XML on the grounds that it was not yet another markup to learn.
- One of the less experienced themers favored XML on the grounds that it was easier to understand since she was used to HTML, but felt she could easily pick up either one.
- The other less experienced themer favored the pseudo-ini syntax, on the grounds that with XML he always gets worried because he doesn't know the meaning of each tag the way he does with HTML (since HTML is a specific DTD that he's worked with for years). He also stated that the most important thing is to keep the syntax expectations throughout different parts of Drupal consistent so that the system as a whole was easier to learn. With "sufficient, clear, unambiguous documentation of the spec" he felt he could overcome his "XML ph34r" (his words :-) ).

So I just did an informal survey around the office. The sample group includes 1 programmer with about 4 weeks Drupal experience, 1 themer with about 6 months Drupal experience, and 2 themers with about 4 weeks Drupal experience.

- The programmer favored XML on the grounds that it was easier to parse.
- The more experienced themer favored XML on the grounds that it was not yet another markup to learn.
- One of the less experienced themers favored XML on the grounds that it was easier to understand since she was used to HTML, but felt she could easily pick up either one.
- The other less experienced themer favored the pseudo-ini syntax, on the grounds that with XML he always gets worried because he doesn't know the meaning of each tag the way he does with HTML (since HTML is a specific DTD that he's worked with for years). He also stated that the most important thing is to keep the syntax expectations throughout different parts of Drupal consistent so that the system as a whole was easier to learn. With "sufficient, clear, unambiguous documentation of the spec" he felt he could overcome his "XML ph34r" (his words :-) ).

(Sorry, d.o 500ed in the middle of posting.)

I just did an informal survey around the office. The sample group includes 1 programmer with about 4 weeks Drupal experience, 1 themer with about 6 months Drupal experience, and 2 themers with about 4 weeks Drupal experience.

- The programmer favored XML on the grounds that it was easier to parse.
- The more experienced themer favored XML on the grounds that it was not yet another markup to learn.
- One of the less experienced themers favored XML on the grounds that it was easier to understand since she was used to HTML, but felt she could easily pick up either one.
- The other less experienced themer favored the pseudo-ini syntax, on the grounds that with XML he always gets worried because he doesn't know the meaning of each tag the way he does with HTML (since HTML is a specific DTD that he's worked with for years). He also stated that the most important thing is to keep the syntax expectations throughout different parts of Drupal consistent so that the system as a whole was easier to learn. With "sufficient, clear, unambiguous documentation of the spec" he felt he could overcome his "XML ph34r" (his words :-) ).

(Sorry, d.o 500ed in the middle of posting.)

I just did an informal survey around the office. The sample group includes 1 programmer with about 4 weeks Drupal experience, 1 themer with about 6 months Drupal experience, and 2 themers with about 4 weeks Drupal experience.

- The programmer favored XML on the grounds that it was easier to parse.
- The more experienced themer favored XML on the grounds that it was not yet another markup to learn.
- One of the less experienced themers favored XML on the grounds that it was easier to understand since she was used to HTML, but felt she could easily pick up either one.
- The other less experienced themer favored the pseudo-ini syntax, on the grounds that with XML he always gets worried because he doesn't know the meaning of each tag the way he does with HTML (since HTML is a specific DTD that he's worked with for years). He also stated that the most important thing is to keep the syntax expectations throughout different parts of Drupal consistent so that the system as a whole was easier to learn. With "sufficient, clear, unambiguous documentation of the spec" he felt he could overcome his "XML ph34r" (his words :-) ).

Eeek! Sorry folks. I didn't see that my original post had gone through at all. Didn't mean to spam the thread. :-(

@chx: Are you saying that the snippet in #41 is neither human readable nor human writable? page.tpl.php is more complex than that. No funky namespaces or anything, just something simple.

after extensive review and testing, chx's patch in #75 (http://drupal.org/files/issues/info_2.patch) is definitely RTBC.

final word on syntax: Steven's pseudo-ini is the only reasonable alternative at this point. neither Dries nor Steven likes the YAML-lite. Steven, chx, and many others have all but vetoed XML. in addition to it being harder for humans to read and generate, there are a few lingering technical problems with XML:

1. in spite of the fact people think we do or should have an XML parser in core, we don't. so, we'd have to write it, and that sucks, especially in php4. since no one's written a patch for this issue that includes XML support, so there's no patch to compare against, nothing to test, review, etc.
2. XML introduces a nasty ambiguity in the .info files: should nested values be nested attributes, or tags on the parent attribute? for example:
   

   <includes>
    <include>
     <name>drupal</name>
     <tag>DRUPAL-5-1</tag>
     <from>drupal</from>
     <to>drupal</to>
    </include>
   ...
   </includes>
   

   vs.

   <includes>
    <include name = "drupal" tag = "DRUPAL-5-1" from = "drupal" to = "drupal" />
    ...
   </includes>
   

   it's lame we even have to think about that.

for comparison, here's the (unambiguous) way to specify the above info in the pseudo-ini:

includes[drupal][tag] = DRUPAL-5-1
includes[drupal][from] = drupal
includes[drupal][to] = drupal

as proof, i'm attaching a draft .info file for an install profile that tells the packaging script what else to include in the tarball. this is NOT for debate in this issue, i'm just using it as a concrete example of the sorts of things install profiles will need in their .info files (or perhaps, even, a .pkg file or something). did i mention you're not supposed to discuss the details of these files in this issue? ;) all i'm asking is for you to look at the version attached here (pseudo-ini) and compare it to the version i'm attaching in my next followup. everyone who thinks XML "isn't that bad" should be reasonably convinced by the evidence.

so, after much ado... i'm calling Steven and chx's effort in #75 hereby RTBC. let's stop quibbling over the syntax and resume progress on all the great things that can be built once theme files have .info files (many of which were already included in Steven's initial patch), and all .info files have a more expressive syntax that allows nested data.

thanks,
-derek

for comparison, here's an XML equivalent of the same nested data.

oh, and for fun/comparison, here's the YAML-lite equivalent. ;)

dww's XML example file is ugly, yes, because it's horribly structured. :-) Attributes exist for a reason and in any sane XML format they are used appropriately.

However, I thought we had an XML parser in the XML-RPC library somewhere. If I am mistaken, then that does limit our ability to use XML as long as we're on PHP 4. (In PHP 5, parsing small XML files like that is so trivially easy it's not even funny.) We could write one for whatever format we choose, but it wouldn't be as simple as in PHP 5.

Since we can't, yet, jettison PHP 4, that means we'd need a custom parser either way. While I still don't like the idea of YADSL (Yet Another Drupal Specific Language), I will grant that Steven's regex parser is likely smaller than any PHP 4 XML parser we could write. That makes the technical details of one format over the other largely a wash.

I will therefore grudgingly withdraw my objections to pseudo-ini for now and give this a +1 as well.

that's part of my point: the fact that you can write the same thing many different ways in XML is yet another good reason not to use it. either we'd have to have a complete parser and allow for wild variation in the .info files, or we'd have to mandate a rigid set of attributes and tags that are expected (and there goes at least half of the argument in favor of XML -- people are already familiar and they don't have to read docs for and understand Yet Another Drupalism).

so, in fairness, here's a "nice" version in XML -- full of attributes to save space. much fewer lines, but not really any more readable for the humans... and, again, the fact you could do it either way (or a combination of both) is itself another strike against XML in my book.

@dww you're really not being fair, I've attached a well formatted ini-like file, that should parse correctly, and of course is very readable.

I find xml, clear, albeit not compact, but really, storage is cheap these days, and xml offers lots more flexibility if you decide to include more information in the .info files. Yes, there is more than one way to describe the data in the file, but generally only a few sensible ways, and we can provide a schema and validation of the files, as well as good documentation of course.

Here's an xml version, I've changed the tags to be more descriptive (after all we're supposed to be describing the required data) and added the ability to provide mirrors for includes.

I really don't see what is unclear about xml, you can make it clear

Personally, I think XML is the proper, de-facto standard mechanism to describe things like this. It's specifically designed for this kind of purpose, and it provides all the features we might need (i.e. support for different character encodings, proper validation with programmer/designer-friendly parse errors). In the long term, it feels like the better option. (I don't think dww's examples are fair -- they explore the extreme formats.)

The data in the module's info files is only needed on certain admin pages and the .info files are not parsed on each request. The themes' info files contain actual variables rather than metadata, and are needed on each page request. (It's the main reason why I prefer to stick with hooks that are queried on the fly. It avoids the need to store serialized data structures in MySQL tables.) Anyway, one thing that's missing is a quick performance test. What's the performance impact of this patch? I assume it's small, because the parsed data gets cached, but I'd like to double-check.

Last but not least, I still wonder how I could do a theme with configurable regions. Say I want to make a theme that offers a configuration option to put two side bars on the right, rather than one sidebar on the left and one sidebar on the right. Just like we have a color picker to dynamically change a theme's colors, I'd love to have configurable regions. It's not clear (yet) how this interfers with this patch ...

(Just to clarify -- I'm not saying that we need to use XML before this patch can get committed. I leave that up to Steven to decide. The only thing that I absolutely want to see happen is a quick performance test. Not necessarily to hold up the patch, but to understand its ramifications on performance.)

I've tried to come up with a direct comparison of both formats using a real world example. The only thing I've added is a certain version dependency for the taxonomy module. However, since I'm not very familiar with XML I could have made some mistakes.

Although I favour the INI style, I have to follow Dries' comment on standards. Joomla f.e. uses XML files for each and every extension in the system, too.

that's part of my point: the fact that you can write the same thing many different ways in XML is yet another good reason not to use it.

Wow. It really surprises me that nearly a decade after XML was introduced, and with Drupal using XML for its output already (XHTML, folks!) there are still developers who don't understand it yet bash it. Of course, any XML format we use would be strict. Allowing people to specify a dependency (for instance) in multiple ways would be completely moronic. We'd just have to figure out if a given field should be an attribute or an element and design accordingly.

Dries is right, XML is ideally suited to this sort of thing. The "it's too hard for themers" argument I don't buy, even moreso after talking to the themers I work with. The only reason against it, really, is that XML parsing in PHP 4 is ugly, code-wise, and with themes we would have to parse one .info file per page load (unless that information is cached somewhere, in which case the parsing performance doesn't really matter.) In PHP 5 it would be a no-brainer decision, but in PHP 4 it actually requires effort.

@ Dries, the problem with benchmarking it is that writing a PHP4-friendly parser for such a format is a non-small task, so it's a lot of work to ask "just to see". Would you be open to caching the data in an SQL table to avoid the parse on each page load, thus making the performance question largely moot?

Dries is asking for benchmarking of the .ini version, just to see about the costs of getting the theme region/feature info from the cached .info data, instead of a php hook. he's not asking about the relative speeds of the different parsers (which is pointless, since it's all cached, either way).

I don't want to get in a shouting match over who does/doesn't understand XML, so I'll just pretend I didn't hear that. ;)

@darthsteven re: #96 "and added the ability to provide mirrors for includes." -- you can do exactly the same thing in pseudo-ini, too. either way, the packaging script has to be changed to look for this data in the parsed array and act accordingly. XML doesn't make this possible where it's impossible in pseudo-ini, so that's just a red herring argument that doesn't help anyone understand the debate...

OK, I have been following this issue and thought I would jump in with my take on things.
I strongly agree that we need .info files and that we should be able to have nested data structures, and of course that all .info files should share the same format.

For readability and long-term usage/elegance I personally find both XML or YAML significantly better than a custom Drupal/ini format (looking at the code in #99 as an example). I understand that XML would mean writing/adapting a parser, which would be a significant chunk of work (although one that we could reuse in quite a few places) and would be best pushed into another patch. The YAML parser can be quite simple though IMO, especially if we start off with a subset of the spec.

That said, I could live with the custom ini format for now, but personally I would be happier is we used a proven, validate-able, locale-freindly format.

i dont understand why drupal doesnt have a dynamically generated theme functionality? combining functionality of panels and making a small module to create dynamic panels will solve all of that for us, ofcourse it would require heavy custom cssing but thats already part of the deal anyway.

i understand the need for info files for hardcoded themes, but i dont see why drupal cant have dynamically generated themes.

i hope the idea is easily understood

And...
Here are the benchmarks:

Before:

Concurrency Level:      10
Time taken for tests:   0.425 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1001
Total transferred:      705705 bytes
HTML transferred:       362362 bytes
Requests per second:    2352.94 [#/sec] (mean)
Time per request:       4.25 [ms] (mean)
Time per request:       0.43 [ms] (mean, across all concurrent requests)
Transfer rate:          1660.48 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.4      0     4
Processing:     1     3    1.7      3    44
Waiting:        0     3    1.7      3    43
Total:          1     4    1.8      3    44

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      4
  75%      4
  80%      4
  90%      5
  95%      6
  98%      7
  99%      8
 100%     44 (last request)

After:

Concurrency Level:      10
Time taken for tests:   0.429 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Non-2xx responses:      1005
Total transferred:      708525 bytes
HTML transferred:       363810 bytes
Requests per second:    2331.00 [#/sec] (mean)
Time per request:       4.29 [ms] (mean)
Time per request:       0.43 [ms] (mean, across all concurrent requests)
Transfer rate:          1651.57 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.3      0     3
Processing:     0     3    5.8      3   131
Waiting:        0     3    5.9      3   131
Total:          0     4    5.8      3   131

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      4
  80%      4
  90%      5
  95%      6
  98%      7
  99%      8
 100%    131 (last request)

These benches are wrong, dmitri will ship better ones later.

Ahoy, cap'tn, coming right up

Proper benchmarks:

Before

Concurrency Level:      10
Time taken for tests:   167.574 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Total transferred:      14581000 bytes
HTML transferred:       14085000 bytes
Requests per second:    5.97 [#/sec] (mean)
Time per request:       1675.74 [ms] (mean)
Time per request:       167.57 [ms] (mean, across all concurrent requests)
Transfer rate:          87.01 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    1.3      0    15
Processing:   197  1669 1556.9   1523 19432
Waiting:      197  1669 1556.6   1523 19431
Total:        197  1669 1558.0   1523 19447

Percentage of the requests served within a certain time (ms)
  50%   1523
  66%   1579
  75%   1616
  80%   1643
  90%   1735
  95%   1817
  98%   2369
  99%   6653
 100%  19447 (last request)

After

Concurrency Level:      10
Time taken for tests:   151.255 seconds
Complete requests:      1000
Failed requests:        0
Broken pipe errors:     0
Total transferred:      14581000 bytes
HTML transferred:       14085000 bytes
Requests per second:    6.61 [#/sec] (mean)
Time per request:       1512.55 [ms] (mean)
Time per request:       151.26 [ms] (mean, across all concurrent requests)
Transfer rate:          96.40 [Kbytes/sec] received

Connnection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0     0    0.0      0     0
Processing:   492  1504  213.7   1522  2351
Waiting:      492  1504  213.7   1522  2351
Total:        492  1504  213.7   1522  2351

Percentage of the requests served within a certain time (ms)
  50%   1522
  66%   1558
  75%   1584
  80%   1611
  90%   1673
  95%   1752
  98%   1945
  99%   2088
 100%   2351 (last request)

I will redo the benchmarks

I agree that we can with .ini files for now, and convert to XML if necessary in future. It's a slightly dangerous path though, as we'll be tempted to tack on stuff to the .ini file parser to do things that XML can already do.

Let me know when this is ready to be committed. I'm waiting for a final go from Steven ...

Ok, let's just wait for the final benchmark results then.

Please, don't miss to add a tag for an update URL of Themes... for me i cannot upload my 20 themes to drupal.org, while they are all released under a Creative Common License. I cannot change this to GPL, but i'd like to have the version included in update_status module and update_status module should be able to check more then only Drupal.org for theme updates.

@hass: Let's get the info file support in first, then we can talk about adding other features to it in separate issues that haven't already ballooned crazy-long. (I already have one or two I want to add as well, but that's for a separate issue and doesn't belong here.)

@hass: good point, but this is actually the wrong thread. ;) all of the update_status, packaging script support, and project XML-RPC stuff is handled separately from core. this issue is simply the enabler. once there are .info files for themes, the packaging script will have somewhere to put this additional data, which update_status can then use to tell you if your themes are out of date. all along, the design goal for the project* and update_status functionality is that it could be made to work with sites other than drupal.org (though the current (initial) implementation of update_status doesn't really have support for that yet, though the project* stuff can be run on other sites). so, to get what you want, you need:

1. this issue to be committed so we *have* .info files for themes at all
2. to setup project and project_release module on your own site, and manage versions/releases of your themes with that
3. to get some features added to update_status.module to better handle querying multiple sites for updates

hope that makes sense.

No lose, no gain, as expected.

And, of course, the rerolled patch.

@chx: why are you deleting this line from CHANGELOG.txt? are your local files not in sync with CVS?

- Language dependent path aliases.

@hass: the patch doesn't delete the line

1. Patch broke because of http://drupal.org/node/118660 -- needs simple re-roll.

2. Waiting for performance data.

ups, you are right... so much minus inside :-)

@Dries, chx posted performance data in #117. No noticeable change.

Huh? Patch applies here with an offset. Anyways I rerolled.

Ps. I begin to understand Steven. How come noone who can't close his trap in his issue even tried to reroll the patch?

Committed to CVS HEAD. Thanks all! =)

Marking this 'code needs work' until the documentation and upgrade instructions have been taken care of.

yay!! thanks Steven, chx and Dries. given my "inability to keep my trap shut" on this issue (to paraphrase chx's elloquent and encouraging words), i'll put my verbosity to good use and take an initial stab at the upgrade docs. ;) stay tuned.

• http://drupal.org/node/114774#info is done (module update docs)
• http://drupal.org/node/132442#info is done (theme update docs), since it's only a stub pointing to...
• http://drupal.org/node/137062 ("Writing .info files for themes (Drupal 6.x)") is started, but still needs lovin'.
• http://drupal.org/node/101009 ("Writing .info files (Drupal 5.x)") needs an update, but not sure how we want to handle it. at the very least, when we discuss dependencies in there, we could have 2 parts, one for 5.x and one for 6.x. or, we could make a whole new version of that page that's specific to 6.x...

in fact, i think we might need a minor overhaul of .info-related documentation, since it's currently a little scattered. to that end, i just submitted a documentation issue about this, so we can move discussion to a more appropriate place: http://drupal.org/node/137069

so, the only thing that definitely still needs to happen is someone more familiar with theming and the implications of regions and features and all that stuff living in .info files needs to take 10 minutes to flesh out http://drupal.org/node/137062 in a little more detail. everything else is either done, or in progress in a more appropriate channel.

cheers,
-derek

I tried accessing admin/help/node with recent HEAD and got Fatal error call to undefined function _module_parse_info_file(), I traced the problem back to this issue. Seems that a few calls weren't replaced by drupal_parse_info_file(). I made a grep and found another occurrence in system.module.

Good catch. Committed to CVS HEAD. Thanks.