Last 7 days

• Nov 01, 2009

  issue 21 (Auto-focusing) commented on by stefdawson   -   1. How would one blow away any info in the boxes by adding a jQuery .focus() call? Sorry, I don't follow. Tabbing through boxes doesn't delete info in boxes... or does it do that on OSX? 2. No intention of doing it anywhere else. Not even sure it's a good idea on the login page, it was just an idea. Since almost nobody's commented I guess almost nobody cares, so we might as well leave it as it is. It was only triggered by the fact I'd used Basecamp recently and found it pleasing to be presented with the cursor already flashing in the username box instead of me having to tab to it.

  1. How would one blow away any info in the boxes by adding a jQuery .focus() call? Sorry, I don't follow. Tabbing through boxes doesn't delete info in boxes... or does it do that on OSX? 2. No intention of doing it anywhere else. Not even sure it's a good idea on the login page, it was just an idea. Since almost nobody's commented I guess almost nobody cares, so we might as well leave it as it is. It was only triggered by the fact I'd used Basecamp recently and found it pleasing to be presented with the cursor already flashing in the username box instead of me having to tab to it.

Last 30 days

• Oct 31, 2009

  issue 21 (Auto-focusing) commented on by ph.wittenbergh   -   1. On the login page: make sure you're not blowing away autofilled login/password (esp on OS X with Keychain capable browsers). On the login page,the 'name' field is first in the tab-loop anyway - tabindex="1". 2. setting the focus on other pages/panes is imho a bad idea. If you really have the urge to go that way, make it user configurable.

  1. On the login page: make sure you're not blowing away autofilled login/password (esp on OS X with Keychain capable browsers). On the login page,the 'name' field is first in the tab-loop anyway - tabindex="1". 2. setting the focus on other pages/panes is imho a bad idea. If you really have the urge to go that way, make it user configurable.
• Oct 31, 2009

  issue 31 (txp:if_article_id on article list context) commented on by maniqui   -   Some ongoing discussion related to commend #2 here: http://forum.textpattern.com/viewtopic.php?id=32216

  Some ongoing discussion related to commend #2 here: http://forum.textpattern.com/viewtopic.php?id=32216
• Oct 30, 2009

  r3286 (enhanced search: adds search modes "any" and "all" to defaul...) committed by artagesw   -   enhanced search: adds search modes "any" and "all" to default mode "exact"; fixes some issues by properly escaping regex characters as necessary

  enhanced search: adds search modes "any" and "all" to default mode "exact"; fixes some issues by properly escaping regex characters as necessary
• Oct 30, 2009

  r3285 (Bug fix: Moved definition of txpath to allow it to be define...) committed by artagesw   -   Bug fix: Moved definition of txpath to allow it to be defined in config file.

  Bug fix: Moved definition of txpath to allow it to be defined in config file.
• Oct 30, 2009

  r3284 (Silence E_STRICT warnings in "live" production mode, mind E_...) committed by r.wetzlmayr   -   Silence E_STRICT warnings in "live" production mode, mind E_STRICT differences between PHP 5 and 6. Kind of fixes issue 48.

  Silence E_STRICT warnings in "live" production mode, mind E_STRICT differences between PHP 5 and 6. Kind of fixes issue 48.
• Oct 30, 2009

  issue 48 (Error message in comment entry popup) reported by r.wetzlmayr   -   PHP strict warnings are visible in the comment popup window when comment mode is configured as "popup": Strict Standards: Non-static method timezone::is_dst() should not be called statically in /textpattern/lib/txplib_misc.php on line 1265 Strict Standards: Non-static method timezone::is_supported() should not be called statically in /textpattern/lib/txplib_misc.php on line 2523 Does not occur at all instances, depends on PHP settings.

  PHP strict warnings are visible in the comment popup window when comment mode is configured as "popup": Strict Standards: Non-static method timezone::is_dst() should not be called statically in /textpattern/lib/txplib_misc.php on line 1265 Strict Standards: Non-static method timezone::is_supported() should not be called statically in /textpattern/lib/txplib_misc.php on line 2523 Does not occur at all instances, depends on PHP settings.
• Oct 20, 2009

  r3283 (Add pluggable UI 'article_ui' -> 'recent_articles'.) committed by r.wetzlmayr   -   Add pluggable UI 'article_ui' -> 'recent_articles'.

  Add pluggable UI 'article_ui' -> 'recent_articles'.
• Oct 20, 2009

  r3282 (Add article context to the 'article_ui' -> 'sidehelp' event ...) committed by r.wetzlmayr   -   Add article context to the 'article_ui' -> 'sidehelp' event .

  Add article context to the 'article_ui' -> 'sidehelp' event .

Earlier this year

• Oct 08, 2009

  issue 47 (Invalid regexp warnings in admin-side article search terms) reported by r.wetzlmayr   -   1. Visit the articles tab 2. Search "Title, Body & Excerpt", "Section", "Author" or "Categories" for a sole regexp metacharacter like asterisk (*) or backslash (\). 3. MySQL casts a warning: "Got error 'repetition-operator operand invalid' from regexp", "Got error 'trailing backslash (\)' from regexp" etc. Reported by THE BLUE DRAGON IN http://forum.textpattern.com/viewtopic.php?id=32007.

  1. Visit the articles tab 2. Search "Title, Body & Excerpt", "Section", "Author" or "Categories" for a sole regexp metacharacter like asterisk (*) or backslash (\). 3. MySQL casts a warning: "Got error 'repetition-operator operand invalid' from regexp", "Got error 'trailing backslash (\)' from regexp" etc. Reported by THE BLUE DRAGON IN http://forum.textpattern.com/viewtopic.php?id=32007.
• Sep 24, 2009

  issue 46 (Can't Add Categories When Using Chinese) reported by chhz.9991.com   -   What steps will reproduce the problem? 1.After set up.(Using zh_cn utf8) 2.Following the step to add a Chinese Character Categorie. 3.The First Chinese Categorie will be add ok,and the second,what ever Chinese character you add,textpattern will say already exists. What is the expected output? What do you see instead? using this two Chinese Character will add ok,like 你好0，你好1 but when using this two chinese character will not add.like 你好，你好吗 What version of the product are you using? On what operating system? version 4.2.0 and 4.0.8 on Linux,Windows Please provide any additional information below. no more.

  What steps will reproduce the problem? 1.After set up.(Using zh_cn utf8) 2.Following the step to add a Chinese Character Categorie. 3.The First Chinese Categorie will be add ok,and the second,what ever Chinese character you add,textpattern will say already exists. What is the expected output? What do you see instead? using this two Chinese Character will add ok,like 你好0，你好1 but when using this two chinese character will not add.like 你好，你好吗 What version of the product are you using? On what operating system? version 4.2.0 and 4.0.8 on Linux,Windows Please provide any additional information below. no more.
• Sep 24, 2009

  issue 45 (Core plugin l10n and i18n method) commented on by r.wetzlmayr   -   No. We research a standard method of handling l10n texts for plugins, similar to what the core does at Admin > Prefs > Languages. Currently, translating a plugin either means a user has to patch a plugin's code, or each single plugin author devises a custom method to render l10n-aware text. Cumbersome. This does not imply any form of remote infrastructure (language server).

  No. We research a standard method of handling l10n texts for plugins, similar to what the core does at Admin > Prefs > Languages. Currently, translating a plugin either means a user has to patch a plugin's code, or each single plugin author devises a custom method to render l10n-aware text. Cumbersome. This does not imply any form of remote infrastructure (language server).
• Sep 24, 2009

  issue 45 (Core plugin l10n and i18n method) commented on by destry.wion   -   Am I reading this right...steps to make it core functionality to publish multilingual sites?

  Am I reading this right...steps to make it core functionality to publish multilingual sites?
• Sep 24, 2009

  issue 45 (Core plugin l10n and i18n method) Labels changed by r.wetzlmayr   -  

  Labels: Type-Enhancement

  Labels: Type-Enhancement
• Sep 24, 2009

  issue 45 (Core plugin l10n and i18n method) reported by r.wetzlmayr   -   A common method to store and edit texts for plugins at monolingual sites would be helpful. My primary concern are user-visible strings, but plugin help texts might also be a target for this issue. A solution should help both plugin authors and site owners. Authors could distribute a set of translations with their work, while site owners could add local strings for the plugin to use, and eventually redistribute a language set back to the community or plugin author.

  A common method to store and edit texts for plugins at monolingual sites would be helpful. My primary concern are user-visible strings, but plugin help texts might also be a target for this issue. A solution should help both plugin authors and site owners. Authors could distribute a set of translations with their work, while site owners could add local strings for the plugin to use, and eventually redistribute a language set back to the community or plugin author.
• Sep 23, 2009

  issue 44 (Removing unnecessary base64 encoding of CSS) reported by johnqstephens   -   http://forum.textpattern.com/viewtopic.php?pid=215743#p215743

  http://forum.textpattern.com/viewtopic.php?pid=215743#p215743
• Sep 23, 2009

  issue 43 (Remove CSS Editor application) reported by johnqstephens   -   http://forum.textpattern.com/viewtopic.php?pid=215835#p215835 Folks want to keep the simple "raw CSS" edit mode, but no one has spoken in favor of keeping the backend CSS Editor application.

  http://forum.textpattern.com/viewtopic.php?pid=215835#p215835 Folks want to keep the simple "raw CSS" edit mode, but no one has spoken in favor of keeping the backend CSS Editor application.
• Sep 23, 2009

  r3281 (Record correct version number for sits running from svn.) committed by r.wetzlmayr   -   Record correct version number for sits running from svn.

  Record correct version number for sits running from svn.
• Sep 23, 2009

  issue 42 ($default_event not properly set in SVN versions) Status changed by r.wetzlmayr   -   This issue was closed by revision r3280.

  Status: Fixed

  This issue was closed by revision r3280.

  Status: Fixed
• Sep 23, 2009

  r3280 ($default_event fires for stable and development versions. Fi...) committed by r.wetzlmayr   -   $default_event fires for stable and development versions. Fixes issue 42.

  $default_event fires for stable and development versions. Fixes issue 42.
• Sep 22, 2009

  issue 42 ($default_event not properly set in SVN versions) reported by r.wetzlmayr   -   Symptom: $default_event is not accounted for when $txp_using_svn is true. Prerequisite: $default_event must not be used during a site update. In http://code.google.com/p/textpattern/source/browse/development/4.x/textpattern/index.php?spec=svn3279&r=3278#108, TXP_UPDATE is defined for both "real" version updates and sites running from SVN. In http://code.google.com/p/textpattern/source/browse/development/4.x/textpattern/index.php?spec=svn3279&r=3278#120, this ambiguity shoots ourselves in the foot.

  Symptom: $default_event is not accounted for when $txp_using_svn is true. Prerequisite: $default_event must not be used during a site update. In http://code.google.com/p/textpattern/source/browse/development/4.x/textpattern/index.php?spec=svn3279&r=3278#108, TXP_UPDATE is defined for both "real" version updates and sites running from SVN. In http://code.google.com/p/textpattern/source/browse/development/4.x/textpattern/index.php?spec=svn3279&r=3278#120, this ambiguity shoots ourselves in the foot.
• Sep 20, 2009

  issue 41 (extraneous <h2 id="comment> </h2> appended to articles) commented on by nik.martin   -   thebombsite, that worked, thanks. I'm fairly new to TXP, and the docs don't FULLY describe things like which forms are included based on what settings. This bug may be against the default config vs. txp itself.

  thebombsite, that worked, thanks. I'm fairly new to TXP, and the docs don't FULLY describe things like which forms are included based on what settings. This bug may be against the default config vs. txp itself.
• Sep 19, 2009

  issue 41 (extraneous <h2 id="comment> </h2> appended to articles) commented on by thebombsite   -   I think that is simply a lack of proper coding in the comments_display form template. Go to that form and look for the h2 tag then surround it with <txp:if_comments></txp:if_comments> tags. Then it won't display unless there are comments for an article.

  I think that is simply a lack of proper coding in the comments_display form template. Go to that form and look for the h2 tag then surround it with <txp:if_comments></txp:if_comments> tags. Then it won't display unless there are comments for an article.
• Sep 19, 2009

  issue 41 (extraneous <h2 id="comment> </h2> appended to articles) reported by nik.martin   -   What steps will reproduce the problem? 1. Enable Site Wide Comments (Admin > Preferences > Basic > Accept Comments) 2. Set "On By Default" to No (Admin > Preferences > Basic > Accept Comments) 2. Create a page template with JUST <txp:article><txp:body /></txp:article> 3. Set a section to use this page 4. Create an article in this section, turning comments OFF 5. Publish Article 6. View source of article. What is the expected output? To see my article Text ONLY What do you see instead? My article Text + "<h2 id="comment"></h2>" What version of the product are you using? Textpattern version: 4.2.0 (r3275) On what operating system? Centos 5.3 x86_64 Please provide any additional information below. I'm rying to use a stripped down article/section/page to produce linkable text files from Textpattern, for creating custom rss feeds, store javascript in the DB, etc. if a page template like: <txp:article><txp:body /></txp:article> doesn't deliver exactly and only the body of the article to the browser, then it seems broken.

  What steps will reproduce the problem? 1. Enable Site Wide Comments (Admin > Preferences > Basic > Accept Comments) 2. Set "On By Default" to No (Admin > Preferences > Basic > Accept Comments) 2. Create a page template with JUST <txp:article><txp:body /></txp:article> 3. Set a section to use this page 4. Create an article in this section, turning comments OFF 5. Publish Article 6. View source of article. What is the expected output? To see my article Text ONLY What do you see instead? My article Text + "<h2 id="comment"></h2>" What version of the product are you using? Textpattern version: 4.2.0 (r3275) On what operating system? Centos 5.3 x86_64 Please provide any additional information below. I'm rying to use a stripped down article/section/page to produce linkable text files from Textpattern, for creating custom rss feeds, store javascript in the DB, etc. if a page template like: <txp:article><txp:body /></txp:article> doesn't deliver exactly and only the body of the article to the browser, then it seems broken.
• Sep 14, 2009

  issue 40 (Enhancement request (feed link tag)) Labels changed by r.wetzlmayr   -  

  Labels: Type-Enhancement Component-Tags

  Labels: Type-Enhancement Component-Tags
• Sep 14, 2009

  issue 40 (Enhancement request (feed link tag)) Labels changed by r.wetzlmayr   -  

  Labels: Type-Enhancement Component-Tags

  Labels: Type-Enhancement Component-Tags
• Sep 14, 2009

  r3279 (Remove bogus "include" in public site template. Thanks, Anto...) committed by r.wetzlmayr   -   Remove bogus "include" in public site template. Thanks, Antonio Touriño.

  Remove bogus "include" in public site template. Thanks, Antonio Touriño.
• Sep 14, 2009

  issue 40 (Enhancement request (feed link tag)) reported by cole007.net   -   Wondering on merits of adding a new class attribute to <txp:feed_link>. I'd ideally like to be able to apply a class to the wraptag (if used) as the nature of this link means I might want to apply some bespoke styling to the wrapping element (an RSS icon, for example). Cheers, Cole

  Wondering on merits of adding a new class attribute to <txp:feed_link>. I'd ideally like to be able to apply a class to the wraptag (if used) as the nature of this link means I might want to apply some bespoke styling to the wrapping element (an RSS icon, for example). Cheers, Cole
• Sep 10, 2009

  issue 39 (Fix behaviour of <txp:if_section> and <txp:if_category> tags...) Status changed by r.wetzlmayr   -   Oops.

  Status: Invalid

  Oops.

  Status: Invalid
• Sep 10, 2009

  issue 39 (Fix behaviour of <txp:if_section> and <txp:if_category> tags...) commented on by r...@vanmelick.com   -   I think that was already done in this changeset: http://code.google.com/p/textpattern/source/detail?r=3057

  I think that was already done in this changeset: http://code.google.com/p/textpattern/source/detail?r=3057
• Sep 09, 2009

  issue 39 (Fix behaviour of <txp:if_section> and <txp:if_category> tags...) reported by r.wetzlmayr   -   ruud suggests: Leaving out the name attribute and setting the name attribute to an empty string doesn’t work consistently in both tags: * compare <txp:if_section> to <txp:if_category>: the former condition is true on the frontpage where there is no section while the latter condition is false on the frontpage where there is no category, but true for any valid category. The <txp:if_category> behaviour makes more sense. * compare <txp:if_category name="">, <txp:if_section name="">, <txp:if_category name=",about"> and <txp:if_section name=",about">. The last three are consistent in behaviour. When specifying an empty category or section, if you’re on the frontpage (no section/category), the condition is true. But <txp:if_category name=""> behaves differently, because that one is true currently if you’re on any valid category page. An empty category or section name could mean “any” or “none”. The latter makes more sense and is used in 3 out of 4 situations. related discussion: http://forum.textpattern.com/viewtopic.php?id=29263

  ruud suggests: Leaving out the name attribute and setting the name attribute to an empty string doesn’t work consistently in both tags: * compare <txp:if_section> to <txp:if_category>: the former condition is true on the frontpage where there is no section while the latter condition is false on the frontpage where there is no category, but true for any valid category. The <txp:if_category> behaviour makes more sense. * compare <txp:if_category name="">, <txp:if_section name="">, <txp:if_category name=",about"> and <txp:if_section name=",about">. The last three are consistent in behaviour. When specifying an empty category or section, if you’re on the frontpage (no section/category), the condition is true. But <txp:if_category name=""> behaves differently, because that one is true currently if you’re on any valid category page. An empty category or section name could mean “any” or “none”. The latter makes more sense and is used in 3 out of 4 situations. related discussion: http://forum.textpattern.com/viewtopic.php?id=29263
• Sep 08, 2009

  issue 20 (populateArticleData() Custom field handling -- part 1) commented on by r...@vanmelick.com   -   Another solution would be to use the actual table column names (custom_1) instead of the user-defined labels for those columns. If you want to sort on custom fields, you have to use those table column names anyway and it solves problems with labels as shown below, not to mention the fact that it would get rid of some ugly hacks to actually get the labels working properly on the public side: 'custom_1' => "spaces, i haz 'em" <txp:article custom_1="something" /> (OK) <txp:article spaces, i haz 'em="something" /> (FAIL)

  Another solution would be to use the actual table column names (custom_1) instead of the user-defined labels for those columns. If you want to sort on custom fields, you have to use those table column names anyway and it solves problems with labels as shown below, not to mention the fact that it would get rid of some ugly hacks to actually get the labels working properly on the public side: 'custom_1' => "spaces, i haz 'em" <txp:article custom_1="something" /> (OK) <txp:article spaces, i haz 'em="something" /> (FAIL)
• Sep 08, 2009

  issue 25 (<txp:comment_x_tags/> don't allow closing without trailing s...) commented on by r...@vanmelick.com   -   A cleaner solution would be to make them real tags in taghandlers.php and rely on the tag parser instead of using a simple search and replace which sometimes replaces when it should not (in non-parsed attribute values). $Form is parsed anyway at line 203. Performance penalty will be negligible. There's no direct relation between the length of a regular expression and its speed ;) Keep in mind that regular expressions have to be compiled (which takes time, perhaps more than actually executing it). The search/replace method requires 7 different regular expressions that are all used only once, while parse() uses only 2 regexes repeatedly (regex compilation is cached by PHP).

  A cleaner solution would be to make them real tags in taghandlers.php and rely on the tag parser instead of using a simple search and replace which sometimes replaces when it should not (in non-parsed attribute values). $Form is parsed anyway at line 203. Performance penalty will be negligible. There's no direct relation between the length of a regular expression and its speed ;) Keep in mind that regular expressions have to be compiled (which takes time, perhaps more than actually executing it). The search/replace method requires 7 different regular expressions that are all used only once, while parse() uses only 2 regexes repeatedly (regex compilation is cached by PHP).
• Sep 08, 2009

  issue 38 (qmail MTA requires \r linebreaks in (subject) header of mail...) reported by r...@vanmelick.com   -   see discussion in http://forum.textpattern.com/viewtopic.php?id=31697 TXP tries to use the right line endings when sending emails, but fails when using qmail (http://cr.yp.to/qmail.html). Apparently qmail wants \r line endings (instead of \n) in the subject parameter of the PHP mail() function if you're using linebreaks in subjects, which happens automatically if your subject line is too long (encode_mailheader limits the length of header lines according to relevant RFCs). This is the error you get when for example you're trying to add a new user in such a situation (qmail MTA + long site name, causing a multi line subject header): Warning: mail(): Bad parameters to mail() function, mail not sent. in /.../textpattern/lib/txplib_misc.php on line 989 Before even considering to think about attempting to fix this, please reproduce the problem first, because while qmail is known for being really strict when it comes to proper use of line endings, all documentation I can find suggests using \n (as TXP already does on *nix systems). Using \r makes no sense yet solved the problem for the user in the forum topic mentioned above, unless it's two wrongs making a right.

  see discussion in http://forum.textpattern.com/viewtopic.php?id=31697 TXP tries to use the right line endings when sending emails, but fails when using qmail (http://cr.yp.to/qmail.html). Apparently qmail wants \r line endings (instead of \n) in the subject parameter of the PHP mail() function if you're using linebreaks in subjects, which happens automatically if your subject line is too long (encode_mailheader limits the length of header lines according to relevant RFCs). This is the error you get when for example you're trying to add a new user in such a situation (qmail MTA + long site name, causing a multi line subject header): Warning: mail(): Bad parameters to mail() function, mail not sent. in /.../textpattern/lib/txplib_misc.php on line 989 Before even considering to think about attempting to fix this, please reproduce the problem first, because while qmail is known for being really strict when it comes to proper use of line endings, all documentation I can find suggests using \n (as TXP already does on *nix systems). Using \r makes no sense yet solved the problem for the user in the forum topic mentioned above, unless it's two wrongs making a right.
• Sep 08, 2009

  issue 37 (article form defined in write tab (modified module) has prec...) commented on by plam.gmx   -   Btw, xxxx-article is the default form for a section..

  Btw, xxxx-article is the default form for a section..
• Sep 08, 2009

  issue 37 (article form defined in write tab (modified module) has prec...) commented on by plam.gmx   -   --------------------------- allowoverride="boolean" Whether to use override forms for the generated article list. Default: 1 (yes). ------------------------ Maybe I'm stupid and understood that other forms are overridden by the tag-att listform and indeed allowoverride="0" works for the article list, but for an individual article the article form is overridden by the tag form. I solved it in this way: <txp:if_individual_article> <txp:article form="xxxx_article" [ allowoverride="1" ] /> <txp:else /> <txp:article listform="article_listing" limit="15" allowoverride="0" /> </txp:if_individual_article> Maybe a better explanation in the tag reference should be desirable. Anyway thanks for the tip...

  --------------------------- allowoverride="boolean" Whether to use override forms for the generated article list. Default: 1 (yes). ------------------------ Maybe I'm stupid and understood that other forms are overridden by the tag-att listform and indeed allowoverride="0" works for the article list, but for an individual article the article form is overridden by the tag form. I solved it in this way: <txp:if_individual_article> <txp:article form="xxxx_article" [ allowoverride="1" ] /> <txp:else /> <txp:article listform="article_listing" limit="15" allowoverride="0" /> </txp:if_individual_article> Maybe a better explanation in the tag reference should be desirable. Anyway thanks for the tip...
• Sep 08, 2009

  r3278 (Do not use $default_event prefs while a version update is un...) committed by r.wetzlmayr   -   Do not use $default_event prefs while a version update is underway.

  Do not use $default_event prefs while a version update is underway.
• Sep 07, 2009

  issue 37 (article form defined in write tab (modified module) has prec...) Status changed by r.wetzlmayr   -   Works as intended.

  Status: Invalid

  Works as intended.

  Status: Invalid
• Sep 07, 2009

  issue 37 (article form defined in write tab (modified module) has prec...) commented on by maniqui   -   Try adding allowoverride="0". More info here: http://textpattern.net/wiki/index.php?title=article#Attributes

  Try adding allowoverride="0". More info here: http://textpattern.net/wiki/index.php?title=article#Attributes
• Sep 07, 2009

  issue 37 (article form defined in write tab (modified module) has prec...) reported by plam.gmx   -   What steps will reproduce the problem? ------------------------------------ 1. choose a module for article in write tab 2. use this in page layout: <txp:article limit="10" form="article" listform="article_listing /> or <txp:article limit="10" form="article" /> or <txp:article limit="10" listform="article_listing /> or <txp:article limit="10" /> 3. In all cases, no matter which (list)forms are used in the page tag, the articles with a form specified in the article context (even if the default form is chosen) are displayed with that form. What is the expected output? What do you see instead? ----------------------------------------------------- I expect that all articles should be displayed with the specified listform if there is no individual_article. What version of the product are you using? On what operating system? -------------------------------------------------------------------- cms: textpattern 4.2 os: windows xp Please provide any additional information below. ----------------------------------------------- No matter what I do (I tested it in a lot of contexts) the following precedence is used when displaying an article in article list: - article form - tag listform - tag form Work around ------------ Instead of a modified module use a custom_field for defining the article form and redirect it using the default article form if it is an individual_article

  What steps will reproduce the problem? ------------------------------------ 1. choose a module for article in write tab 2. use this in page layout: <txp:article limit="10" form="article" listform="article_listing /> or <txp:article limit="10" form="article" /> or <txp:article limit="10" listform="article_listing /> or <txp:article limit="10" /> 3. In all cases, no matter which (list)forms are used in the page tag, the articles with a form specified in the article context (even if the default form is chosen) are displayed with that form. What is the expected output? What do you see instead? ----------------------------------------------------- I expect that all articles should be displayed with the specified listform if there is no individual_article. What version of the product are you using? On what operating system? -------------------------------------------------------------------- cms: textpattern 4.2 os: windows xp Please provide any additional information below. ----------------------------------------------- No matter what I do (I tested it in a lot of contexts) the following precedence is used when displaying an article in article list: - article form - tag listform - tag form Work around ------------ Instead of a modified module use a custom_field for defining the article form and redirect it using the default article form if it is an individual_article
• Sep 04, 2009

  issue 36 (Trailing dash in url_title) reported by r.wetzlmayr   -   Article title like "Donald Swain: “I enjoy your site very much.”" result in an url_title with a trailing dash: "donald-swain-i-enjoy-your-site-very-much-". Ugly, requires a trim().

  Article title like "Donald Swain: “I enjoy your site very much.”" result in an url_title with a trailing dash: "donald-swain-i-enjoy-your-site-very-much-". Ugly, requires a trim().
• Sep 04, 2009

  issue 35 (Enhance doLabel()) reported by stefdawson   -   Currently there is no way to prevent doLabel() from displaying a <br /> tag if you don't want one, or if you want a 'simple' break between label and item (e.g. a colon or a space). Whatever you specify is surrounded by '<' and '>' brackets. I propose doLabel() should behave similarly to doWrap() insofar as if you specify something that _isn't_ a tag it should put it after the label without brackets. At the moment it is also not possible to specify an empty labeltag, because if it's empty it adds a break tag by default. Whether an empty labeltag is desirable is open to debate, but for tags and plugins that use <code>doLabel($label, $labeltag).doWrap($out, $wraptag, $break, $class)</code> it allows more flexibility in output. If an empty labeltag is permitted, to preserve backwards compatibility we would either have to: 1. allow something like a space or a known constant that indicated "no break please", or 2. permit labeltag="" to set no labeltag, thus all other tags that currently use labeltag=>'' in lAtts() would need modifying to make 'br' their default Would modifying this have any other side effects? Is this something that would be useful to people who use label/labeltag? Should there be an empty labeltag option? Should the labeltag be allowed to be a simple character like colon or space, or is this a gross violation of naming convention?

  Currently there is no way to prevent doLabel() from displaying a <br /> tag if you don't want one, or if you want a 'simple' break between label and item (e.g. a colon or a space). Whatever you specify is surrounded by '<' and '>' brackets. I propose doLabel() should behave similarly to doWrap() insofar as if you specify something that _isn't_ a tag it should put it after the label without brackets. At the moment it is also not possible to specify an empty labeltag, because if it's empty it adds a break tag by default. Whether an empty labeltag is desirable is open to debate, but for tags and plugins that use <code>doLabel($label, $labeltag).doWrap($out, $wraptag, $break, $class)</code> it allows more flexibility in output. If an empty labeltag is permitted, to preserve backwards compatibility we would either have to: 1. allow something like a space or a known constant that indicated "no break please", or 2. permit labeltag="" to set no labeltag, thus all other tags that currently use labeltag=>'' in lAtts() would need modifying to make 'br' their default Would modifying this have any other side effects? Is this something that would be useful to people who use label/labeltag? Should there be an empty labeltag option? Should the labeltag be allowed to be a simple character like colon or space, or is this a gross violation of naming convention?
• Sep 04, 2009

  issue 32 (Files) changed by stefdawson   -   For a recent client project I modded TXP to add a file Title and I agree it makes a world of difference. Adding the title is not a major undertaking -- a few mods to the Files tab and a new client tag to output it -- so I'll take ownership of this one as I've pretty much done it already. As for renaming files, we'll take a look at what can be done, though that one's a bit more involved...

  Status: Assigned

  Owner: stefdawson

  Labels: Type-Enhancement Priority-Low

  For a recent client project I modded TXP to add a file Title and I agree it makes a world of difference. Adding the title is not a major undertaking -- a few mods to the Files tab and a new client tag to output it -- so I'll take ownership of this one as I've pretty much done it already. As for renaming files, we'll take a look at what can be done, though that one's a bit more involved...

  Status: Assigned

  Owner: stefdawson

  Labels: Type-Enhancement Priority-Low
• Sep 03, 2009

  issue 34 (Avoid relative paths in diagnostics output) reported by r.wetzlmayr   -   Diagnostics output contains a few relative paths with intermittent '..', e.g. /[webroot]/textpattern/../css.php This might confuse people into reading an ellipsis there, and failing to find the file in question. Diagnostics output should only contain canonical file system paths.

  Diagnostics output contains a few relative paths with intermittent '..', e.g. /[webroot]/textpattern/../css.php This might confuse people into reading an ellipsis there, and failing to find the file in question. Diagnostics output should only contain canonical file system paths.
• Sep 02, 2009

  issue 33 (timezone settings) commented on by dominik.lenk   -   Turns out that this has to do with php 5.3 coming with the default installation of mac os x 10.6: date.timezone is not set by default in the php.ini file… Not Textpattern related…

  Turns out that this has to do with php 5.3 coming with the default installation of mac os x 10.6: date.timezone is not set by default in the php.ini file… Not Textpattern related…
• Sep 02, 2009

  issue 33 (timezone settings) commented on by dominik.lenk   -   Europe - Berlin

  Europe - Berlin
• Sep 01, 2009

  issue 33 (timezone settings) Labels changed by r.wetzlmayr   -   What timezone have you actually set in "Basic Preferences"?

  Labels: Type-Defect Component-Core

  What timezone have you actually set in "Basic Preferences"?

  Labels: Type-Defect Component-Core
• Sep 01, 2009

  issue 33 (timezone settings) reported by dominik.lenk   -   Getting the following warnings (+ a lot more) in the txp preferences. Almost certainly has to do with the timezone support… Running txp 4.2 (Rev 3189) on mac os 10.6 with php 5.3 and mysql 5.1.37 Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1262 Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1263 Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1299

  Getting the following warnings (+ a lot more) in the txp preferences. Almost certainly has to do with the timezone support… Running txp 4.2 (Rev 3189) on mac os 10.6 with php 5.3 and mysql 5.1.37 Warning: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1262 Warning: mktime() [function.mktime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1263 Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/London' for 'BST/1,0/DST' instead in /Users/user/Sites/domain.dev/textpattern/lib/txplib_misc.php on line 1299
• Sep 01, 2009

  issue 32 (Files) reported by cole007.net   -   Hey Not a defect/issue or bug, more of a feature request (directed here by Robert Wetzlmayr - see http://twitter.com/rwetzlmayr/status/3683019124). Could be pipe dream stuff but definitely something I think that would be an improvement to the textpattern CMS. I love textpattern. One of the key pluses for me that is missing in a lot of other CMS's is how TXP separates content and presentation. I love the grouping of files, images and links as separate _kinds_ of content and the ease with which these can be associated with individual articles (through custom fields, for example). However, I *wish* that files were more flexible and there was: # the ability to rename files, and/or # the ability to have an alternative title for a file Thinking here how TXP treats images (and wondering why files are treated so differently). Hope this makes sense - it is the one ommission/frustration for me (apart from section hierarchy) in an otherwise lovely CMS :) Cole http://cole007.net/

  Hey Not a defect/issue or bug, more of a feature request (directed here by Robert Wetzlmayr - see http://twitter.com/rwetzlmayr/status/3683019124). Could be pipe dream stuff but definitely something I think that would be an improvement to the textpattern CMS. I love textpattern. One of the key pluses for me that is missing in a lot of other CMS's is how TXP separates content and presentation. I love the grouping of files, images and links as separate _kinds_ of content and the ease with which these can be associated with individual articles (through custom fields, for example). However, I *wish* that files were more flexible and there was: # the ability to rename files, and/or # the ability to have an alternative title for a file Thinking here how TXP treats images (and wondering why files are treated so differently). Hope this makes sense - it is the one ommission/frustration for me (apart from section hierarchy) in an otherwise lovely CMS :) Cole http://cole007.net/
• Aug 28, 2009

  r3277 (This is 4.2.0, heading for the next release.) committed by r.wetzlmayr   -   This is 4.2.0, heading for the next release.

  This is 4.2.0, heading for the next release.