4.8/5.0: Modules, the install system, and directories
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further. * Modules get their own directory. (modules/system/system.module). * All modules get own .install (modules/comments/comment.install). This way, all the relevant tables of a module are "closest" to the source, and won't actually get thrown into the db until someone enables them (I hate the fact that I've got about 15 tables I'm not using in my Drupal database. Just drives me nuts.) This also helps update.php in that it will only need to go through ENABLED modules, instead of performing updates for unused tables. We can also pre-create/publish nid 1 in modules/node/node.install without having that dummy hardcoded text, a long standing issue. * databases/ directory is removed entirely. By giving each module their own .install, we don't really need databases/ anymore - we'd just need to, at first run, check if table system exists. If not, find all required modules and run their .install. This way, we remove the entire schema creation step of the INSTALL. All the existing updates.inc would move into system.install. This is nice, IMO, because it'll make a purdy friendly installer a lot easier to create (as it'd just have to send to the frontpage after DB config/QA instead of sucking in databases.mysql). * Modules get an activate, deactivate, and uninstall hook. I think Merlin was working on this to some degree. Activate enables the module, deactivate disables it, but keeps the created data, prefs, and tables in place, and uninstall removes everything. This mimicks the operation of Gallery 2 modules - the uninstall part is awesome! If I use search.module for a week on my 5000+ node site, then find out it's just not good enough, I don't want those gigantic tables hanging around forever, taking up backup space. If I uninstall search.module, those tables and data should be removed. * .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?) * By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files. I coulda swore I had more in the shower, but I've to go to work now. -- Morbus Iff ( accept no prostitutes ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
* .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?)
I'm not sure what you're asking for here. Currently, after hook_install is called, the schema version is set to the greatest current schema update. I.e. if you've got a module_update_5 in the .install file, then the schema will be set to 5. So you don't get any updates you don't need. andrew
* .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?)
I'm not sure what you're asking for here. Currently, after hook_install is called, the schema version is set to the greatest current schema update. I.e. if you've got a module_update_5 in the .install file, then the schema will be set to 5. So you don't get any updates you don't need.
Ah! I didn't know that. Scratch that bullet then. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further.
* Modules get their own directory. (modules/system/system.module).
Sounds reasonable to me. I think certain things get a little messy but it does help the install system and it becomes a lot easier for modules to dump less-used functions off into *.inc files.
* All modules get own .install (modules/comments/comment.install). This way, all the relevant tables of a module are "closest" to the source, and won't actually get thrown into the db until someone enables them (I hate the fact that I've got about 15 tables I'm not using in my Drupal database. Just drives me nuts.) This also helps update.php in that it will only need to go through ENABLED modules, instead of performing updates for unused tables. We can also pre-create/publish nid 1 in modules/node/node.install without having that dummy hardcoded text, a long standing issue.
I think this is a good idea.
* databases/ directory is removed entirely. By giving each module their own .install, we don't really need databases/ anymore - we'd just need to, at first run, check if table system exists. If not, find all required modules and run their .install. This way, we remove the entire schema creation step of the INSTALL. All the existing updates.inc would move into system.install. This is nice, IMO, because it'll make a purdy friendly installer a lot easier to create (as it'd just have to send to the frontpage after DB config/QA instead of sucking in databases.mysql).
This also makes a lot of sense.
* Modules get an activate, deactivate, and uninstall hook. I think Merlin was working on this to some degree. Activate enables the module, deactivate disables it, but keeps the created data, prefs, and tables in place, and uninstall removes everything. This mimicks the operation of Gallery 2 modules - the uninstall part is awesome! If I use search.module for a week on my 5000+ node site, then find out it's just not good enough, I don't want those gigantic tables hanging around forever, taking up backup space. If I uninstall search.module, those tables and data should be removed.
I particularly like this combination.
* .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?)
This is probably unnecessary as has already been said.
* By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files.
The one thing missing is that modules should be able to declare what other modules need to be enabled. I think I agree with Steven's basic premise that we don't want to auto-activate modules unless the operator says it's ok, so in my ideal world I'd come back with a list of modules that need to be activated and say "activate all these modules too?" kind of like yum does. I assume apt does roughly the same thing.
The one thing missing is that modules should be able to declare what other modules need to be enabled. I think I agree with Steven's basic premise that we don't want to auto-activate modules unless the operator says it's ok, so in my ideal world I'd come back with a list of modules that need to be activated and say "activate all these modules too?" kind of like yum does. I assume apt does roughly the same thing.
I think that's too much workflow: * user clicks checkbox. * user clicks submit. * user gets message listing pre-reqs. * user clicks all pre-reqs. * user clicks submit. * user gets more pre-req messages. I'd much rather see the pre-req's listed in the description: name | description (requires: comments) | [] [] Then when the user clicks the box, we *can* enable the pre-reqs without further user intervention, because we can assume he saw the required components part of the description, and still wants to continue. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Morbus Iff wrote:
The one thing missing is that modules should be able to declare what other modules need to be enabled. I think I agree with Steven's basic premise that we don't want to auto-activate modules unless the operator says it's ok, so in my ideal world I'd come back with a list of modules that need to be activated and say "activate all these modules too?" kind of like yum does. I assume apt does roughly the same thing.
I think that's too much workflow:
* user clicks checkbox. * user clicks submit. * user gets message listing pre-reqs. * user clicks all pre-reqs. * user clicks submit. * user gets more pre-req messages.
I'd much rather see the pre-req's listed in the description:
name | description (requires: comments) | [] []
Well that's nice when the dependencies are simple and it's certainly the minimum functionality. But if you have what you said, and then also have the workflow listed above the only difference is that instead of coming back saying "I can't enable this" it comes back saying "I can't enable this unless you enable these things too" and gives you options. (Also, why make the user check things? It's either yes or no.)
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
The one thing missing is that modules should be able to declare what other modules need to be enabled. I think I agree with Steven's basic premise that we don't want to auto-activate modules unless the operator says it's ok, so in my ideal world I'd come back with a list of modules that need to be activated and say "activate all these modules too?" kind of like yum does. I assume apt does roughly the same thing.
I think that's too much workflow:
* user clicks checkbox. * user clicks submit. * user gets message listing pre-reqs. * user clicks all pre-reqs. * user clicks submit. * user gets more pre-req messages.
I'd much rather see the pre-req's listed in the description:
name | description (requires: comments) | [] []
Then when the user clicks the box, we *can* enable the pre-reqs without further user intervention, because we can assume he saw the required components part of the description, and still wants to continue.
That is actually more of how yum/apt solve the problem (for those familiar with the analogy). User: command to install package X System: recursively check dependencies and dependencies of dependencies, and list any packages that need to be installed to satisfy dependencies with a "y/n" option to the user to install those packages - it also checks that the version numbers are correct in each of the dependencies. User: says "y/n" System: do stuff I'm not sure if Drupal needs the whole version number system. In the case of yum and firefox (two other packages I'm familiar with that make heavy use of external "modules") they both track API compatability and provide an API version number in the core package. Modules provide version number(s) that they are capable of working with - if the two sets don't intersect then the system does not let the module get installed. Users who feel like living dangerously can edit the module's internal XML that stores the range of compatable core versions and try installing again - but this frequently fails and leads to a sad user who can only blame themself. This system would shift support requests from "why does this 4.6 module not work when I install it on a 4.7 sysem" to "why won't Drupal let me install this 4.6 module in a 4.7 system". I think the latter question is easier for the user to answer on their own and then understand better how the system works. It has pretty clear benefits to users, but also makes for a slight increase in administration cost and a slight increase in the code base. Basically, in addition to using an unenforced CVS branch to mark which core-version a particular module is compatable with, we also use and check a version in a file in the module. Regards, Greg
I fully support the notion that every module has its own directory.
* By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files.
I have the following on my list when HEAD is open for features again. We discussed it on the mailing list before, and an .ini file will have the module name and description. This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that. It also opens the door to putting in things like version number (not file version, but release version, date of change, and many other meta data, and nifty things). Split mode is nice performance wise, but would it be overkill in most cases?
I fully support the notion that every module has its own directory.
* By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files.
We discussed it on the mailing list before, and an .ini file will have the module name and description. This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that.
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? If not, I'd rather use .help, and stick the module name, description, and all help docs in there too. If .help isn't generic enough (for the various metadata things you mention), then use .info. But .ini *means* something and it means we either support the .ini spec fully (ugh, really?) or overload the meaning (never a good thing). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? If not, I'd rather use .help, and stick the module name, description, and all help docs in there too. If .help isn't generic enough (for the various metadata things you mention), then use .info. But .ini *means* something and it means we either support the .ini spec fully (ugh, really?) or overload the meaning (never a good thing).
Agreed. I think a *.info is the best bet. *.help seems to connote more of a help file, rather than an about or meta file. Heck, even *.meta would work too. Regardless of the extension, having a file like this is key and I think we can all agree on that. ted
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
I fully support the notion that every module has its own directory.
* By putting modules into their own directory, we're making it easier for some of those comments.help related ideas to kick in - to stick the help text in an external file and call it only when needed. I also think that chx's splitmode is a lot nicer if we could constrain the split functions to their source directory instead of having a primary directory full of 1000+ mini-files.
We discussed it on the mailing list before, and an .ini file will have the module name and description. This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that.
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? If not, I'd rather use .help, and stick the module name, description, and all help docs in there too. If .help isn't generic enough (for the various metadata things you mention), then use .info. But .ini *means* something and it means we either support the .ini spec fully (ugh, really?) or overload the meaning (never a good thing).
Not for the love of Windows (I have very little of that), but for the ease of parsing, ubiquitous format, extensibility ...etc.. See the order discussion on this late Jan here http://lists.drupal.org/pipermail/development/2006-January/013203.html Allie makes convincing arguments. I am not hung up on the .ini part, it can be .info or .config for all I care. What I do not want is a proliferation of a slew of files (we now have .module, .install, then .help, .somethingelse, .other, ...etc.) The same .ini/.config file can hold help, version, ...etc. with ease. Extensibility is the key here.
http://lists.drupal.org/pipermail/development/2006-January/013203.html Allie makes convincing arguments.
Hrm. I didn't know of parse_ini_file(). The following works as I'd expect: ----- test.ini admin/country/evil = "I am the mastah of eternity!" stupid/monkey = "hah" [somethign_help] wickedno = "yes" ----- test.ini with the following: print_r(parse_ini_file('./test.ini', true));. But, there are a few problems with this: * We don't get all the capabilities of t(). While we can certainly throw a t() around the retrieved string, we can never use %vars to include URLs or user data, or what have you. This, I think, puts the nail in the idea of help-within-an-ini file. If we do want to keep file slewing down (and I certainly agree), then the .ini file doesn't seem like the strongest choice, because there's no logic in it whatsoever (and %vars of t() can be considered logic, since most of them in core are using urls() or printing user vars). Likewise, there's no other precedence in Drupal that says something "not PHP" is a strong choice (our .install files, for instance, are moving away from a regular SQL dump and into PHP - can't we assume that we'd eventually want to do the same with an .ini file?) For what it's worth, I don't like .config - it's too actiony ("Let me config that for you..." is a common speech pattern). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Op woensdag 22 februari 2006 16:49, schreef Morbus Iff:
Why an .ini file?
Why any of these at all? why not a simple hook_info or hook_help in the .install? I prefer to not get wild on adding all kinds of .files, that is going to be hell to track. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Why any of these at all? why not a simple hook_info or hook_help in the .install?
Because, unlike modules, the code for an .install is nearly *always* growing. Whereas modules may lose functions or become tighter code, .install files MUST, for legacy reasons, keep all the data changes around. Any gains we get by using .install files in admin/modules would be utterly destroyed if we had to load system.install (which would contain all of the current/legacy updates.inc in my proposal). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
Why any of these at all? why not a simple hook_info or hook_help in the .install?
Because, unlike modules, the code for an .install is nearly *always* growing. Whereas modules may lose functions or become tighter code, .install files MUST, for legacy reasons, keep all the data changes around. Any gains we get by using .install files in admin/modules would be utterly destroyed if we had to load system.install (which would contain all of the current/legacy updates.inc in my proposal).
And a hook_info or hook_help would require loading the entire module in memory, and that is what causes the memory issues with admin/modules Splitmode helps with this, but as I said earlier, it is overkill for the vast majority of small/medium web sites. Perfect for big ones though. If splitmode is not the only way of doing things (can't imagine it would be so for the time being), then we need an external file to do that part.
Khalid B wrote:
If splitmode is not the only way of doing things (can't imagine it would be so for the time being), then we need an external file to do that part.
For what it is worth, I would like to see all of the help texts in a separate file. The case I often run into is that the texts chosen by module authors are inappropriate for a particular site I am building. The current "Drupal way" of fixing this is to turn on the locale.module, create a new version of English (en-US), disable the standard English, and translate the inappropriate texts from English to English. You can see how this is a horrible waste. I'd much rather have a texts file that extracted help and as much of the texts (if not all) as possible. This way, I could give the file to a non-tech person and say "fix it", with a reasonably high chance of them not screwing it all up. I can't do that with the current system. So while there are arguments for keeping the .file proliferation to a minimum, there are some good arguments to the contrary. -Robert
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? If not, I'd rather use .help, and stick the module name, description, and all help docs in there too. If .help isn't generic enough (for the various metadata things you mention), then use .info. But .ini *means* something and it means we either support the .ini spec fully (ugh, really?) or overload the meaning (never a good thing).
If we can use .ini-files, we should. No need to invent our own file format/parser. PHP has built-in functionality to parse .ini-files: http://php.net/parse_ini_file -- Dries Buytaert :: http://buytaert.net/
Dries Buytaert wrote:
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? If not, I'd rather use .help, and stick the module name, description, and all help docs in there too. If .help isn't generic enough (for the various metadata things you mention), then use .info. But .ini *means* something and it means we either support the .ini spec fully (ugh, really?) or overload the meaning (never a good thing).
If we can use .ini-files, we should. No need to invent our own file format/parser. PHP has built-in functionality to parse .ini-files:
In other words, PHP has already overloaded the .ini meaning for us.
On 2/22/06, Robert Douglass <rob@robshouse.net> wrote:
Dries Buytaert wrote:
Why an .ini file? The .ini extension *means* something (Windows .ini file) - is Drupal going to have full support of the .ini specification? ... If we can use .ini-files, we should. No need to invent our own file format/parser. PHP has built-in functionality to parse .ini-files:
In other words, PHP has already overloaded the .ini meaning for us.
Here is a way to get over the .ini stigma: On Linux: ln -s blah.ini blah.this_is_a_linux_file On MacOS/X ln -s blah.ini blah.ThisIsANiceMacFile Problem solved ... ;-)
http://php.net/parse_ini_file In other words, PHP has already overloaded the .ini meaning for us. Here is a way to get over the .ini stigma:
Please, please, please. This is now stop-motion. When I had .ini hate, it was because I didn't know a) the extent of what he meant by .ini, b) that there was a parse_ini_file function already. PHP's implementation of .ini files is correct. I've also tested it and it is actually useful. But, the *real* problem is described herein: http://lists.drupal.org/pipermail/development/2006-February/014021.html We don't get all the capabilities of t(). While we can certainly throw a t() around the retrieved string, we can never use %vars to include URLs or user data, or what have you. This, I think, puts the nail in the idea of help-within-an-ini file. *That* is what should be discussed in regard to .ini not OSes. *That*, and that alone, is why I'm against .ini now. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/22/06, Morbus Iff <morbus@disobey.com> wrote:
http://php.net/parse_ini_file In other words, PHP has already overloaded the .ini meaning for us. Here is a way to get over the .ini stigma:
Please, please, please. This is now stop-motion.
When I had .ini hate, it was because I didn't know a) the extent of what he meant by .ini, b) that there was a parse_ini_file function already.
PHP's implementation of .ini files is correct. I've also tested it and it is actually useful.
But, the *real* problem is described herein: http://lists.drupal.org/pipermail/development/2006-February/014021.html
We don't get all the capabilities of t(). While we can certainly throw a t() around the retrieved string, we can never use %vars to include URLs or user data, or what have you. This, I think, puts the nail in the idea of help-within-an-ini file.
*That* is what should be discussed in regard to .ini not OSes. *That*, and that alone, is why I'm against .ini now.
Merely trying to lighten up the mood, not make fun or anything. What you raise is a valid concern of course. Could certain strings read from the .ini file be designated as passed to t() and hence translatable using the same mechanism we have today? (Although not ideal, that works as it is today).
Could certain strings read from the .ini file be designated as passed to t() and hence translatable using the same mechanism we have today? (Although not ideal, that works as it is today).
I was thinking that, but it just seems to be sorta evil - we'd have to do eval'ing and so forth. Consider: [help] admin/monkey = "welcome to %sitename!" [tvars] sitename = variable_get('sitename', 'Drupal') This, of course, is only an example, but consider the same problem with url() and the like. Plus, sometimes, there's just degrees of logic applied to the help strings to get them to function properly. Consider the following from book.module's help: if (arg(0) == 'node' && is_numeric(arg(1)) && arg(2) == 'outline') { return t('...'); } I can find more examples, certainly, if I kept looking, but this was the first in alphabetical order. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Op woensdag 22 februari 2006 17:45, schreef Dries Buytaert:
If we can use .ini-files, we should. No need to invent our own file format/parser. PHP has built-in functionality to parse .ini-files:
May I introduce you all to YAML? http://www.yaml.org/ Yaml has the power of XML but the simplicity of INI. you can store any PHP^D^D^DRuby variable in yaml you can store any SQL database as YAML (true) you can store simple stuff like structured data in a very simple way. (true) </cynical RoR plugging> But other that that. I am not keen on ini. Not even on YAML. let alone on XML. why? We all write PHP. We all know it. Why not use it? why learn some new markup, some YAML, or some INI syntax, when we all even dream PHP. I ask you, what is the difference between: LeetBox_info() { return array( 'version' => '1.2.548' 'description' => 'this is teh leetest module evah: I tell you' 'depends' => array ('1337', 'forum', 'FooBar'); ); } and [LeetBox info] version: 1.2.548 description: this is teh leetest module evah[colon] I tell you #if you need a : or a ; please use [colon] or [semicolon] instead depends:1337, forum, FooBar #please use ! if your name needs a comma ? Those few ascii thingies? Imagine all the benefit of PHP: Unicode *cough*, t()-abiltiy, not having to learn YAML etc. Imagine all those libs in Drupal that one can (ab)use. etc. I see one main difference: PHP means stuff to me, that ini thing requires me to look up the syntax, to find ways around issues long fixed in PHP and above all to lean something new that I will not use anywhere else anyway! Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
On 2/22/06, Bèr Kessels <ber@webschuur.com> wrote:
We all write PHP. We all know it.
I believe that is a flawed assumption or at least that "we" is being defined differently by different people in this thread. Some Drupal users will not open PHP files and if the only way to edit an config file is by opening/editing PHP files then they will say "drupal is only for developers". In order to decide on a file format the first task is deciding the audience. Is it just the module developers who already know PHP? Is it module developers most of the time and other folks who are scared of PHP some of the time? Is it module developers a little bit of the time and "regular folks" 99% of the time? I think the 3rd item in my list is the most likely - developer writes the file once, users install the thing thousands of times and may need to read or even <gasp> edit that file to get it to work. Greg
list is the most likely - developer writes the file once, users install the thing thousands of times and may need to read or even <gasp> edit that file to get it to work.
A user would never need to edit an .ini or .info file, just like they never need to edit a .module or an .install file. Irrelevant argument. .install, .module, .inc., and .info files are developer only. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Wed, 2006-02-22 at 13:46 -0500, Morbus Iff wrote:
list is the most likely - developer writes the file once, users install the thing thousands of times and may need to read or even <gasp> edit that file to get it to work.
A user would never need to edit an .ini or .info file, just like they never need to edit a .module or an .install file. Irrelevant argument.
.install, .module, .inc., and .info files are developer only.
I think that is one of the problems with using a .ini extension - it is often used for configuration and program settings. A think .meta is more semantically in line with what we are talking about. In general I like the idea of using the ini file format, but I would like to make sure the parse_ini() function is nicely wrapped, so we could change/extend/mashup things in the future without lots of downstream changes. - Owen
We all write PHP. We all know it. Why not use it? why learn some new markup, some YAML, or some INI syntax, when we all even dream PHP.
That is my argument, yes: we know and user PHP. Anything else we're either shooting ourselves in the future (witness .sql -> .install movement) or requiring parser creation (YAML, XML, etc.). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
I agree with Ber. Look at phpMyAdmin, it has a pretty hardcore config file and guess what, it's all PHP arrays. It's simple, human readable, but requires no advanced functions to make it work, read, no overhead. So why don't we create the new file: module.meta (or module.info) and throw in it: module_meta() { return array( 'version' => '1.5', 'description' => t('This is a really cool module'), 'depends' => array('module1', 'module2', 'module3') 'template' => 'module.foo.tpl.php' ); } We can make the array as big or as small as needed and adjust hook_meta() as needed. This makes the most sense to me. I'm assuming these meta files aren't going to be that complex. Not only that, but it keeps Drupal consistent with the way everything else seems to work... arrays, forms api, yes arrays :-D ted
On 22 Feb 2006, at 9:19 PM, Theodore Serbinski wrote:
I agree with Ber. Look at phpMyAdmin, it has a pretty hardcore config file and guess what, it's all PHP arrays. It's simple, human readable, but requires no advanced functions to make it work, read, no overhead.
So why don't we create the new file: module.meta (or module.info) and throw in it:
module_meta() { return array( 'version' => '1.5', 'description' => t('This is a really cool module'), 'depends' => array('module1', 'module2', 'module3') 'template' => 'module.foo.tpl.php' ); }
I would like to use meta-information for template files too, and having to rename functions inside meta info files is annoying. In fact, there's many things that will need meta info files that aren't modules themes, styles, translations, install profiles, cck node types, etc. etc. Additionally, you need to load all these files before you can figure out what the requirements are, and using php means you potentially have namespace conflicts. I still vote for parse_ini(). Don't think modules, think packages. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I still vote for parse_ini().
And what about help? I need convincing. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 22 Feb 2006, at 9:33 PM, Morbus Iff wrote:
I still vote for parse_ini().
And what about help? I need convincing.
If by help you mean description, that can safely be in the file. I never said we should put the help hook in a meta info file. Once again. i'm late to the conversation =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
If by help you mean description, that can safely be in the file. I never said we should put the help hook in a meta info file. Once again. i'm late to the conversation =)
Well, in my head, having the possibility to move help into the meta files is required. Otherwise, we *will* have file spewage in the future ("shit, we used ini and we can't move help into there? Um. So, let's make a .help file! whee!"). I'm against file spewage: I'd really only like to see .install, .inc, .module, and .meta (or some such). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 22 Feb 2006, at 9:41 PM, Morbus Iff wrote:
If by help you mean description, that can safely be in the file. I never said we should put the help hook in a meta info file. Once again. i'm late to the conversation =)
Well, in my head, having the possibility to move help into the meta files is required. Otherwise, we *will* have file spewage in the future ("shit, we used ini and we can't move help into there? Um. So, let's make a .help file! whee!"). I'm against file spewage: I'd really only like to see .install, .inc, .module, and .meta (or some such).
Considering how the help hook currently works, can you think of a way not to have all help hooks loaded all the time to be able to run the help system. meta files, install files and .inc files can be loaded when necessary, help always needs to be there. it's the same problem we have with hook_menu. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Well, in my head, having the possibility to move help into the meta files is required. Otherwise, we *will* have file spewage in the future ("shit, we used ini and we can't move help into there? Um. So, let's make a .help file! whee!"). I'm against file spewage: I'd really only like to see .install, .inc, .module, and .meta (or some such).
Considering how the help hook currently works, can you think of a way not to have all help hooks loaded all the time to be able to run the help system.
Can I think of a way *right now*, on the spot? No. Do I know that there have been various desires to do so? Yes. Do I know that there is a belief that moving the help out of there will improve performance? Yes. Do I know that there's a desire to make handbook editing map sync more closely to module help editing? Yes. Do I want file spewage because we didn't make the "right" and "most flexible" decision? Absolutely not. Do I want the ability to move help into our meta info file? Yes. Am I thinking about that right now? Yes. Ignoring the technical limitations of moving help outside of .modules in general, do I believe that .ini files can satisfy the help desire? No. Do I see the move from .sql files to .install files being indicative of a future possibility with the non-logical .ini files? Yes. Do I want to make the same mistake? No. Help does not need to be there on node/13. No help has ever been displayed on that page. But, a lot of help text is actually loaded in memory on that page load. Should it? Not at all. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 22 Feb 2006, at 10:00 PM, Morbus Iff wrote:
Do I want the ability to move help into our meta info file? Yes. Am I thinking about that right now? Yes. Ignoring the technical limitations of moving help outside of .modules in general, do I believe that .ini files can satisfy the help desire? No. Do I see the move from .sql files to .install files being indicative of a future possibility with the non-logical .ini files? Yes. Do I want to make the same mistake? No. all I'm really opposed to is requiring a function definition for the meta information inside the file. Because a lot of the places I see the meta information being used are not modules, that might need to be copied around, taking the name from the directory they are in (the themes/style example).
We could also just include the meta files from within a function and use get_defined_vars() to retrieve the variables. oh .. and themes are a great place for knowing that files have changed, since most people modify them directly in the directory, hence disabling the theme and using a safe default after upgrade might be a good way of stopping theme breakages, for instance) If a module distributes template files that are overridden, it might also be useful to know which template files in the theme you are using might be out of date. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
oh .. and themes are a great place for knowing that files have changed, since most people modify them directly in the directory, hence disabling the theme and using a safe default after upgrade might be a good way of stopping theme breakages, for instance)
Hrm - I always thought the recommended behavior, Drupal and otherwise, was to copy the theme into a new directory and modify as needed. This was difficult with xtemplate, but not so much with phptemplate. Can we get away from this paradigm? "You have modified the bluemarine theme. This is generally unrecommended - consider reading this handbook page instead on how to properly theme Drupal." ? -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 22 Feb 2006, at 10:34 PM, Morbus Iff wrote:
Hrm - I always thought the recommended behavior, Drupal and otherwise, was to copy the theme into a new directory and modify as needed. This was difficult with xtemplate, but not so much with phptemplate. Can we get away from this paradigm? "You have modified the bluemarine theme. This is generally unrecommended - consider reading this handbook page instead on how to properly theme Drupal." ? Yeah. that was until the regions hook was introduced.
People are littering themes with mytheme_regions() now, which means copying them kills the regions hook. That is if they are not already themes to begin with. I sincerely believe that themes should not have their own namespaces, which is what the phptemplate_ namespace kind of of gets at. By introducing functions for the meta info, it becomes unusable for themes. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 22 Feb 2006, at 9:19 PM, Theodore Serbinski wrote:
'template' => 'module.foo.tpl.php'
OK ... here's another thing during install, it should put all the files distributed with it into a tracking table, along with checksums and timestamps for each of the files. I don't believe there's a good reason for us to have to specify this in the meta info files, and i believe we should only actually load the meta info files when any one of them has been changed. ... I'm sorry if i'm late to this thread, i forgot to renew my primary mail domain, and i only just managed to get mail sorted out now. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
during install, it should put all the files distributed with it into a tracking table, along with checksums and timestamps for each of the files.
Why? Timestamps are useless, because they won't match up with the timestamps of the actual source file (consider extract on localhost, upload via FTP toward remote host - timestamps are changed). And checksums would seem to only ever be used to validate upgrades, which seems to duplicate the schema_version in the system table. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 22 Feb 2006, at 9:40 PM, Morbus Iff wrote:
Timestamps are useless, because they won't match up with the timestamps of the actual source file (consider extract on localhost, upload via FTP toward remote host - timestamps are changed). And checksums would seem to only ever be used to validate upgrades, which seems to duplicate the schema_version in the system table.
Knowing that a file has been modified since it was initially installed can be very useful information. For changes that are made to the files without the install system. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Knowing that a file has been modified since it was initially installed can be very useful information. For changes that are made to the files without the install system.
To what and to whom though? How would it work or matter? About the only way I can see it being important is to encourage improper behavior: it encourages people to modify core files because when they upgrade, they can just check out what files they've changed, and merge the modifications, ignorantly, back into the newly downloaded core files. We shouldn't encourage that behavior. As for a normal Drupal upgrading process, I'm failing to see how that information is actually *useful* - how would the timestamp ever get updated? I run disobey.com off of HEAD - am I too assume I'd have to click "use this new timestamp for the base" every time I do a "cvs update"? And if it's just a click away like that, how is it future useful to a confused end user who just wants the message to go away? Need concrete examples and explanations, not "just cos!". -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Wed, Feb 22, 2006 at 10:34:58AM -0500, Khalid B wrote:
We discussed it on the mailing list before, and an .ini file will have the module name and description.
I like how the modules have everything self contained right now.
This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that.
That can be overcome by having the module list script set memory limit to -1. That simple fix should go in 4.7.
It also opens the door to putting in things like version number (not file version, but release version, date of change, and many other meta data, and nifty things).
All of which can be put into some sort of info hook(s). --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
We discussed it on the mailing list before, and an .ini file will have the module name and description.
I like how the modules have everything self contained right now.
I like that too, but we are already beyond this point. If your module needs a CCS file it will have a .css, same for .js, and even some modules use .inc. We also have the .install files as well. It was good while it lasted, but it is time to move on.
This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that.
That can be overcome by having the module list script set memory limit to -1. That simple fix should go in 4.7.
Doesn't work where the hosting company caps the memory limit. You will either get PHP to ignore the change you made, or give an error. In both cases: that is not a solution.
It also opens the door to putting in things like version number (not file version, but release version, date of change, and many other meta data, and nifty things).
All of which can be put into some sort of info hook(s).
I see merit in a hook_info(), as Ber outlined. The idea though is to make them a separate file, along with the _help hook as well.
On Wed, Feb 22, 2006 at 08:12:28PM -0500, Khalid B wrote:
That can be overcome by having the module list script set memory limit to -1. That simple fix should go in 4.7.
Doesn't work where the hosting company caps the memory limit. You will either get PHP to ignore the change you made, or give an error.
Ah. Very true, fine sir. Forgot about that.a
I see merit in a hook_info(), as Ber outlined.
The idea though is to make them a separate file, along with the _help hook as well.
It need not even be a function. The .info files can be something like this: <?php $info['modulename'] = array( 'version' => '1.2', ... etc ... ); The all that needs to be done is loop through the directory, including each .info file. At the end, the $info array has everything you need. Or it could even just be a regular array: <?php $info = array( 'version' => '1.2', ... etc ... ); Then the system goes through each file and either adds it to an overarching array like this (in psuedo code for quickness): <?php $all_info = array(); foreach module file { include $module.info; $all_info[$module] = $info; } Or just display the info directly: <?php $all_info = array(); foreach module file { include $module.info; echo 'name: ' . $module . '<br />'; echo 'version: ' $info['version'] . '<br />'; } Fast. Simple. No godawful .ini syntax. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
On Wed, 2006-02-22 at 19:58 -0500, Daniel Convissor wrote:
On Wed, Feb 22, 2006 at 10:34:58AM -0500, Khalid B wrote:
We discussed it on the mailing list before, and an .ini file will have the module name and description.
I like how the modules have everything self contained right now.
This avoids the need to load all module when the admin goes to admin/modules, and overcomes the memory issue associated with that.
That can be overcome by having the module list script set memory limit to -1. That simple fix should go in 4.7.
I am more concerned about the total amount of memory being used than the default system limits... We're talking a about web applications with potentially thousands of concurrent sessions.
It also opens the door to putting in things like version number (not file version, but release version, date of change, and many other meta data, and nifty things).
All of which can be put into some sort of info hook(s).
--Dan
Morbus Iff wrote:
* .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?)
No, thats basically all wrong. Drupal figures out the latest update number availiable and uses that as the installed schema version. -- Neil Drumm http://delocalizedham.com/
* .install files get aggregator_schema_version() function which tells the installer which version number to set in the system table on FIRST INSTALL. This way, it's not calling or seeing a number of updates that are already applied to the initial starting table. (I think this is a problem in our current install system, right?)
No, thats basically all wrong. Drupal figures out the latest update number availiable and uses that as the installed schema version.
Read the whole thread before you reply ;) -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
* Modules get an activate, deactivate, and uninstall hook. I think Merlin was working on this to some degree. Activate enables the module, deactivate disables it, but keeps the created data, prefs, and tables in place, and uninstall removes everything. This mimicks the operation of Gallery 2 modules - the uninstall part is awesome! If I use search.module for a week on my 5000+ node site, then find out it's just not good enough, I don't want those gigantic tables hanging around forever, taking up backup space. If I uninstall search.module, those tables and data should be removed.
Of course, you're assuming dependency handling here. If Pizza.module depends on the tables in JunkFood.module, then we can't uninstall junkfood.module untill pizza.module is uninstalled. This leads to debian-ish system, I'm just scared of re-implementing apt-get in PHP. Of course, if we go for it, it would be entertaining to see the code :) -Arnab
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further.
And one more: * misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run. -- Morbus Iff ( hey britney, you say you want to lose control? ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 23 Feb 2006, at 3:06 PM, Morbus Iff wrote:
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
One of the things that came from the theme system discussion at DrupalCon was that we need to implement namespacing in drupal. So that all css classes / id's created by drupal get prefixed by the name of the module they are generated by. Now we almost do something like this already, but I also think that anything that is in drupal.css should be prefixed by drupal-* , and all the modules should be module-*. This means that if you see a class in your markup (that hasn't been generated by the theme), you can immediately see which file the css is defined in, and which file you need to override. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
So that all css classes / id's created by drupal get prefixed by the name of the module they are generated by. This just seems to be an extension of the id-itus and class-itus that already afflicts Drupal. Most modules output their content in a container (usually a div, occasionally a table), all that's required is to have that container tagged with and id or class representative of the module.
Then use the CSS cascade properly to style any child elements. Slapping a prefix on everything is just bloat - why is it that bloat in PHP files is bad but bloat in XHTML and CSS is acceptable?
you can immediately see which file the css is defined in, and which file you need to override. It's really not that much harder to find a parent div/table and check out it's class/id.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Thu, 2006-02-23 at 15:34 +0000, Adrian Simmons wrote:
Adrian Rossouw wrote:
So that all css classes / id's created by drupal get prefixed by the name of the module they are generated by. This just seems to be an extension of the id-itus and class-itus that already afflicts Drupal. Most modules output their content in a container (usually a div, occasionally a table), all that's required is to have that container tagged with and id or class representative of the module.
Then use the CSS cascade properly to style any child elements.
Slapping a prefix on everything is just bloat - why is it that bloat in PHP files is bad but bloat in XHTML and CSS is acceptable?
Bloat in php files is code that must be read, compiled, and executed... not simply read and fed. Good naming conventions are encouraged throughout drupal. Verbose naming of ID's and Classes assist developers and designers working together, and provide more semantics to the markup for search engines to take advantage of. I personally prefer only using ID for a know content item. block or node. Then using multiple classes.. id='node-29' class='node node-page' class='.help .aggregator-help'
you can immediately see which file the css is defined in, and which file you need to override. It's really not that much harder to find a parent div/table and check out it's class/id.
but finding the file in which it is defined can be difficult, and for a developer communicating with a designer who isn't drupal-saavy, verbose class names can ease the designer developer communication.
Darrel O'Pry wrote:
but finding the file in which it is defined can be difficult, and for a developer communicating with a designer who isn't drupal-saavy, verbose class names can ease the designer developer communication. It must just be me that can hear so many designers and theme developers cursing and screaming because they have such a hard time overriding existing CSS.
The reason they have such a hard time doing that is because so much of both drupal.css and module specific css use highly specific selectors instead of using the css cascade intelligently and efficiently. This multi-class/ID on every element encourages lazy css writing. But we went over all this months ago, so I'll shut up now and try and provide themes/patches that prove the point instead of ranting here :) -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Thu, 2006-02-23 at 08:06 -0500, Morbus Iff wrote:
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further.
And one more:
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
While I agree with this in terms of simplifying code organization I think that we would want to consider the number of files sent to the client. Each css file is a http request with the overhead that that implies. The fix for this would be for the css from modules (and maybe any core theme css) to be aggregated and sent to the browser in one file (either a physical file or a php script that sends the correct headers). - Owen
The fix for this would be for the css from modules (and maybe any core theme css) to be aggregated and sent to the browser in one file (either a physical file or a php script that sends the correct headers).
A dangerous fix, IMO, as that will break the "view source" web developers have come to expect (as a direct view source of the module-CSS-file wouldn't know which modules to actually load). -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/23/06, Owen Barton <drupal@grugnog.com> wrote:
And one more:
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
While I agree with this in terms of simplifying code organization I think that we would want to consider the number of files sent to the client. Each css file is a http request with the overhead that that implies.
Yes this could still occur. We would simply include 'modules.php' which would be content-type text/css and would be dynamicly generated with all of the correct CSS from the modules. The one problem with this though, could be a caching issue, however, possibly, since the file is of content-type text/css, it might be cached. Or we can come up with our own mechanism in Drupal. ted
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
While I agree with this in terms of simplifying code organization I think that we would want to consider the number of files sent to the client. Each css file is a http request with the overhead that that
Yes this could still occur. We would simply include 'modules.php' which would be content-type text/css and would be dynamicly generated
For what it's worth, I'm deathly against PHP generated CSS. I'd much rather have a gigantic misc/drupal.css than a css.php thing. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 2/23/06, Morbus Iff <morbus@disobey.com> wrote:
For what it's worth, I'm deathly against PHP generated CSS. I'd much rather have a gigantic misc/drupal.css than a css.php thing.
I agree. For all the benefits it might seem to have, generating CSS would cause more problems than it's worth. You have to kiss caching goodbye and say hello to unnecessary overhead. I'd be ok with splitting off the module specific bits of drupal.css into modules/foo/foo.css but it seems like most people's gripe with CSS is not about it's size but that they just can't figure out how to override selectors in their theme. If more CSS advocacy is what's needed, then so be it.
On 2/24/06, Chris Cook <beerfan@gmail.com> wrote:
into modules/foo/foo.css but it seems like most people's gripe with CSS is not about it's size but that they just can't figure out how to
That should have been "...gripe with drupal.css..."
On Thu, 2006-02-23 at 17:03 +0000, Owen Barton wrote:
On Thu, 2006-02-23 at 08:06 -0500, Morbus Iff wrote:
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further.
And one more:
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
While I agree with this in terms of simplifying code organization I think that we would want to consider the number of files sent to the client. Each css file is a http request with the overhead that that implies.
This so breaks caching...
The fix for this would be for the css from modules (and maybe any core theme css) to be aggregated and sent to the browser in one file (either a physical file or a php script that sends the correct headers).
it is one file now... Scripted is even worse, then the caching behavior of most browsers works against us. If it were broken up and the css files were only linked on pages that needed them, then we could split the load of downloading the multiple css files over several page loads.
- Owen
On Thu, 2006-02-23 at 08:06 -0500, Morbus Iff wrote:
This is what I'd like to see in 4.8/5.0 which would tie up some "loose ends" as it were with some of the direction that Drupal is moving in. These are bullet points because I'm heading off to work, but I'll be more than happy to wax further.
And one more:
* misc/drupal.css can get split up into module directories so that module-specific CSS (such as aggregator and forums) doesn't get downloaded even if the module isn't enabled. Also, I think it'll make for cleaner CSS in the long run.
Saints be praised with a big +1. I'll start on it as soon as I figure out the open_basedir, and how to handle drupal's tmp and left over files...
participants (17)
-
Adrian Rossouw -
Adrian Simmons -
andrew morton -
Arnab Nandi -
Bèr Kessels -
Chris Cook -
Daniel Convissor -
Darrel O'Pry -
Dries Buytaert -
Earl Miles -
Greg Knaddison -
Khalid B -
Morbus Iff -
Neil Drumm -
Owen Barton -
Robert Douglass -
Theodore Serbinski