Move all core modules into their own directories.
We've discussed this to death during the freeze (even though we weren't supposed to), and most (if not all) the developers feel this is a good idea. When can we get around to doing this. The biggest issue I see is that all patches for 4.7 won't apply on HEAD. That is inevitable anyway, so I think we should just go for it already. =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
We've discussed this to death during the freeze (even though we weren't supposed to), and most (if not all) the developers feel this is a good idea.
When can we get around to doing this. The biggest issue I see is that all patches for 4.7 won't apply on HEAD. That is inevitable anyway, so I think we should just go for it already. =)
I'm having a hard time trying to come up with a reason to not do this. - I would do things as I usually do with CVS- mv; cvs rm; cvs add. Then someone would yell at me for losing the history. - It kinda feels like shuffling the files around for the sake of shuffling. Maybe this should be coupled with something I talked with Kieran about last friday, help in separate human-readable files instead of PHP. The other option of course is making .install files for core modules, but I think thats less doable. -- Neil Drumm http://delocalizedham.com/
Neil Drumm wrote:
Adrian Rossouw wrote:
We've discussed this to death during the freeze (even though we weren't supposed to), and most (if not all) the developers feel this is a good idea.
When can we get around to doing this. The biggest issue I see is that all patches for 4.7 won't apply on HEAD. That is inevitable anyway, so I think we should just go for it already. =)
I'm having a hard time trying to come up with a reason to not do this.
- I would do things as I usually do with CVS- mv; cvs rm; cvs add. Then someone would yell at me for losing the history. - It kinda feels like shuffling the files around for the sake of shuffling. Maybe this should be coupled with something I talked with Kieran about last friday, help in separate human-readable files instead of PHP. The other option of course is making .install files for core modules, but I think thats less doable.
Neil, someone with account on the CVS server can coordinate the move, with moving files with histories around. But I would bet you know this already :) Goba
On 02 May 2006, at 9:19 PM, Neil Drumm wrote:
- I would do things as I usually do with CVS- mv; cvs rm; cvs add. Then someone would yell at me for losing the history. - It kinda feels like shuffling the files around for the sake of shuffling. Maybe this should be coupled with something I talked with Kieran about last friday, help in separate human-readable files instead of PHP. The other option of course is making .install files for core modules, but I think thats less doable. http://lists.drupal.org/archives/development/2006-02/msg00460.html
pretty good summary The 2 things I am working on is the dependency system, which introduces meta-information for all of the modules / themes / blah. And then there's the changes for the db api, namely db_create_table, and db_add_column etc. functions. Along with individual module directories and install files, this _could_ drastically improve how much maintenance db schema's and the like take. Additionally, it makes all our distributions the same. When we build install profiles, they will just happen to ship with a different set of directories. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 02 May 2006, at 21:41, Adrian Rossouw wrote:
The 2 things I am working on is the dependency system, which introduces meta-information for all of the modules / themes / blah. And then there's the changes for the db api, namely db_create_table, and db_add_column etc. functions.
Can you explain us more about said dependency system? I've never been a big fan of meta-data files. I remember that chx wrote a very simple dependency system that adds about 30 lines of code and no meta- data files. It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations? -- Dries Buytaert :: http://www.buytaert.net/
On 03 May 2006, at 9:10 AM, Dries Buytaert wrote:
Can you explain us more about said dependency system? I've never been a big fan of meta-data files. I remember that chx wrote a very simple dependency system that adds about 30 lines of code and no meta-data files. It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations?
The limitation there is, you still have to load all the modules to find out what the dependencies are. And then you can still have namespace conflicts (you should never have more than one theme loaded at the same time. and themes should have metadata too) Could you explain why you have never been a fan of metadata files? I've been aware of this dislike of yours, since the first version of phptemplate, and while I relented then, I believe it's important now that we implement them. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Can you explain us more about said dependency system? I've never been a big fan of meta-data files. I remember that chx wrote a very simple dependency system that adds about 30 lines of code and no meta-data files. It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations? The limitation there is, you still have to load all the modules to find out what the dependencies are.
Except on install/configure time you don't need the metadata at all. True, you don't need the hooks as well. The separate metadata files, should help in creating distros, and tools for making decisions before downloading something. The format of the metadata is of no real concequence, as long as it is simple enough.
On 03 May 2006, at 12:54, Adrian Rossouw wrote:
Can you explain us more about said dependency system? I've never been a big fan of meta-data files. I remember that chx wrote a very simple dependency system that adds about 30 lines of code and no meta-data files. It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations? The limitation there is, you still have to load all the modules to find out what the dependencies are. And then you can still have namespace conflicts (you should never have more than one theme loaded at the same time. and themes should have metadata too)
Because I'm not sure these namespace problems are real. So far, we managed to avoid them pretty easily. -- Dries Buytaert :: http://www.buytaert.net/
Op woensdag 3 mei 2006 09:10, schreef Dries Buytaert:
It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations?
That time the discussion was about what the best metadata holder would be: .ini, XML, YAML, SQL etc. chx and I pushed forward that there is another way to store metadata: PHP. pro: we all speak PHP. Nothing new to learn. No parsers required. con: non-developers are not able to read/wrtie the metadata. IMO there is no need at all for non developers to get involved in the metadata. Bèr On a sidenote: i have proof of concept code for so called fixtures in sympal scripts (need to secure the whole thing first, before releasing). A fixture contains a state of the site. See it as "save the current website". Fixtures are needed for good tests, for development data (don't you ever get tired of typing adfgasdfasdf jkljljkljk in your node fields just to test a permission), and for saving the variables and system settings. But fixtures are also a means to store certain distro-initial-state-and-data. Fixtures in sympals scripts are pure PHP. :) I would love to be able to re-use core code for this in future, so I would love to see this path of 'store stuff in PHP' explored more. -- [ End user Drupal services and hosting | Sympal.nl ]
On 03 May 2006, at 1:02 PM, Bèr Kessels wrote:
chx and I pushed forward that there is another way to store metadata: PHP. pro: we all speak PHP. Nothing new to learn. No parsers required. con: non-developers are not able to read/wrtie the metadata. IMO there is no need at all for non developers to get involved in the metadata. They could be php, and I am leaning heavily in that direction, albeit not in functions. The biggest con however imo is that drupal.org needs to be able to parse these too, and I'd rather not be in a situation where drupal.org needs to run random php to be able to do it's job.
Fixtures in sympals scripts are pure PHP. :)
I would love to be able to re-use core code for this in future, so I would love to see this path of 'store stuff in PHP' explored more. I have a similar idea in the form of site packages. The only problem is it will require a database dump in my version. But at least the package will tell you what versions of which modules it need to be able to run.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on admin/modules. Futher, it means that CVS or SVN or project module or system.module can safely read anyone's scripts without trusting all files. Consider how much better we can do with project listings on the web if we aren't duplicating information between the project form and the README. On 5/3/06 3:10 AM, "Dries Buytaert" <dries.buytaert@gmail.com> wrote:
On 02 May 2006, at 21:41, Adrian Rossouw wrote:
The 2 things I am working on is the dependency system, which introduces meta-information for all of the modules / themes / blah. And then there's the changes for the db api, namely db_create_table, and db_add_column etc. functions.
Can you explain us more about said dependency system? I've never been a big fan of meta-data files. I remember that chx wrote a very simple dependency system that adds about 30 lines of code and no meta- data files. It relied on a new _dependency() hook and that was pretty much it. Sounds a lot simpler to me but maybe I oversee some limitations?
-- Dries Buytaert :: http://www.buytaert.net/
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on
And the big problem with any non-PHP solution is that, three years from now, we'll be throwing it out and reinventing it (ie., the move from .sql files to .install) because we've found it doesn't scale. One of the "problems" I was hoping to solve with the metadata files being PHP is we have a chance to move the entire _help hook there, which will make the .module file smaller, will give the doc team their own little "namespace" to worry about, and will lessen the load of the .module file in memory (since we're not loading all the help text in, especially when, for a visitor it rarely, if ever, gets parsed). -- Morbus Iff ( i am the horrible hogglewart ) 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 03 May 2006, at 14:39, Moshe Weitzman wrote:
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on admin/modules. Futher, it means that CVS or SVN or project module or system.module can safely read anyone's scripts without trusting all files. Consider how much better we can do with project listings on the web if we aren't duplicating information between the project form and the README.
True. Thanks for pointing these out. :) Being able to execute meta-data files seems dangerous. Not being able to execute meta-data files makes them a lot less interesting. -- Dries Buytaert :: http://www.buytaert.net/
On 03 May 2006, at 14:39, Moshe Weitzman wrote:
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on admin/modules. Futher, it means that CVS or SVN or project module or system.module can safely read anyone's scripts without trusting all files. Consider how much better we can do with project listings on the web if we aren't duplicating information between the project form and the README.
Maybe this makes for a good starting point to experiment with some of the ideas. Execute from the command line in Drupal's root directory. -- Dries Buytaert :: http://www.buytaert.net/
Maybe this makes for a good starting point to experiment with some of the ideas. Execute from the command line in Drupal's root directory.
Useful. In addition, we should consider moving all a module's associated files into its directory. A core example is upload.js from /misc to /modules/upload (or a subdirectory). This change would help us get away from our sometime practice of giving core components special treatment that e.g. contrib modules don't have access to. (An example of this problem is the hard-coding of js behaviours into form element theme functions, e.g., autocomlete in theme_textfield(), see this issue http://drupal.org/node/57865. Obviously, contrib modules wishing to add behaviours to existing elements can't follow what's done in core.)
On 03 May 2006, at 6:27 PM, Nedjo Rogers wrote:
This change would help us get away from our sometime practice of giving core components special treatment that e.g. contrib modules don't have access to. Perhaps see if there are any modules we can make conditional includes for. To reduce their memory usage.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 03 May 2006, at 14:39, Moshe Weitzman wrote:
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on admin/modules. Futher, it means that CVS or SVN or project module or system.module can safely read anyone's scripts without trusting all files. Consider how much better we can do with project listings on the web if we aren't duplicating information between the project form and the README.
Maybe this makes for a good starting point to experiment with some of the ideas. Execute from the command line in Drupal's root directory.
I've given it some more thought and I'm OK with moving each module to its own directory. Now, we need someone who can extend the dir.php to be more thourough (eg. and move some css / js). I'd like to see someone take action, rather than discussing this to death. If you have an interest in this, please step forward, open an issue on drupal.org and start sharing dir.php's. :) One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it. The advantages: * Easier for designers; just copy the template file. * We're forced do a better job separating code and markup. * Smaller modules and reducing memory footprint as the theme functions are only loaded on demand. The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines. -- Dries Buytaert :: http://buytaert.net/
Dries Buytaert wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines.
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate? -- Neil Drumm http://delocalizedham.com/
I think using template files is a great idea, but not at the expense of using other theming engines. Neil Drumm wrote:
Dries Buytaert wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines.
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate?
My concern here is also what about theme functions that make more sense written in PHP-with-print style rather than HTML-with-some-PHP style? Anything where you have an array that ends up as a table or list, for instance, would fall into that category. Template files are cool, but let's not get carried away. They're not the answer to every output question. -- Larry Garfield On Thu, May 4, 2006 7:33 am, Scott White said:
I think using template files is a great idea, but not at the expense of using other theming engines.
Neil Drumm wrote:
Dries Buytaert wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines.
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate?
On 04 May 2006, at 9:56 PM, Larry Garfield wrote:
My concern here is also what about theme functions that make more sense written in PHP-with-print style rather than HTML-with-some-PHP style? Anything where you have an array that ends up as a table or list, for instance, would fall into that category. I have no objection against those. Currently stuff like theme_table for instance, is impractical to write otherwise.
Here i think the fapi approach makes far more sense, like nedjo said. Drumm's form_table element is _far_ more understandable and themeable than our current theme_table. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Here i think the fapi approach makes far more sense, like nedjo said. Drumm's form_table element is _far_ more understandable and themeable than our current theme_table.
That approach is certainly good, and certainly cool, but it does not replace the ability to -- when necessary -- just build a complex string based on complex PHP logic. Template files are great for fitting pre-rendered strings into an HTML shell, but they are terrible for encapsulating large quantities of conditional logic. I'd LOVE to see more template file support -- being able to throw snippets around in small files rather than functions would be cool -- but not if it comes at the *expense* of basic function support. Perhaps I'm misunderstanding what's really being suggested? --Jeff
Let's not cloud the discussion. We are talking about x.tpl.php files which is PHP. You can do whatever you want in them with PHP or HTML. Noone proposes to remove that. On 5/4/06 3:56 PM, "Larry Garfield" <larry@garfieldtech.com> wrote:
My concern here is also what about theme functions that make more sense written in PHP-with-print style rather than HTML-with-some-PHP style? Anything where you have an array that ends up as a table or list, for instance, would fall into that category.
Template files are cool, but let's not get carried away. They're not the answer to every output question.
Neil Drumm wrote:
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate?
I don't use anything but PHPTemplate, but I think that we want to keep the engine system. Why don't we just leave the theme_ function inclusion mechanism to the engine? PHPTemplate will require separate files, and other engines can do what they please.
On 5/4/06, Robert Douglass <r.douglass@onlinehome.de> wrote:
Neil Drumm wrote:
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate?
I don't use anything but PHPTemplate
Me too.
but I think that we want to keep the engine system.
Adrian and others mentioned Smarty, which is widely used outside Drupal, and PHPTal (which is more secure than PHPTemplate). Seems like choice is good, and let the market decide ...
Why don't we just leave the theme_ function inclusion mechanism to the engine? PHPTemplate will require separate files, and other engines can do what they please.
We can have each module put its theme_foo_bar() functions in a file called foo.theme in the modules/foo directory. Then, in phptemplate we can include the .theme file and other engines can do their thing. Having a separate file (whatever it is named) is good, since we separate presentation (.theme) from logic (.module).
Adrian Count me in with Morbus, Earl, et al camp who are concerned by the number of files that will have to be included. A site with 15 extra modules each with 3 theme_function will have 45 more files to include. If we have just one file per module, then it is only 15. A world of difference.
On 06 May 2006, at 5:31 AM, Khalid B wrote:
Count me in with Morbus, Earl, et al camp who are concerned by the number of files that will have to be included. A site with 15 extra modules each with 3 theme_function will have 45 more files to include. If we have just one file per module, then it is only 15. A world of difference.
One theme file per module has exactly NO benefits to designers over having them in the .module to begin with. If we find that having them in individual files is too slow (which I don't believe will be the case, but is something we have to benchmark, not go either way on just because of a gut feeling!) we can develop a caching layer to handle this. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On the theming subject could there be some middle ground here. First we have a default theme file for the module you can through all your one line theme functions in here. Then we allow for individual files that can provide seperation for more complicated and elaborate themeing. There might be a name spacing issue but there might be some way we could allow the individual files to overide the default functions which would allow some flexibility for people themeing functions and keeping up to date with bug fixes etc. Just my 2 cents. James On 5/6/06, Adrian Rossouw <adrian@bryght.com> wrote:
On 06 May 2006, at 5:31 AM, Khalid B wrote:
Count me in with Morbus, Earl, et al camp who are concerned by the number of files that will have to be included. A site with 15 extra modules each with 3 theme_function will have 45 more files to include. If we have just one file per module, then it is only 15. A world of difference.
One theme file per module has exactly NO benefits to designers over having them in the .module to begin with. If we find that having them in individual files is too slow (which I don't believe will be the case, but is something we have to benchmark, not go either way on just because of a gut feeling!) we can develop a caching layer to handle this.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
If we find that having them in individual files is too slow (which I don't believe will be the case, but is something we have to benchmark, not go either way on just because of a gut feeling!) we can develop a caching layer to handle this.
Optimise later, I would say. And benchmarks in this case are going to be really weird. Too many different filesystems with different penalties, with or without caching, file or db cache, with or without opcaches, .... IMO, this is exactly a case to try and make the best possible case for the designers. I think big files are bad, because it is hard to grasp them easily at once. For the theme_ to be separate from the main code is better, since you usually need those during design, and don't need to go through vast amounts of unneeded for the task code. Especially if you are not that familiar with php. I vote to make life easier for the designers. And optimise the performance later. I think it is quite doable. I've done a rough split of the theme functions from the modules based on the current 4.7 (didn't have the latest cvs, but it should be similar). If you want I can prepare a patch and submit it on drupal.org together with the split code (slow, ugly, but quick to code).
Optimise later, I would say. And benchmarks in this case are going to be really weird. Too many different filesystems with different penalties, with or without caching, file or db cache, with or without opcaches, ....
Exactly. Developers (myself included!) tend to optimize way too fast/ early. I'd start with the bare minimal, get that into core, spend some time evaluating, and improve as necessary. Making the best possible case for designers is exactly what this is about, and this time around, we should go all the way.
I've done a rough split of the theme functions from the modules based on the current 4.7 (didn't have the latest cvs, but it should be similar). If you want I can prepare a patch and submit it on drupal.org together with the split code (slow, ugly, but quick to code).
I've read your blog post and am particularly interested in trying to test this as soon it is working as intended. Step #1 is to run the scripts and to do some performance benchmark. Have you done any experiments yet? When can we expect to be able to play with this? :-) Thanks for taking a lead in this, Vlado! Much appreciated. -- Dries Buytaert :: http://www.buytaert.net/
I've read your blog post and am particularly interested in trying to test this as soon it is working as intended. Step #1 is to run the scripts and to do some performance benchmark. Have you done any experiments yet? When can we expect to be able to play with this? :-) Not really, haven't had time yet. Will do over the weekend. To test there is a need for a small change in theme.inc, and that's all.
Thanks for taking a lead in this, Vlado! Much appreciated. Well, Adrian is the one who's pushing :)
As a sidenote - documentation. Is anyone interested in helping me prepare a theming reference. The reference from the apis is not good for designers. Ultimately I would like to be able to automatically produce the html snippets, for each theme function, regardless of what is the template engine. My plan is to: 1. catalogue all available theme_ functions in core (for all practical purposes this is done, might need tweaking, but the code is there) 2. go through the theme_ functions and construct dummy(lorem ipsum) style calls to extract a formatted html. 3. look into producing a drupaldocs like description. This suggestion is closely related to testing as well. How would you approach it? Any ideas? Cheers, Vlado
On 11 May 2006, at 10:54 AM, drupal wrote:
This suggestion is closely related to testing as well. How would you approach it? Any ideas?
Join the drupal-themes list. now. We have a whole bunch of designers who are itching to get to stuff like this. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Hi Vlado, On 07 May 2006, at 14:42, drupal wrote:
For the theme_ to be separate from the main code is better, since you usually need those during design, and don't need to go through vast amounts of unneeded for the task code. Especially if you are not that familiar with php. I vote to make life easier for the designers.
And optimise the performance later. I think it is quite doable.
I've done a rough split of the theme functions from the modules based on the current 4.7 (didn't have the latest cvs, but it should be similar). If you want I can prepare a patch and submit it on drupal.org together with the split code (slow, ugly, but quick to code).
did you make any progress with this? -- Dries Buytaert :: http://www.buytaert.net/
Just a note on CVS implications for moving files to new locations. There are three options that I can see: 1. Move to a better SCM (svn, bzr), where moving files becomes a non-issue. The scope of that is huge, and has been debated to death with no concensus and is a holy war by itself. 2. Do a cvs remove on the present file, do a cvs add on the new directory/file. Repository integrity is maintained (checking out old tags works), but old history is lost. One possible workaround is to make the first commit log message contain a link to the attic where the old file is. 3. Move the ,v files in the repository backend. This will break old tags. For example checking out 4.6 will not find modules/node.module, since it is now in modules/node/node.module, and CVS knows nothing about the old path. Derek, you seem to be the new CVS guy around, any ideas on how to proceed with this?
On May 20, 2006, at 8:15 AM, Khalid B wrote:
1. Move to a better SCM...
argh, not this again. ;) "active" -> "won't fix".
Derek, you seem to be the new CVS guy around, any ideas on how to proceed with this?
yes. which i've posted to this thread before. ;) or, RTFI (issue): http://drupal.org/node/64280#comment-99892 thanks, -derek
Derek, you seem to be the new CVS guy around, any ideas on how to proceed with this?
yes. which i've posted to this thread before. ;) or, RTFI (issue):
Excellent plan ...
What about the system table? On Sat, 2006-05-20 at 12:54 -0400, Khalid B wrote:
Derek, you seem to be the new CVS guy around, any ideas on how to proceed with this?
yes. which i've posted to this thread before. ;) or, RTFI (issue):
Excellent plan ...
We can have a _update_X() that does that. It can either do a rescan of the file the system and populate the system table, or we can use direct UPDATEs to change them. On 5/20/06, Darrel O'Pry <dopry@thing.net> wrote:
What about the system table?
On Sat, 2006-05-20 at 12:54 -0400, Khalid B wrote:
Derek, you seem to be the new CVS guy around, any ideas on how to proceed with this?
yes. which i've posted to this thread before. ;) or, RTFI (issue):
Excellent plan ...
One of the changes that made it into 4.7 late in the game was automatic detection of moved modules whenever system/modules is loaded. It makes migrating modules from the /modules directory to the /sites/x/modules directory a snap, AND as a side benefit it makes this sort of migration loads easier. Seems like the same logic could apply pretty easily. --Jeff -----Original Message----- From: Khalid B [mailto:kb@2bits.com] Sent: Saturday, May 20, 2006 12:00 PM To: development@drupal.org Subject: Re: [development] Move all core modules into their own directories. We can have a _update_X() that does that. It can either do a rescan of the file the system and populate the system table, or we can use direct UPDATEs to change them.
I am diving into Drupal in earnest. Quick question... How/where can I turn all/any caching? I am trying to skin/dev new front page but changes are not always immediately released. Thanks! :)
On 21 May 2006, at 12:02 AM, Larry Eitel wrote:
I am diving into Drupal in earnest. Quick question... How/where can I turn all/any caching? I am trying to skin/dev new front page but changes are not always immediately released. I recommend installing the devel module. It has lots of tools, such as a simple link to clear the cache.
You might also want to install the themedev module. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 5/21/06, Adrian Rossouw <adrian@bryght.com> wrote:
I recommend installing the devel module. It has lots of tools, such as a simple link to clear the cache.
The devel module is indeed very handy for clearing the cache. However, in answer to your question, Larry: there are two things that are ALWAYS cached in Drupal - the menu tree, and the table of variables. There is no way to turn off caching for these two things. The 'cache' setting on the 'admin/settings' page only controls caching of themed page output. Cheers, Jaza.
did you make any progress with this? Yes - debugging some code though.
The modules in core in their own directories is a simple script and it just works. Out of the box in drupal. No code changes required. It just works. The theming bits are more complicated. It requires changes to the modules code, and learning from the form api's changes I've written a helper tool. Unfortunately still fishing for bugs in it. With luck I'll have it working within a day or two.
this might be useful that is a simple bash script to do a move. It should work on a typical unix with the gnu tools installed. For windows just use cygwin. You probably won't need to adjust anything, but the modules directory I'll put the theme code later. == cut here ==================================================== #! /bin/bash MODULES=drupal/modules for i in `ls $MODULES/*.module|cut -f1 -d.|cut -f3 -d'/' `; do echo $i ; mkdir $MODULES/$i; mv $MODULES/$i.module $MODULES/$i/$i.module done
On 06 May 2006, at 5:20 AM, Khalid B wrote:
Adrian and others mentioned Smarty, which is widely used outside Drupal, and PHPTal (which is more secure than PHPTemplate).
Why would phptal be more secure ? you can still use php: to execute php code =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Neil Drumm wrote:
Dries Buytaert wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines.
I would actually be okay with removing the whole engine system and simply doing PHPTemplate only. Sure theme engines are a nice feature, but how many are maintained and what % of themes are PHPTemplate?
Neil, there were some points that supporting plain PHP function based themes are going to be continued. They can be a lot faster then including 20 PHP template files just to build a page. Goba
Op donderdag 4 mei 2006 16:42, schreef Gabor Hojtsy:
Neil, there were some points that supporting plain PHP function based themes are going to be continued. They can be a lot faster then including 20 PHP template files just to build a page.
More important, is the support. PHPtal and Smarty are used a LOT in the industry. smarty has been maintained over three releases. There are a number of smarty themes in there. Even if its not used a lot, the very fact that we can *say* that we can support Smarty, is a big plus. But even more important, we should (or could) really focus on some cross-CMS engines as well. Imagine the coolness of being able to share themes between Jooomla and Drupal. A joomla.engine or even droomla.engine would be required for that. Dropping support for new engines makes this impossible. A big -1 from me for retting rid of other engines then phptemplate! Bèr
But even more important, we should (or could) really focus on some cross-CMS engines as well. Imagine the coolness of being able to share themes between Jooomla and Drupal. A joomla.engine or even droomla.engine would be required
for that. Dropping support for new engines makes this impossible. Yes... that would resolve a lot of the problems with the shortage in templates. introfini -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Monday, May 08, 2006 9:55 AM To: development@drupal.org Subject: Re: [development] Move all core modules into their own directories. Op donderdag 4 mei 2006 16:42, schreef Gabor Hojtsy:
Neil, there were some points that supporting plain PHP function based themes are going to be continued. They can be a lot faster then including 20 PHP template files just to build a page.
More important, is the support. PHPtal and Smarty are used a LOT in the industry. smarty has been maintained over three releases. There are a number of smarty themes in there. Even if its not used a lot, the very fact that we can *say* that we can support Smarty, is a big plus. But even more important, we should (or could) really focus on some cross-CMS engines as well. Imagine the coolness of being able to share themes between Jooomla and Drupal. A joomla.engine or even droomla.engine would be required for that. Dropping support for new engines makes this impossible. A big -1 from me for retting rid of other engines then phptemplate! Bèr
On 08 May 2006, at 11:50 AM, introfini wrote:
Yes... that would resolve a lot of the problems with the shortage in templates.
introfini
The biggest problem with that is the different locations where they store their files. I would like to be able to get the bootstrap of drupal low enough, that you can create (say) a templates/ hook, which is just a wraparound for the themes directory. Otherwise, you will still need to edit the templates from other cms' to change the paths of where things are. Perhaps some intelligent modRewrite rules could do it too. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 08 May 2006, at 10:55, Bèr Kessels wrote:
But even more important, we should (or could) really focus on some cross-CMS engines as well. Imagine the coolness of being able to share themes between Jooomla and Drupal. A joomla.engine or even droomla.engine would be required for that. Dropping support for new engines makes this impossible.
A big -1 from me for retting rid of other engines then phptemplate!
Euh, who said we'd drop them? We were talking about making PHPTemplate the new fallback mechanism, rather than theme_ function. Really, we're done talking about the theme stuff. Time for some code. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it.
:drool: That sounds good.
" * Easier for designers; just copy the template file." This is a big plus. introfini -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Dries Buytaert Sent: Thursday, May 04, 2006 12:30 PM To: development@drupal.org Subject: Re: [development] Move all core modules into their own directories.
On 03 May 2006, at 14:39, Moshe Weitzman wrote:
I'm sure Adrian will answer in more detail but the key advatgantage of text files for metadata is that you don't load PHP to in order to get title/author/description... This means no more memory problems on admin/modules. Futher, it means that CVS or SVN or project module or system.module can safely read anyone's scripts without trusting all files. Consider how much better we can do with project listings on the web if we aren't duplicating information between the project form and the README.
Maybe this makes for a good starting point to experiment with some of the ideas. Execute from the command line in Drupal's root directory.
I've given it some more thought and I'm OK with moving each module to its own directory. Now, we need someone who can extend the dir.php to be more thourough (eg. and move some css / js). I'd like to see someone take action, rather than discussing this to death. If you have an interest in this, please step forward, open an issue on drupal.org and start sharing dir.php's. :) One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it. The advantages: * Easier for designers; just copy the template file. * We're forced do a better job separating code and markup. * Smaller modules and reducing memory footprint as the theme functions are only loaded on demand. The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines. -- Dries Buytaert :: http://buytaert.net/
On May 4, 2006, at 4:29 AM, Dries Buytaert wrote:
Now, we need someone who can extend the dir.php to be more thourough (eg. and move some css / js). I'd like to see someone take action, rather than discussing this to death.
whenever someone's getting ready to actually commit any of this to CVS, i'd encourage you to do the steps i outlined in a previous post. as promised, here's a copy of the script i have to do this (care of one of my co-workers, an amazingly helpful and knowledgeable faculty member at UW-Madison by the name of Marv Solomon): http://dwwright.net/cvs_rename again, i'd be happy to answer any questions if you don't follow what it's doing. however, the comments at the top of the script are verbose and clear, so that's probably all you need. enjoy, -derek (dww)
Derek Wright wrote:
On May 4, 2006, at 4:29 AM, Dries Buytaert wrote:
Now, we need someone who can extend the dir.php to be more thourough (eg. and move some css / js). I'd like to see someone take action, rather than discussing this to death.
whenever someone's getting ready to actually commit any of this to CVS, i'd encourage you to do the steps i outlined in a previous post. as promised, here's a copy of the script i have to do this (care of one of my co-workers, an amazingly helpful and knowledgeable faculty member at UW-Madison by the name of Marv Solomon):
Thanks, Derek, while I don't have much of an opinion wrt own directories for modules, I think that keeping the cvs history is essential. If/when this is approved, I'd like to work with you to properly migrate this stuff. Cheers, Gerhard
On 04 May 2006, at 1:29 PM, Dries Buytaert wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines.
Most of the other theme engines are just copy pastes of phptemplate, re-implementing one or two functions. I'll glady step up and work on the compatibility of theme engines , and the interoperability with standard drupal themes (although in reality, everything will work as before). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines. Most of the other theme engines are just copy pastes of phptemplate, re-implementing one or two functions.
I'll glady step up and work on the compatibility of theme engines , and the interoperability with standard drupal themes (although in reality, everything will work as before).
It would be good if someone could look into this, and maybe tried to make a script to auto-extract the theme_ functions and convert them to .tmp.php files. Like that, we could mess around with it and see if it works or not. Takers? -- Dries Buytaert :: http://buytaert.net/
It would be great if we added the necessary phpdoc at same time so that all themeable functions could be listed at drupaldocs. On 5/4/06 8:26 AM, "Dries Buytaert" <dries.buytaert@gmail.com> wrote:
The disadvantages: * PHPTemplate would become more dominant. It's not clear how this can co-exist with other theme engines. Most of the other theme engines are just copy pastes of phptemplate, re-implementing one or two functions.
I'll glady step up and work on the compatibility of theme engines , and the interoperability with standard drupal themes (although in reality, everything will work as before).
It would be good if someone could look into this, and maybe tried to make a script to auto-extract the theme_ functions and convert them to .tmp.php files. Like that, we could mess around with it and see if it works or not. Takers?
-- Dries Buytaert :: http://buytaert.net/
On 04 May 2006, at 2:26 PM, Dries Buytaert wrote:
It would be good if someone could look into this, and maybe tried to make a script to auto-extract the theme_ functions and convert them to .tmp.php files. Like that, we could mess around with it and see if it works or not. Takers? The big issue is still naming the parameters. They are currently named in the function call.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
Most of the other theme engines are just copy pastes of phptemplate, re-implementing one or two functions.
I'll glady step up and work on the compatibility of theme engines , and the interoperability with standard drupal themes (although in reality, everything will work as before).
I like this idea. 1) Including lots of templates might be a performance drain; I've already done some experiments that show that even with an opcache, more PHP files with small amounts of code is significantly slower to process than 1 PHP file with lots of code. Though I think this could be rectified with a PHPTemplateCompiled engine, where the compiler extracts all of the files necessary and puts them into a single template file. This would have an advantage of making design easier by separating the templates, but impacting the performance much less...but it does have the disadvantage of the compiling process being a disconnect between modifying and using. Still, I think there could be some value here. 2) This fits nicely with the views template system where I have specifically named templates for each view, and I've heard wind that other modules are using similar systems -- it's really very much the same as node-page.tpl.php and in this future templating system, would likely work the same way. 3) There's no reason that we can't require future engines to all parse PHP template files *as well as* whatever their own template infrastructure wants; at that point, alternative template engines (smarty, xtemplate, for example) can simply provide their own versions of the templates. However, we need to be very careful to not include code in our templates at that point.
1) Including lots of templates might be a performance drain; I've already done some experiments that show that even with an opcache, more PHP files with small amounts of code is significantly slower to process than 1 PHP file with lots of code. Though I think this could be rectified with a PHPTemplateCompiled engine, where the compiler extracts all of the files necessary and puts them into a single template file. This would have an advantage of making design easier by separating the templates, but impacting the performance much less...but it does have the disadvantage of the compiling process being a disconnect between modifying and using. Still, I think there could be some value here. +++ as long as it is an optional feature, in some hosting environments you don't have write access to fs
On Thu, 2006-05-04 at 16:02 +0100, Vladimir Zlatanov wrote:
1) Including lots of templates might .....Still, I think there could be some value here. +++ as long as it is an optional feature, in some hosting environments you don't have write access to fs Then again, there is always the database....
On 04 May 2006, at 5:03 PM, Vladimir Zlatanov wrote:
On Thu, 2006-05-04 at 16:02 +0100, Vladimir Zlatanov wrote:
1) Including lots of templates might .....Still, I think there could be some value here. +++ as long as it is an optional feature, in some hosting environments you don't have write access to fs Then again, there is always the database....
And then there's the other wonderful thing about having template files. We can finally write a cohesive template editor. Have a templates table, that allows you to cache / override the templates. From within the browser. Every template knows what variables it will get, we can provide 'defaults' for preview purposes, and we can create a really kickass node creation system, possibly even with tinymce integration and the like. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Vladimir Zlatanov wrote:
1) Including lots of templates might be a performance drain; I've already done some experiments that show that even with an opcache, more PHP files with small amounts of code is significantly slower to process than 1 PHP file with lots of code. Though I think this could be rectified with a PHPTemplateCompiled engine, where the compiler extracts all of the files necessary and puts them into a single template file. This would have an advantage of making design easier by separating the templates, but impacting the performance much less...but it does have the disadvantage of the compiling process being a disconnect between modifying and using. Still, I think there could be some value here.
+++ as long as it is an optional feature, in some hosting environments you don't have write access to fs
Indeed, that is exactly why I suggest creating it as a completely separate engine. Though as I think on it, the current setup doesn't support running the same theme with multiple engines, that I'm aware of. I'm not actually sure.
+++ as long as it is an optional feature, in some hosting environments you don't have write access to fs
Indeed, that is exactly why I suggest creating it as a completely separate engine. Though as I think on it, the current setup doesn't support running the same theme with multiple engines, that I'm aware of. I'm not actually sure. It can shadow the main engine, something like an optional switch, if it is there, it overrides the default engine. It shouldn't that difficult, since we already have the layered approach anyway.
Indeed, that is exactly why I suggest creating it as a completely separate engine. Though as I think on it, the current setup doesn't support running the same theme with multiple engines, that I'm aware of. I'm not actually sure.
The point of my original e-mail is that for such a system to be successful, it needs to be default. If theme_ functions remain the default fallback mechanism, we don't get the full advantage (eg. the modules and memory footprint won't go down) making it a lot less attractive. In fact, things would get worse, as we'd need to duplicate the theme_ functions as stand-alone templates (eg. creating maintenance overhead). -- Dries Buytaert :: http://buytaert.net/
Dries Buytaert wrote:
Indeed, that is exactly why I suggest creating it as a completely separate engine. Though as I think on it, the current setup doesn't support running the same theme with multiple engines, that I'm aware of. I'm not actually sure.
The point of my original e-mail is that for such a system to be successful, it needs to be default. If theme_ functions remain the default fallback mechanism, we don't get the full advantage (eg. the modules and memory footprint won't go down) making it a lot less attractive. In fact, things would get worse, as we'd need to duplicate the theme_ functions as stand-alone templates (eg. creating maintenance overhead).
I think there's a miscommunication; I was referring to a different engine that is a mirror of PHPTemplate, but does the compiling; I agree that the template structure needs to be default, and Adrian was pointing out that most of PHPTemplate can easily be pulled into core, and still leave the part that actually interprets the template to the engine. PHPTemplate would then, by itself, be very very short, since it'd just execute the templates. PHPTemplateCompiled (or whatever; this name is bad, but it's all I got right now) would be longer since it'd have to support a compile function and be able to bring in all of the templates that are used.
On Thu, 2006-05-04 at 17:49 +0200, Dries Buytaert wrote:
Indeed, that is exactly why I suggest creating it as a completely separate engine. Though as I think on it, the current setup doesn't support running the same theme with multiple engines, that I'm aware of. I'm not actually sure.
The point of my original e-mail is that for such a system to be successful, it needs to be default. If theme_ functions remain the default fallback mechanism, we don't get the full advantage (eg. the modules and memory footprint won't go down) making it a lot less attractive. In fact, things would get worse, as we'd need to duplicate the theme_ functions as stand-alone templates (eg. creating maintenance overhead).
Hmm, you are right that having lots of files creates a different kind of maintenance problems. The pros, are all (or most) design related and the fact that php doesn't need to compile and keep in memory unused code. The cons, load/search times might increase. Maybe the maintenance overhead. Duplication will be a bad thing in any case. But again, the current theme_ functions are hard(ish) to maintain. Remember how long it took to get rid of the various accessibility and xhtml compatibity annoyances. If we have a robust caching solution, that essentially replicates the current fallback layout, for example something like the engine Earl suggests, we can go forward in both cases. My concern with that is that it requires an extra step. Another option is to go for a slow default. Weighted engines, with one of them a default. It could be the pure php thing, with only one .template file, or similar. And allow for custom speedups and caching.
On 04 May 2006, at 18:15, Vladimir Zlatanov wrote:
The cons, load/search times might increase. Maybe the maintenance overhead.
Various people claim that the theme_ functions are necessary to get the best performance out of Drupal. Frankly, I'm not convinced that is true. If we go all the way and remove the theme functions from the .module files, the PHP engine will have a lot less code to parse. Take a moment to think about it. It is kind of a clean (but less aggressive) implementation of Karoly's "split mode" patch. Karoly claims that "split mode" gives him an average performance gain of 40% as well as significant memory reductions. Maybe someone can modify Karoly's split mode patch (so that it only splits out the theme_ functions), merge it with dir.php, and give it a go? It would be different from the final implementation, but it would give us a pretty accurate indication as to whether we need to keep the theme_ functions or not. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
On 04 May 2006, at 18:15, Vladimir Zlatanov wrote:
The cons, load/search times might increase. Maybe the maintenance overhead.
Various people claim that the theme_ functions are necessary to get the best performance out of Drupal. Frankly, I'm not convinced that is true.
If we go all the way and remove the theme functions from the .module files, the PHP engine will have a lot less code to parse. Take a moment to think about it. It is kind of a clean (but less aggressive) implementation of Karoly's "split mode" patch. Karoly claims that "split mode" gives him an average performance gain of 40% as well as significant memory reductions.
Maybe someone can modify Karoly's split mode patch (so that it only splits out the theme_ functions), merge it with dir.php, and give it a go? It would be different from the final implementation, but it would give us a pretty accurate indication as to whether we need to keep the theme_ functions or not.
Indeed, some benchmarks would be nice instead of pushing our gut feelings head to head :) Goba
-----Original Message----- One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it. -------------------------- Errrr... I'm assuming you mean that *all* a module's theme functions would be in a theme file, or somesuch? As opposed to EACH theme function being in a separate file? I have a number of modules that have numberous tiny theme functions that work together, any of which can be overridden. Should I be consolidating them? --Jeff
On 04 May 2006, at 2:36 PM, Jeff Eaton wrote:
Errrr... I'm assuming you mean that *all* a module's theme functions would be in a theme file, or somesuch? As opposed to EACH theme function being in a separate file? I have a number of modules that have numberous tiny theme functions that work together, any of which can be overridden. Should I be consolidating them?
No. each theme function in a separate file. This makes it far easier to override them. Also. phptemplate has a very useful piece of functionality that makes it test for other templates first. ie: node-<type>.tpl.php Perhaps you could even use that to make your overridability make more sense. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Thursday 04 May 2006 04:29 am, Dries Buytaert wrote:
One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it.
Wow. I have been working on something rather similar to this. For the last couple of months, as I have had the time, I've been working on a theme that has as one of it's features all of it's theme related stuff (but not including theme_ functions from the modules themselves) in separate .css and .tpl.php files per module or node type. I have so far only been working on core modules, but I did have in mind to include some of the more popular contrib modules later on. The reasoning behind it for me is that I wanted to create a them that I could use on multiple projects where I could easily modify the areas that needed modification and not have the other code be in the way. If I'm not using the forum module, then I don't have the forum markup to deal with. If I am using the forum module, then all the relevant markup is in one place and easy to find and modify. -- Jason Flatt http://www.oadae.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/
One of the things I'd like to see happen, is that we move away from the theme_ functions, and that we make PHPTemplate files for each theme function. So, if you are a designer and you want to theme a part of Drupal, you just copy the template from module/foo/bar.tpl.php to your theme directory, and you start hacking away at it.
I'm all for it, but as long as we can still do things the old way. For me, having 50 less-than-10-line theme files in a directory is garbage: I'd much rather stick them into just one file - it makes editing easier for *me*. I'd be happy if both ways were supported. In some cases, my theme overrides are three lines - such as ignoring the long parameter on the filter tips. Having that in a single file is insulting. Will both still be possible? -- Morbus Iff ( oh, i wish i was a hoggle ) 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 04 May 2006, at 4:22 PM, Morbus Iff wrote:
I'm all for it, but as long as we can still do things the old way. For me, having 50 less-than-10-line theme files in a directory is garbage: I'd much rather stick them into just one file - it makes editing easier for *me*. I'd be happy if both ways were supported.
Benton:~/dev/drupal-stable/modules adrian$ grep "function theme_*" * | wc 63 256 3959 50 theme files for a module would be wrong. The most is the comment module. and that's likely due to the alternate renderings. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 04 May 2006, at 4:48 PM, Adrian Rossouw wrote:
Benton:~/dev/drupal-stable/modules adrian$ grep "function theme_*" * | wc 63 256 3959
I missed out on includes. Which is another 64 lines. I'm wondering though how long the average theme function is. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Benton:~/dev/drupal-stable/modules adrian$ grep "function theme_*" * | wc 63 256 3959
50 theme files for a module would be wrong. The most is the comment module.
That's core only. Granted, I just argued a bit ago about "new features should only be thought about in regards to core", but /me whines. <g> -- Morbus Iff ( masochism-oriented recombinant bot (unlisted series) ) 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 May 2, 2006, at 12:19 PM, Neil Drumm wrote:
- I would do things as I usually do with CVS- mv; cvs rm; cvs add. Then someone would yell at me for losing the history.
the really nice thing about the way drupal needs to rely on CVS for this is that there's no external dependency on the locations of these files that also needs to be tracked in CVS. most software projects can't just rename source files without also changing a Makefile somewhere (for example), which makes CVS's limitations in this regard more of a show-stopper. however, since there's no Makefile, and the core code will search for book.module in either modules/book.module or in modules/book/book.module, nothing needs to know when we rename these files (other than the humans involved). so, you don't have to loose any history at all. here's the (sneaky, don't-try-this-at-home) approach that you could use. this requires shell access to the repository, so it's really something only killes or dries could do. 1) go into the actual repository directory for "drupal/modules" 2) mkdir book 3) cp book.module book 4) [pseudo]: foreach tag on modules/book.module { cvs rtag -dB $tag modules/book/book.module } 5) in a workspace checked out from head: - rm modules/book.module - cvs rm modules/book.module - cvs commit -m "moved book.module into modules/book" modules/book.module obviously, you'd need to repeat these 5 steps for each module you want to move. step #4 is important, so that if someone does "cvs co -r DRUPAL-4-7 drupal", they don't get duplicate copies of everything. however, it's a big potential time-sink, too. i've got a script somewhere that automates this, which i could dig out, polish off, and give to whomever wants to do this task if you're interested in going this route. i'd be happy to answer any questions about all this, if anyone's confused as to what i'm describing here.
- It kinda feels like shuffling the files around for the sake of shuffling. Maybe this should be coupled with something I talked with Kieran about last friday, help in separate human-readable files instead of PHP. The other option of course is making .install files for core modules, but I think thats less doable.
yeah, i can see some good reasons to do all this, but until we've hit one and are actively ready to use it, i'd vote against doing the reshuffling just yet. i think we can all agree there will be a flurry of 6.7.0 activity, and despite our best efforts, bugs. therefore, we might as well keep it easy to apply patches to both branches as long as possible. -derek (dww)
On 5/3/06, Neil Drumm <drumm@delocalizedham.com> wrote:
The other option of course is making .install files for core modules, but I think thats less doable.
I'm all for making .install files for (non-required) core modules. It means that a user can install Drupal with very few modules enabled, and they won't have a whole lot of unnecessary tables created in their database. But anyway, this should probably be held off, until after the new install / dependency / profile / etc system goes in. Jaza.
A previous discussion that points to previous discussions. http://lists.drupal.org/archives/development/2006-03/msg00134.html Ber had some great RoR inspired ideas that expanded on mine, and Morbus had some other good ideas too. The issues are: - Security (keep non data files out of DocumentRoot) - Upgradability (isolation of core Drupal from user modified files) - Easier backups (Cleaner directory structure) - Some other points mentioned in the above threads. (Normally at this point, we start seeing the "CVS sucks", "SVN is the way to go", "No bzr is ...", ...etc., but as Gabor said, it is a solved issue, so please leave those for another slower day on the mailing list.)
- Security (keep non data files out of DocumentRoot)
And as I've argued a hundred times, this is a pointless issue. -- Morbus Iff ( small pieces of morbus loosely joined ) 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 02 May 2006, at 20:32, Adrian Rossouw wrote:
We've discussed this to death during the freeze (even though we weren't supposed to), and most (if not all) the developers feel this is a good idea.
When can we get around to doing this. The biggest issue I see is that all patches for 4.7 won't apply on HEAD. That is inevitable anyway, so I think we should just go for it already. =)
1. Let's move this discussion to the issue tracker. 2. Let's make a script that allows us to "patch" our local trees so we get to play with such setup. 3. Let's postpone this as long as possible so we don't break all patches that have been waiting for a review. -- Dries Buytaert :: http://www.buytaert.net/
participants (26)
-
Adrian Rossouw -
Bèr Kessels -
Darrel O'Pry -
Derek Wright -
Derek Wright -
Dries Buytaert -
drupal -
Earl Miles -
Gabor Hojtsy -
Gerhard Killesreiter -
introfini -
James Gilliland -
Jason Flatt -
Jeff Eaton -
Jeremy Epstein -
Khalid B -
Larry Eitel -
Larry Garfield -
Morbus Iff -
Moshe Weitzman -
Nedjo Rogers -
Neil Drumm -
Robert Douglass -
Scott White -
sime -
Vladimir Zlatanov