April 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Drupal forms do not validate as xhtml 1.0
by stefan nagtegaal 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/10637 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: stefan nagtegaal Status: won't fix >From 4.6 this _is_ done inside the settings.php... stefan nagtegaal Previous comments: ------------------------------------------------------------------------ September 8, 2004 - 01:18 : tangent Attachment: http://drupal.org/files/issues/form_sample.html (623 bytes) When the user is not logged in, Drupal adds a hidden input named PHPSESSID to forms. This input is misplaced according to xhtml 1.0 specs. It is currently placed immediately inside the form tag but according to the spec it must be placed in a block level tag (e.g., "p", "h1", "h2", "h3", "h4", "h5", "h6", "div", "pre", "address", "fieldset", "ins", "del"). I recommend placing this hidden input either inside it's own div element or inside the container div which contains the rest of the form. I would fix this in my theme if I could track down where this variable is added but I haven't been able to so far. I have attached an html sample with valid and invalid markup. You can run it through the W3C validator at http://validator.w3.org/. ------------------------------------------------------------------------ September 11, 2004 - 16:54 : tangent This problem persists in the latest cvs code. ------------------------------------------------------------------------ September 11, 2004 - 17:02 : Steven This has nothing to do with Drupal. It is a PHP feature, so the bug should be reported with PHP. Turn off session.use_trans_sid in php.ini or through .htaccess to get rid of the PHPSESSID in URLs. ------------------------------------------------------------------------ November 9, 2004 - 02:29 : lvadillo I've been trying to validate an xtemplate I'm going to put on line (XHTML 1.0 strict), to my surprise there were quite a few validating errors. 1) The ones due to to PHPSESSID went away when adding in .htaccess "php_flag session.use_trans_sid off", as recommended in other threads here. I still don't really know what I'm taking away with this command, anyway, I would say that even with it "on" it should be W3C compliant. I've looked at the coding (I have no idea about php) and found some type="hidden" inputs that are not within a block as the spec calls for some " ------------------------------------------------------------------------ November 9, 2004 - 02:32 : lvadillo CONTINUES... 2) Besides the PHPSESSID, I found that there were also others not inside the normal "" block (in the login screen), these were "function form_hidden()" and "function form_button()" in COMMON.INC. I then put a with no height and bottom to validate them and be non-intrusive to layout. 3) The "print" option of the book was also non conforming, I edited "function book_print()" and "function book_print_recurse()" in BOOK.MODULE, to show the coded as XHTML 1.0 as the rest (the dirty way I would say) and cleaned a couple of validating errors. ------------------------------------------------------------------------ November 9, 2004 - 09:10 : xand Are there any side effects to setting "php_flag session.use_trans_sid off" in .htaccess? Otherwise, why is it not done with the default Drupal .htaccess file?

1 0

[drupal-devel] [feature] Handle full URLs in url() and l()
by asimmonds 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/10888 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jhriggs Updated by: asimmonds Status: patch Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes) The &'s had been changed to & amp; , here's a valid patch asimmonds Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 03:01 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ September 30, 2004 - 23:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 25, 2005 - 08:06 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ March 14, 2005 - 10:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 14, 2005 - 12:05 : gordon +1 This is a good thing for people who can't using clean urls. ------------------------------------------------------------------------ April 2, 2005 - 18:23 : TDobes This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's?

1 0

[drupal-devel] [feature] Handle full URLs in url() and l()
by TDobes 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/10888 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jhriggs Updated by: TDobes Status: patch This patch seems like a good idea, but does not apply anymore. Also, shouldn't the comments for l() and url() be updated to indicate that the functions will work with both internal and external URL's? TDobes Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 09:01 : jhriggs Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB) This little patch allows full URLs to be used for the url() and l() functions, giving modules a single interface for creating links. Currently, modules must use l() for drupal links and raw HTML for external links. This patch changes url() to handle -- basically pass through -- full URLs while still doing the proper handling of internal paths and works with clean URLs enabled or disabled. It also shortens (and hopefully simplifies) the url() code a bit. Some examples of calls that now work: <?php l('a link', 'some/path'); // same as before l('an external link', 'http://drupal.org/'); l('full with query', 'http://google.com/search?q=define:foo'); l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above l('full with fragment', 'http://drupal.org/node/5942#comment-12374'); l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above ?> ------------------------------------------------------------------------ September 30, 2004 - 05:09 : moshe weitzman +1. less HTML in code is a good thing for readability, if nothing else. ------------------------------------------------------------------------ January 24, 2005 - 14:06 : mathias Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes) Revisiting this issue one year later shows we're almost there. The only thing that's left is the ability to handle external urls when clean_urls is disabled. Once implemented, menu.module can happily accept external urls and not just Drupal paths, making the menu system much more attractive to end users. I'll update the menu.module docs if this patch (or an alternative solution) is accepted. ------------------------------------------------------------------------ March 13, 2005 - 16:36 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes) Updated from Drupal root directory. ------------------------------------------------------------------------ March 13, 2005 - 18:05 : gordon +1 This is a good thing for people who can't using clean urls.

1 0

[drupal-devel] [feature] Handle external URLs
by chx 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19842 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/externalurl.patch (448 bytes) This very simple patch lets you add external URLs to your menu or wherever, 'cos I patched url() itself. Please consider for 4.6. chx

5 7

[drupal-devel] [bug] Internet Explorer freezing when accessing admin pages with Pushbutton Theme
by tatonca 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/16531 Project: Drupal Version: 4.5.2 Component: theme system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: tatonca Updated by: tatonca Status: fixed Thanks everyone for thier help... :) tatonca Previous comments: ------------------------------------------------------------------------ February 1, 2005 - 03:01 : tatonca Some users using IE 6.0 on XP SP2 and W2K SP4 are experiencing problems accessing admin pages while using the pushbutton theme. Changing to Bluemarine corrects the problem. I have made sure the default pushbutton theme also exhibits this problem. In all cases when going to an admin link such as ?q=admin/themes/config or ?q=user/1/edit IE freezes completely, requiring an exit and in some cases using task manager to stop the process. Other '3 part or more' links such as ?q=image/uid/# seem fine. Firefox does not have the problem - All pages render fine. There are no errors reported in the log files. I have the following modules configured : aggregator, archive, blog, blogapi blogroll, buddylist, comment, feature forum, help, image , legacy legal, members, menu, node page, profile, search statistics story, taxonomy ------------------------------------------------------------------------ February 2, 2005 - 11:35 : Robert Castelo I'm not sure where to begin with this bug, there isn't anything in Pushbutton that specifically styles the admin pages. Maybe something to do with the large tables some admin pages use, or perhaps something in the menu code? But then why hasn't this bug come up before? Pushbutton is quite widely used. It also sounds like it might be difficult to reproduce the bug: "The strange bit is that another XP machine with same IE works fine!" Could it possibly be just temporary heavy load on the server when you where trying the theme? Or a module that was causing problems - I noticed on your site you mentioned you where having problems with old modules. I'm not going to be able to look at this for about a week anyway, so try it out again and see if it could be something else, if the problem persists let me know and I'll have a look. ------------------------------------------------------------------------ February 2, 2005 - 18:53 : tatonca Hey there, I've tried this again at various times and the behaviour is still the same - ie on the affected machines freezes predicatably at the same pages, specifically the two types I've mentioned, and changing to bluemarine resolves the issue. I have started to port the pushbutton theme into bluemarine a section at a time, as I do like the theme but the error makes it hard for the majority of my users to update thier own accounts. With some luck, I may hit the exact piece of code in pushbutton that causes the problem and be able to report on that... Is there anything else that defines a theme other than the way the html goes and the {module} tags that are defined within it? ------------------------------------------------------------------------ February 2, 2005 - 21:22 : andremolnar I cannot reproduce this error. As a troubleshooting step - try turning off style sheets in internet explorer and see if the page works (it may not look right, but see if it loads without hanging). I can't think of anything on the server side (i.e. the theme) that could cause this behaviour. andre ------------------------------------------------------------------------ February 2, 2005 - 23:49 : Robert Castelo Also try testing with all modules turned off (except of course required ones) - just to make absolutely sure it's not a misbehaving module. ------------------------------------------------------------------------ February 8, 2005 - 08:48 : Anonymous Sounds like a crappily-written add-in for IE which is screwing things up for you. I had a problem similar to this with some spyware that had attached itself to IE on a client's PC... after running ad-aware, all was well again. In conclusion, this bug just made me hate IE and spyware even more. ------------------------------------------------------------------------ February 20, 2005 - 09:38 : Anonymous I too have found this "freezing" to be happening on my newly built Windows 2003 server box, and it freezes on my XP box as well. ------------------------------------------------------------------------ February 20, 2005 - 13:05 : Emiliano Hi! I rewrote the Pushbutton css file for my site (with differente colors) and "forgot" to define the style for *TABS*. Now Pushbutton theme works fine here (it used to freeze before). So I believe the problem is either in the "tabs", "tabs primary" or "li active" classes in the style sheet. You may notice that all the pages which have TABS will freeze. Verify the style sheet and remove or try to fix the style definitions. It worked fine for me. Then only thing is that if you remove the definitions, your tabs will look simpler. You may try to recreate that styles. []s, Emiliano. ------------------------------------------------------------------------ February 21, 2005 - 21:59 : tatonca You are correct - good observation! I had switched to the bluemarine theme and there are no TAB declarations in styles.css for this theme. I double checked with pushbutton enabled on an affected system and it is only pages with tabs that are not rendering. It must be some style setting in 'tabs' that IE does not like - I will test by eliminating each style setting in each of the 'tab' class specifications one at a time until the problem goes away to determine which it is... Thanks for the lead... ------------------------------------------------------------------------ February 28, 2005 - 21:14 : tatonca Just cross linking another thread with folks having similar issues http://drupal.org/node/17807 Update: I still can't figure out what causes it to fail - I mean I know it's the way Tabs are defined, as discussed, however the CSS seems to be formatted correctly and should work in IE - as evidenced by all kinds of people for which it works properly. I wonder if running IE in 'quirks' mode will yeild any insight.... ------------------------------------------------------------------------ March 22, 2005 - 16:07 : hellata The problem is the .tabs ul.secondary class declaration. Here is the offending line: white-space: nowrap; It's an IE bug (anyone surprised?). Adding "width:100%;" 'unconfuses' IE. Here is a working definition: 166 .tabs ul.secondary { 167 border-collapse: collapse; 168 padding: 10px 0 10px 0px; 169 margin: 0 0 0 0; 170 width:100%; 171 white-space: nowrap; 172 list-style: none; 173 height: auto; 174 line-height: normal; 175 border-bottom: none; 176 } ------------------------------------------------------------------------ March 24, 2005 - 00:55 : Robert Castelo Attachment: http://drupal.org/files/issues/pushbutton-tab-crash.patch (463 bytes) Thanks Hellata. Someone else experiencing this problem tried your solution, and it worked. Attached is a patch, which will hopefully make this bug disapear once and for all. ------------------------------------------------------------------------ March 29, 2005 - 09:49 : TDobes This patch was committed [1]... marking as "fixed." [1] http://drupal.org/cvs?commit=14680

1 0

[drupal-devel] [bug] request_uri() hack for tunelled connections
by anisotropic 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19843 Project: Drupal Version: 4.5.2 Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: anisotropic Updated by: anisotropic Status: active I run a drupal instance at work on our internal network as a FAQ tool, and had problems using the site while using ssh tunnels from the outside. I tracked this down to a problem with request_uri() where the following case was not accounted for: in $_SERVER HTTP_HOST is something like this: hostname:8080 because this is the port the client is using and passing along, but SERVER_PORT is '80' and REQUEST_URI is just something like /drupal/?q=support the following is a quick hack to fix this, intended not as a patch, but just to illutstrate an edge-case and a way to work around it. There are no doubt better ways to do this. =) the quick hack: <?php function request_uri() { // echo "<pre>".print_r($_SERVER, 1)."</pre>\n"; debugging? bah! if(isset($_SERVER['HTTP_HOST'])) { $host = explode(':', $_SERVER['HTTP_HOST']); } if($host[1] != $_SERVER['SERVER_PORT']) { // boom, we're tunnelled, better supply an entire url $uri = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI']; } else { if (isset($_SERVER['REQUEST_URI'])) { $uri = $_SERVER['REQUEST_URI']; } else { if (isset($_SERVER['argv'])) { $uri = $_SERVER['PHP_SELF'] .'?'. $_SERVER['argv'][0]; } else { $uri = $_SERVER['PHP_SELF'] .'?'. $_SERVER['QUERY_STRING']; } } } return check_url($uri); } ?> anisotropic

1 0

Re: [drupal-devel] some drupal stats
by K B 01 Apr '05

01 Apr '05

Dries, Let me be among the first to respond to this. I personally do not mind it, if it makes money for the Drupal Foundation non-profit organization (you are registering it soon, right? :-), AND that it is ethically acceptable. By ethically acceptable, I mean that it is completely disclosed to all developers and users of Drupal, and that it is not mandatory (users can disable it if they want). No sneaky business like the .css trick used by Wordpress, or a link farm, ...etc. I am not sure what they exactly mean by "integrate AdSense support into Drupal". Do they just want us to make the Drupal default page for the admin to has a link to signup for Adsense? A standard block for Adsense? As long as it is fully disclosed and can be disabled, I do not see anything wrong with a voluntary referral program, since this is effectively what it is. On the other hand, look at this from another angle: Google sees Drupal as important. I have no idea if they made that offer to other blogging software as well or not, but that makes me feel good to be part of the Drupal community. --- Date: Thu, 31 Mar 2005 22:51:51 +0200 From: Dries Buytaert <dries(a)buytaert.net> Subject: Re: [drupal-devel] some drupal stats To: drupal-devel(a)drupal.org, boris(a)bmannconsulting.com Message-ID: <d6c69f7c34744dad259733d3bffb771d(a)buytaert.net> Content-Type: text/plain; charset=US-ASCII; format=flowed > However, on the making-money-for-the-project angle....Dries, do you > want to bring up the Google issue? I don't have the details at hand here so I'd rather bring it up when I'm back in Belgium. Unfortunately, I guess that is too late now. In short: we got an offer from Google to integrate AdSense support into Drupal. For each Drupal user that signs up with Google and enables Google Ads on his or her Drupal site, we would get money from Google. Clearly, this is a great opportunity to generate some money. However, the question arises: do we want to go there, and if so, how?

3 5

[drupal-devel] [feature] New permission: access forums
by willmoy 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/19823 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: willmoy Status: patch Attachment: http://drupal.org/files/issues/access-forums.patch (1.17 KB) This simple patch (basically s/access content/access forums/g) makes it possible to restrict view access to forums. This is useful e.g. for sites that want anonymous users to be able to see pages etc. but want people to have to log in before reading the forums. I don't have a HEAD install anywhere, but the equivalent changes on my 4.5 installation are working just fine. willmoy

3 2

[drupal-devel] [feature] make (not verified) optional
by Anonymous 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/19837 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: Anonymous Status: active Attachment: http://drupal.org/files/issues/drupal_not_verified_user.patch (580 bytes) it would be nice to make the (not verified) flag for usernames optional, module writers would set $additions['verified']=1 in hook_load() to remove it for usernames that are not in the user databse, but still considerd verified. Anonymous

1 0

[drupal-devel] sorry to be asking special treatment...
by Daniel Convissor 01 Apr '05

01 Apr '05

Hi: I'm sorry to be asking for special treatment here. Can someone please commit the four simple, helpful (and one of them is even critical) patches I submittied? They are listed here in order of importance. database.pgsql ALTER TABLE sequences is wrong * http://drupal.org/files/issues/database.pgsql.sessions.diff http://drupal.org/node/19768 Make default $db_url informative and unique http://drupal.org/files/issues/settings.dburl.diff http://drupal.org/node/19800 settings.php: better instructions for $db_url and $db_prefix http://drupal.org/files/issues/settings2.diff http://drupal.org/node/19474 have db_prefix_tables() handle 'default' key not being set http://drupal.org/files/issues/database.diff http://drupal.org/node/19609 Committing these, or even marking them won't fix, will allow me move forward on the table creation script. The script not only helps my client, it will help other users and Drupal in general. Thank you, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

2 1