- Development - lists.drupal.org

[drupal-devel] [bug] Theme admin fix-up after multisite patch
by jhriggs 17 Mar '05

17 Mar '05

Issue status update for http://drupal.org/node/13738 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: critical Assigned to: TDobes Reported by: TDobes Updated by: jhriggs Status: patch Attachment: http://drupal.org/files/issues/theme_settings.patch (45 bytes) This patch was applied by Dries but not marked as fixed; however, it introduced a new bug. Theme-specific settings no longer work. The attached patch fixes this. jhriggs Previous comments: ------------------------------------------------------------------------ December 1, 2004 - 02:48 : TDobes Attachment: http://drupal.org/files/issues/fix-styles-after-multisite.patch (632 bytes) There was a major theming issue I missed in my bug-testing after the multi-site patch landed. Styles now seem to have their description field filled with the filename of their parent theme/template rather than the theme_key of the parent. This is a problem because init_theme still expected to see the theme_key and therefore dropped back to the base theme (no theme at all). The attached patch fixes this situation. ------------------------------------------------------------------------ December 1, 2004 - 03:04 : TDobes Note: This might also warrant an update.inc script. Because of this change, sites that were based on styles won't load the proper theme after upgrading until the admin visits the themes administration page an clicks "save." ------------------------------------------------------------------------ December 1, 2004 - 16:41 : Dries Committed. ------------------------------------------------------------------------ March 15, 2005 - 16:03 : TDobes Attachment: http://drupal.org/files/issues/themes-bugfix_and_cleanup.patch (8.77 KB) I did a bit more testing of the theme administration in 4.6 and found a few items that needed improvement. The attached patch fixes a couple bugs, removes some code rot, and cleans up the code a bit: * Fix a bug which would cause the "configure" link for styles to be broken. (missed this in the last patch) * Fix a bug with using drupal_get_filename for theme engines. Although this is not called anywhere in core, we should still fix it for contrib. (i.e. themes that may want to manually invoke a theme engine to create a hybrid theme) * Correct an inaccurate comment in theme.inc * Populate the default primary links with an "edit primary links" link for consistency with the secondary links * remove some unnecessary variables in the theme administration which had misleading and confusing names * replace time-consuming foreach when rendering theme admin page with a more efficient array_key_exists * usability: rather than completely removing the search box checkbox when search.module is disabled, simply disable it. (UI elements shouldn't appear/disappear.) Please commit and/or review prior to 4.6 release.

1 0

[drupal-devel] Script to check contib module compatibility
by neil＠civicspacelabs.org 17 Mar '05

17 Mar '05

Would anyone be interested in a script to automatically test if a module is 4.6-compliant? I want to get some feedback before potentially comitting to writing it. It would need two levels of output: Warning: a module implements a hook which changed. Without creating a unit test framework there is no easy way to determine if a module works or not. Error: a module implements a removed function or calls a function with the wrong arguments? What other test cases are posssible? Would anyone want to help? -Neil

2 1

Re: [drupal-devel] CivicSpace development moving to Drupal
by Boris Mann 16 Mar '05

16 Mar '05

On Tue, 15 Mar 2005 17:49:01 -0800, neil(a)civicspacelabs.org <neil(a)civicspacelabs.org> wrote: > - To properly release the configure [1] module it will need about 2/3 of > the code pushed into individual modules using a new hook. We should > have a debate about this going into Drupal core at some point. It > could easily live as a contrib module, but I think we need to take a > step back and think about how module installation works. > - Install.php [6] is a heavily branded and Postgres incompatible moving > target. Who is interested in helping get this into Drupal? I know > people who want to make Drupal easier to install are out there. We've already said to CS that we want to work with them to integrate configure, install.php, and Adrian's work on installation. Tell us when you (Neil/CS) have time, so we can make the time for Adrian to work on it. And of course, anyone else in the community that wants to work on it. Ditto for Survey/Forms, since James has done the work on that. Long term, we'd love to see survey.module (and potentially a registration.module as well, and quiz.module too?) become really powerful components. A good forms library is a necessity for this. Do these forms intersect in any way with either the profile fields and/or CCK? -- Boris Mann http://www.bryght.com

2 1

[drupal-devel] subsite - sharing codebase - doesn't work as expected
by Ross Kendall 16 Mar '05

16 Mar '05

Is it just me? Drupal doesn't seem to be picking up 'settings.php' files for subdirectories... I hadn't really used the multiple 'settings.php' ability, so I thought I would give it a test out by trying to set up a main drupal site, with a subsite that shared the Drupal codebase, (and the database tables for sharing users). This didn't work as expected. In fact Drupal did not want to recognise a 'settings.php' file for a subdirectory of the main site. My test is here: http://drupal-test.rosskendall.com/ (plain CVS install - done today) which uses 'sites/drupal-test.rosskendall.com/settings.php' However, when I create this settings file: 'sites/drupal-test.rosskendall.com.subsite2/settings.php' in an attempt to create a separate Drupal site that uses the same codebase, here: http://drupal-test.rosskendall.com/subsite2/ ...it does not even recognise the settings file. Obviously I'm not very familiar with this feature, but I do suspect that something is broken, because it does not do 'what it says on the can'. Any insights? Or can anyone confirm this is not working as it should? Cheers, Ross.

6 10

RE: [drupal-devel] CivicSpace Labs launches new beta site
by Steven Peck 16 Mar '05

16 Mar '05

There is text to speech software setups that allow blind people to use IE as their browser. My cousin and her husband (both blind) use such a setup. The turn off images in browsers. -sp > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Chris Messina > Sent: Saturday, March 12, 2005 3:04 PM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] CivicSpace Labs launches new beta site > The other thing you mentioned about turning off images is something I > hadn't really considered. It's a problem for text replacement, for > sure, but I wonder how many people browse with images turned off. I > certainly know it happens -- I just wonder whether it's worth > investing much time in. > > > Chris > >

4 3

[drupal-devel] Taxonomy > Vocabulary > "Preview Form"?
by Morbus Iff 16 Mar '05

16 Mar '05

What's the whole point of this feature? I just noticed that I'll have to fiddle around with that code so it'll properly display an input box on "community" vocabularies. But, I'm now curious WHY this feature is even there. Seems pretty dumb. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

3 2

[drupal-devel] files folder error
by Anisa 16 Mar '05

16 Mar '05

So, basically, since I know no one here likes long irrelevent stories, I would like to know why there isn't anything in the install file about making the 'files' folder... apparently it must be necessary, because you get a big red: The directory files does not exist. error. (Drupal 4.5.2 has this changed in 4.6?) It's not quite documentation, and I know what to do about it so it's not support. Just askin'. :) Anisa.

12 25

[drupal-devel] [bug] Current forum title not being updated properly during navigation
by Periastron 16 Mar '05

16 Mar '05

Issue status update for http://drupal.org/node/18927 Project: Drupal Version: cvs Component: forum.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Periastron Updated by: Periastron -Status: active +Status: patch Hi, just changing the status to call attention to the fact that a patch is attached to my original report. Periastron Previous comments: ------------------------------------------------------------------------ March 15, 2005 - 09:46 : Periastron Attachment: http://drupal.org/files/issues/forum_9.patch (621 bytes) In 4.6.0 RC, there appears to be a slight regression in the display of the current forum title. As one navigates down through the forum taxonomy, the title used to change to the current term, but now it always just displays the vocabulary name. I have attached a patch that restores the previous behaviour. It looks like the regression may have been introduced in some changes to theme_forum_display.

1 0

[drupal-devel] [bug] image.gd.inc isn't compatible with gd 1
by walkah 16 Mar '05

16 Mar '05

Issue status update for http://drupal.org/node/18700 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: stefan nagtegaal Reported by: stefan nagtegaal Updated by: walkah Status: patch Hey guys, sorry I've been silentlly watching this thread. Here's my take: +1 - I like the approach, and I agree that (especially now that we're requiring 4.3.x) making the "default" support gd2 only isn't a bad idea. I'm working on some additions to this patch, however, to basically make the toolkit checking a bit more robust (working on top of Stefan's). Great job Stefan, keep it up! walkah Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 13:13 : stefan nagtegaal The idea behind the image.gd.inc file is that it should be usable for people who are using GD 1 and GD 2. Unfortunatly, the way it is written now, only support for GD 2 can be given because: Current way of determining GD 2, is not right: if (function_exists('imageCreateTrueColor')) { // GD 2 Handling; } else { // GD 1 Handling } this doesn't work.. imageCreateTrueColor() was already implemented in GD 1, only it failed to work properly.. See these pages: http://www.php.net/imagecratetruecolor#25234 & http://www.php.net/imagecratetruecolor#25487 According to this comments, we should implement this like this: // Silence errors using the @ $image = @imageCreateTrueColor(......); if (!$image) { // GD 1 Handling; } ------------------------------------------------------------------------ March 11, 2005 - 13:03 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc.patch (2.26 KB) Attached patch improves: - the way which deals with the detection of GD 1 or GD 2; - error messages as reported by Steven here: http://drupal.org/node/17645; After applying this to HEAD/Drupal 4.6 RC, we can close the following issues: - http://drupal.org/node/17645; - http://drupal.org/node/13027; Please test/comment and apply attached patch.. ------------------------------------------------------------------------ March 12, 2005 - 03:41 : Dries Isn't the approach taking in http://drupal.org/node/13027 nicer? It doesn't surpress warnings/errors. Maybe that approach doesn't work? ------------------------------------------------------------------------ March 12, 2005 - 03:50 : Bèr Kessels -1 on supressing errors with @. Its ugly, and hardly used in Drupal. We should use our own error handling at all times. ------------------------------------------------------------------------ March 12, 2005 - 04:42 : stefan nagtegaal I will make a new patch, with the more elegant approach you mentioned Dries... ------------------------------------------------------------------------ March 12, 2005 - 12:05 : stefan nagtegaal As noticed before in this issue.. The function imageCreateTrueColor _does_ exist, even in versions of GD before 1.8 only it was broken.. So, function_exist() doesn't work on that the function, because it really _does_ exist, but the fact is that it's simply broken.. So unfortunatly, the more elegant solution doesn't seem to work.. ------------------------------------------------------------------------ March 12, 2005 - 13:01 : pz Stupid question, why not just use the gd_info function? ------------------------------------------------------------------------ March 13, 2005 - 03:54 : Dries What versions of PHP have those old GD toolkits? PHP 4.3.10 comes with GD 2.0.28, it seems, as does PHP 5.0.3. PHP 4.3.3, Drupal's current minimum PHP requirement, comes with GD 2.0.15. >From the looks, we don't need GD 1 handling at all ... (but we might need a global version check). Thoughts? ------------------------------------------------------------------------ March 13, 2005 - 05:32 : stefan nagtegaal PHP 4.1.2 comes with GD 1.62.. The nasty/hackish code with the build-in GD toolkit, is exactly why I proposed to split the image.inc into a separate image.gd1.inc and image.gd2.inc. I would propose a patch which does: - remove all the GD < 2 function calls like imageCreate() and imageCopyResized() and have a real GD 2 compatible image.inc; - introduce a new image.gd1.inc file into Walkahs sandbox; If the module is being moved to the contributions, the image.gd1.inc is also available for people without proper GD 2 support; - more userfriendly and helpfull error reporting for the image-api.. If we agree about this, I'll make patches for inclusion into 4.6.. Which does contain the before mentioned problems with the current usage.. Please, I would like to have some feedback about this... ------------------------------------------------------------------------ March 13, 2005 - 07:55 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image-inc_0.patch (2.99 KB) As proposed above, patch for image.inc.. Please comment or apply... The image.gd1.inc file wil be posted after this post... ------------------------------------------------------------------------ March 13, 2005 - 07:57 : stefan nagtegaal Attachment: http://drupal.org/files/issues/image.gd1.inc (2.07 KB) And the image.gd1.inc file for Walkahs sandbox... Tell me what you all think about this.. ------------------------------------------------------------------------ March 13, 2005 - 10:11 : Dries I'm OK with this! I'd like to await James' input though. ------------------------------------------------------------------------ March 15, 2005 - 05:16 : stefan nagtegaal Walkah, are you out there??? Ber, do you agree with Dries that this is a better approach? ------------------------------------------------------------------------ March 15, 2005 - 06:15 : Bèr Kessels I like this approach because it: uses a good default, and uses that well. Provides flexibility for those not wanting that default, without extra complexity. Uses modules to add extra functionality instead of configuration options. big +1 from me.

1 0

[drupal-devel] [bug] minor oddity in code. unneeded concenation
by Bèr Kessels 16 Mar '05

16 Mar '05

Issue status update for http://drupal.org/node/18983 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: minor Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/user.module_15.diff (544 bytes) This tiny patch fixes a tiny issue. I stumbled upon it when debugging my installation. Bèr Kessels

1 0