- Development - lists.drupal.org

[drupal-devel] [bug] Search Module not Working
by insomoz 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19863 Project: Drupal Version: 4.5.2 Component: search.module Category: bug reports Priority: critical Assigned to: insomoz Reported by: insomoz Updated by: insomoz Status: active Search module give this error message Compilation failed: characters with values > 255 are not yet supported in classes at offset 52 in /home/username/public_html/modules/search.module on line 258. insomoz

2 1

[drupal-devel] [bug] 4.6 aggregator showing/not interpreting HTML tags
by visserj 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19874 Project: Drupal Version: cvs Component: aggregator.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: visserj Updated by: visserj Status: active This applies to 4.6RC. ter upgrading my 4.5.2 site to 4.6, I seem to have some issues with the aggregator. The same feeds in the 4.5.2 aggregator showed no issues at all. Here's an example of what I mean. Watch the uninterpreted HTML tags in the feed: With five scoreless innings in his first spring start [1], Bruce Chen locked up the fifth spot in the rotation in a 3-1 win over the Cardinals yesterday. or this I don't know whether to laugh or cry. If this is Lloyd McClendon's idea of an April Fools' Day joke, it's not very nice to Tike Redman. If it's not, this is the cockamamiest baseball idea of all time. The effect of this move will be to take plate appearances away from Jason Bay and Craig Wilson, the two best hitters on the team, and give them to Tike Redman, who's possibly the worst hitter on the team. <a href = http://www.pittsburghlive.com/x/tribune-review/sports/pirateslive/s_319809.…>Here's</a> the Trib article. <a href = http://www.postgazette.com/pg/05092/481810.stm>Here's</a> the Post-Gazette writeup. I'm posting them both because of they offer an amazing array of half-baked explanations and bizarre reasonings. This is a fairly major issue, it's not workable this way. [1] http://sports.yahoo.com/mlb/recap?gid=250401124&prov=ap visserj

1 0

[drupal-devel] [bug] database.pgsql menu_mid_seq problems
by danielc 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19852 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/database.pgsql.menuseq.diff (364 bytes) Revision 1.84 of database.pgsql added the following query ALTER SEQUENCE menu_mid_seq RESTART 2; in response to issue 10349 (http://drupal.org/node/10349) Unfortunately, this causes an error due to the fact that the SQL script hasn't created that sequence yet. This patch adds a CREATE SEQUENCE query with the right info in it and removes the bogus ALTER SEQUENCE query. danielc

1 2

[drupal-devel] [feature] Comment module does not support extension of its forms
by escoles 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/14708 Project: Drupal Version: 4.5.1 Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: escoles Status: duplicate I'm not clear on how to apply this patch. The name of the file is "comment.form", not "comment.module"; is that simply an error? Or should I be able to find a resource somewhere with the filename "comment.form"? Related question: If I operate on the assumption that the filename should be "comment.module" and try to run patch, I get the error message "Only garbage was found in the patch input." Does anybody know what that would mean? escoles Previous comments: ------------------------------------------------------------------------ December 22, 2004 - 18:20 : tangent The comment module currently does not support 3rd party modules being able to add form elements or form validation. This is important for the captcha module to be able to add an extra form item. ------------------------------------------------------------------------ December 22, 2004 - 18:22 : tangent Attachment: http://drupal.org/files/issues/comment.form.patch (824 bytes) Here is a patch. ------------------------------------------------------------------------ December 23, 2004 - 06:54 : Anonymous Haven't tested it, but it seems identical to the changes I'd made for my experiments. +1 for this. This is important to have if people want captchas on comments. Other modules that I think can benefit by this: Ratings (rate the post along with commenting on it). ------------------------------------------------------------------------ December 23, 2004 - 07:15 : moshe weitzman this is a good direction for hook_comment(). for consistency with nodeapi, i propose splitting into 'form pre' and 'form post' operations and also adding a 'view' operation. ------------------------------------------------------------------------ December 23, 2004 - 09:37 : tangent I agree with the commentapi thing (however it is named or done) for several reasons. In the short term though, in order to use a captcha module immediately, it wouldn't hurt to update the existing code to support the purpose since I suspect the aforementioned redesign will not happen overnight. ------------------------------------------------------------------------ December 24, 2004 - 01:48 : TDobes There's a similar discussion going on in another issue [1]... one of these should be marked as a duplicate. [1] http://drupal.org/node/13539 ------------------------------------------------------------------------ December 24, 2004 - 06:51 : stefan nagtegaal Just not to forget: If such a patch like this makes it into core it would be nice to strip down the comment.module untill it is a real api. Removing the comment moderation part into an cmoderation.module would be a good thingtm. This way we make drupal more flexible and light weight... ------------------------------------------------------------------------ January 22, 2005 - 04:41 : stefan nagtegaal Duplicate of http://drupal.org/node/13539..

1 0

[drupal-devel] [feature] tracker needs to track project posts.
by gordon 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19847 Project: Drupal Version: cvs Component: tracker.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: gordon Updated by: gordon Status: active When looking at a tracker/user/{uid} can it also include as it does for comments posted against nodes responses to issues that you have posted to. Esp. being a developer, this would make it sop much easier to monitor posts that you have made, and continue the conversations. This post I will be able to track as I am the author, but any I am not the author but a contributer to the conversation I cannot follow as easily. gordon

3 3

[drupal-devel] [bug] Entities in titles are converted to their character representation
by AtomicMaestro 02 Apr '05

02 Apr '05

Issue status update for http://drupal.org/node/19864 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: AtomicMaestro Updated by: AtomicMaestro Status: active To reproduce: 1. Create a node with a title "< > become < and >" 2. View the node The title becomes "< > become < and >" AtomicMaestro

1 0

[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