- Development - lists.drupal.org

[drupal-devel] Cache sid
by Julian Bond 02 Mar '05

02 Mar '05

I have a test drupal 4.51 at http://localhost/bikeweb So in conf.php I have $base_url = "http://localhost/bikeweb"; In bootstrap.inc function page_set_cache() cached pages are saved at $base_url . request_uri() and Apache is reporting via function request_uri() $_SERVER['REQUEST_URI'] = '/bikeweb/' So the cached page gets set in the cache table with a cid of http://localhost/bikeweb/bikeweb/ if the cache has to be rebuilt, I then start getting assorted errors because the path is now wrong. This doesn't look right to me although it will only fail on installations that are not in the root of the url. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/

7 16

[drupal-devel] [bug] Putting a .theme file into themes/ makes all themes not working
by chx 02 Mar '05

02 Mar '05

Issue status update for http://drupal.org/node/16914 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch - That should probably be an error message, rather than a status (success) message. Ah, I was never aware of the second parameter of drupal_set_message! One always learns. - The coding style needs work. Spaces, my doom :( - For consistency the theme name should be wrapped in em's. Understood. - I'd prefer not to scan ./themes for .theme files and to ignore any .theme files places directly in ./themes. Well. Only a system_listing call happens before my patch in system_theme_data. All system_listing does it sets up a maximum of two starting points for a recursive file_scan_directory ($directory and $config/$directory) and file_scan_directory has no options for such an exclusion and it does not seem appropriate to change file_scan_directory only for this. Surely I miss something in here, but I still think that this special thing shall be done in system_theme_data. If this is accepted, the minor (from a coding point of view they are minor) issues will be corrected in no time. chx Previous comments: ------------------------------------------------------------------------ February 7, 2005 - 08:13 : chx Try putting a .theme file into themes/ without any subdir. Enable it (maybe just saving theme settings is enough), Nothing will work after this. To restore your site: remove the offending theme, issue an SQL: DELETE FROM {system} WHERE type='theme' and save theme settings again. ------------------------------------------------------------------------ February 7, 2005 - 08:14 : chx effects HEAD, too. ------------------------------------------------------------------------ February 7, 2005 - 13:33 : chx Attachment: http://drupal.org/files/issues/themesfix.patch (542 bytes) Here is a patch which fixes the problem. However, I do not have the feeling that this is "the" solution. Feel free to come up with something better. ------------------------------------------------------------------------ February 7, 2005 - 13:35 : chx Oops forgot to set to CVS, 'cos the fix is against HEAD. Not that 4.5.2 does not need a patch... ------------------------------------------------------------------------ February 7, 2005 - 22:15 : Anonymous While this patch would allow a theme to be placed directly in the "themes" directory, it disables the ability for that theme to use a "style.css" file, which is inconsistent. I would prefer a patch that enforces the criteria that themes MUST be placed in a SUBDIRECTORY of "themes" -- themes placed directly in the "themes" folder should be ignored... maybe we could send the admin a drupal_set_message that would tell them about the problem when visiting admin/themes too. ------------------------------------------------------------------------ February 23, 2005 - 00:07 : chx Attachment: http://drupal.org/files/issues/themefix.patch (693 bytes) Anonymous is right. I have made a better patch. Please commit, this is very important IMHO. ------------------------------------------------------------------------ February 23, 2005 - 00:30 : chx Attachment: http://drupal.org/files/issues/themefix_1.patch (712 bytes) Message was wrong. ------------------------------------------------------------------------ March 2, 2005 - 00:26 : chx May I know why this is not getting commited? This is a very nasty issue, the poor site admin who tries a few themes and misplaces one is totally baffled why his themes do not work after this. ------------------------------------------------------------------------ March 2, 2005 - 09:26 : Dries - That should probably be an error message, rather than a status (success) message. - The coding style needs work. - For consistency the theme name should be wrapped in em's. - I'd prefer not to scan ./themes for .theme files and to ignore any .theme files places directly in ./themes. Won't commit as is.

1 0

[drupal-devel] [bug] Putting a .theme file into themes/ makes all themes not working
by Dries 02 Mar '05

02 Mar '05

Issue status update for http://drupal.org/node/16914 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: Dries Status: patch - That should probably be an error message, rather than a status (success) message. - The coding style needs work. - For consistency the theme name should be wrapped in em's. - I'd prefer not to scan ./themes for .theme files and to ignore any .theme files places directly in ./themes. Won't commit as is. Dries Previous comments: ------------------------------------------------------------------------ February 7, 2005 - 09:13 : chx Try putting a .theme file into themes/ without any subdir. Enable it (maybe just saving theme settings is enough), Nothing will work after this. To restore your site: remove the offending theme, issue an SQL: DELETE FROM {system} WHERE type='theme' and save theme settings again. ------------------------------------------------------------------------ February 7, 2005 - 09:14 : chx effects HEAD, too. ------------------------------------------------------------------------ February 7, 2005 - 14:33 : chx Attachment: http://drupal.org/files/issues/themesfix.patch (542 bytes) Here is a patch which fixes the problem. However, I do not have the feeling that this is "the" solution. Feel free to come up with something better. ------------------------------------------------------------------------ February 7, 2005 - 14:35 : chx Oops forgot to set to CVS, 'cos the fix is against HEAD. Not that 4.5.2 does not need a patch... ------------------------------------------------------------------------ February 7, 2005 - 23:15 : Anonymous While this patch would allow a theme to be placed directly in the "themes" directory, it disables the ability for that theme to use a "style.css" file, which is inconsistent. I would prefer a patch that enforces the criteria that themes MUST be placed in a SUBDIRECTORY of "themes" -- themes placed directly in the "themes" folder should be ignored... maybe we could send the admin a drupal_set_message that would tell them about the problem when visiting admin/themes too. ------------------------------------------------------------------------ February 23, 2005 - 01:07 : chx Attachment: http://drupal.org/files/issues/themefix.patch (693 bytes) Anonymous is right. I have made a better patch. Please commit, this is very important IMHO. ------------------------------------------------------------------------ February 23, 2005 - 01:30 : chx Attachment: http://drupal.org/files/issues/themefix_1.patch (712 bytes) Message was wrong. ------------------------------------------------------------------------ March 2, 2005 - 01:26 : chx May I know why this is not getting commited? This is a very nasty issue, the poor site admin who tries a few themes and misplaces one is totally baffled why his themes do not work after this.

1 0

[drupal-devel] Comments count and tracking still broken
by Abalieno 02 Mar '05

02 Mar '05

Just FYI. The last acknowledgment I know is here: http://drupal.org/node/15500 It's marked as fixed but on my site is not. The current broken state is on drupal 4.5.2 and applying the patch posted by Zed Pobre. The comments count still doesn't get updated properly and I have to re-run the update to the database each time to get the comments count right. This happens on my site and with anonymous comments. Comments must be approved by me before they appear, but even when they are published their count isn't updated on the homepage and on the tracker module. I do not use caching options. -HRose / Abalieno

2 4

[drupal-devel] Silly Question
by Andre Molnar 02 Mar '05

02 Mar '05

Can someone decipher the TLA (three letter acronym) CCK for me? andre

3 3

[drupal-devel] [bug] aggregator_block needs $delta=0
by cprice 02 Mar '05

02 Mar '05

Issue status update for http://drupal.org/node/18231 Project: Drupal Version: cvs Component: aggregator.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: cprice Updated by: cprice Status: patch Attachment: http://drupal.org/files/issues/aggregator_block.patch (697 bytes) In aggregator.module, the aggregator_block needs $delta default set to 0. Attached patch fixes problem. cprice

1 0

[drupal-devel] [bug] node_add disregards menu access settings
by javanaut 02 Mar '05

02 Mar '05

Issue status update for http://drupal.org/node/18221 Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: normal Assigned to: javanaut Reported by: javanaut Updated by: javanaut Status: patch Attachment: http://drupal.org/files/issues/node_add_menu_security.patch (949 bytes) node/add lists out all modules on the site that the user has permission to create. This list should additionally check that the node/add/$type menu path is accessible, otherwise, the page generates dead links to these inaccessible paths. I've attached a patch that adds this check to the node_add function when no $type is specified. javanaut

1 1

[drupal-devel] [bug] Putting a .theme file into themes/ makes all themes not working
by chx 02 Mar '05

02 Mar '05

Issue status update for http://drupal.org/node/16914 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: chx Reported by: chx Updated by: chx Status: patch May I know why this is not getting commited? This is a very nasty issue, the poor site admin who tries a few themes and misplaces one is totally baffled why his themes do not work after this. chx Previous comments: ------------------------------------------------------------------------ February 7, 2005 - 08:13 : chx Try putting a .theme file into themes/ without any subdir. Enable it (maybe just saving theme settings is enough), Nothing will work after this. To restore your site: remove the offending theme, issue an SQL: DELETE FROM {system} WHERE type='theme' and save theme settings again. ------------------------------------------------------------------------ February 7, 2005 - 08:14 : chx effects HEAD, too. ------------------------------------------------------------------------ February 7, 2005 - 13:33 : chx Attachment: http://drupal.org/files/issues/themesfix.patch (542 bytes) Here is a patch which fixes the problem. However, I do not have the feeling that this is "the" solution. Feel free to come up with something better. ------------------------------------------------------------------------ February 7, 2005 - 13:35 : chx Oops forgot to set to CVS, 'cos the fix is against HEAD. Not that 4.5.2 does not need a patch... ------------------------------------------------------------------------ February 7, 2005 - 22:15 : Anonymous While this patch would allow a theme to be placed directly in the "themes" directory, it disables the ability for that theme to use a "style.css" file, which is inconsistent. I would prefer a patch that enforces the criteria that themes MUST be placed in a SUBDIRECTORY of "themes" -- themes placed directly in the "themes" folder should be ignored... maybe we could send the admin a drupal_set_message that would tell them about the problem when visiting admin/themes too. ------------------------------------------------------------------------ February 23, 2005 - 00:07 : chx Attachment: http://drupal.org/files/issues/themefix.patch (693 bytes) Anonymous is right. I have made a better patch. Please commit, this is very important IMHO. ------------------------------------------------------------------------ February 23, 2005 - 00:30 : chx Attachment: http://drupal.org/files/issues/themefix_1.patch (712 bytes) Message was wrong.

1 0

[drupal-devel] [feature] Editable node descriptions
by drumm 01 Mar '05

01 Mar '05

Project: Drupal Version: cvs Component: node.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/node.module_2.diff (4.44 KB) Hey, lets make those things on the node/add page editable. And fix up some code style along the way. drumm -- View: http://drupal.org/node/17879 Edit: http://drupal.org/project/comments/add/17879

3 3

[drupal-devel] Stability of DB schema in 4.6 RC?
by Scott Courtney 01 Mar '05

01 Mar '05

Good morning, all. I'm in a quandary, and am looking for some advice from my fellow coders. My local "sandbox" of Drupal is at version 4.5.2, and needs to stay there for now because I'm actively working on two modules for the open Drupal community plus one module for my employer (nothing secret, but it's so company-specific that it's useless to the Open Source community, else I'd release it GPL). So, I haven't even touched the CVS HEAD version or played with anything at 4.6 level yet. The plan is to finish my modules at 4.5.x, then update them for 4.6, because I really want to offer them for *both* versions in production. Here's the question: I need to quickly (as in, "this week") deploy three *non-production* Drupal sub-sites under a common virtual host, or under three separate virtual hosts. The sites can be a little unstable for now, because end users won't see them for several weeks. But I do need to get them online for the content creation team to start building nodes and taxonomy. Since the sites can wait to go production, it occurs to me that it might be smarter to go ahead and put the CVS HEAD version of Drupal on there, since: 1. It would keep me from having to upgrade the DB tables later, 2. It gives me a convenient sandbox to start making my modules 4.6 compatible without breaking my existing development sandbox, 3. It lets me train the content creators (some of whom are not previously Drupal-experienced) *once*, in only the upcoming 4.6 user interface, 4. If I recall from this list, there are new features in 4.6 for the specific support of multiple logical sites with a single Drupal install -- which would greatly simplify my life. Now, being a developer, I fully realize that the 4.6 *code* isn't stable yet, may give errors or utterly crash, etc. I'm okay with that. But my question is, how stable is the *database schema* for core Drupal at this time? Are we likely to see any further table layout changes at this point, or is it *reasonably* safe to assume, "When 4.6 production comes out, I can nuke the CVS code and replace it with the released code, but won't have to modify the database?" Comments welcome, and thanks. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey

4 4