Feedback to: Help us test the release candidate for the upcoming 4.0.7

Pat64 · 2008-11-26 19:13:04

Hi all.

I’m traying this new version :)

Just an idea : it will be very interesting to choose within the “Prefs” tab the date format for the publishing date inputs visible within the “Write” tab.

Some people could be confuising with the english date format : “AAAA/MM/DD” cause others are using this one : “DD/MM/AAAA”

But as ruud wrote:
^^ It’s far too late to change something like that now.

Another comment :

The date format within the “Authors” tab is like this : MM AAAA. Perhaps it should be like this : DD MM AAAA H:I.

Best regards,

Last edited by Pat64 (2008-11-26 19:14:12)

ruud · 2008-11-26 19:24:27

Joe, the popup help for smtp_from (= SMTP envelope sender address) should work now.

Patrick,
YYYY/MM/DD is not the english date format. It’s the international ISO date format (although perhaps the ‘/’ should be changed to ‘-’).

The date format on the users tab is limited to month/year on purpose to indicate how accurate the date is, because that date does not indicate when the user last visited on the admin side. Instead, it shows when the user last logged in (using username/password). These are not necessarily the same, because you can stay logged in for about a month before you are forced to log in again. Making it more accurate than showing the month would be misleading and would probably generate quite a few questions about why the date shown isn’t “up-to-date”. Those that do need more accuracy, probably need a plugin that logs every action a user takes on the admin side ;)

Last edited by ruud (2008-11-26 19:36:23)

Pat64 · 2008-11-26 19:36:49

Ok ruud. I understand.

Best regards,

joebaich · 2008-11-26 20:16:10

Ruud wrote:

Joe, the popup help for smtp_from (= SMTP envelope sender address) should work now.

Excellent, thank you very much.

artagesw · 2008-11-26 22:58:37

ruud wrote:

Hmm… I’d first like to see why exactly the plugin requires the HTTP header and if the status information isn’t available in some global variable (I’d expect it to be there), because this appears to be not about triggering an action, but about avoiding something.

The plugin does not require a header. It simply needs to know what status code Textpattern returns. The php headers_list() function does not return the main status header, but it does return custom headers. The plugin already calls headers_list() and parses the result, so a custom header seems like a clean way to communicate the status code with minimal changes. I have implemented this method in the plugin and made the one-line change to Textpattern core, and have tested it – it works great.

A global variable would work as well, but I dislike global variables as a core-to-plugin communication mechanism – they tend to be fragile.

Ultimately, I would be happy with whatever mechanism the devs want to provide. Since I have already written and tested the plugin modifications assuming a customer header, that would be my first choice.

zoltandragon · 2008-11-27 07:51:52

I have encountered another tiny problem – and right now I am not even sure whether it is a TXP-related problem or server-side one: after upgrading my site, the server stopped sending the emails when an article gets a comment. Has anyone else encountered such a case?

FireFusion · 2008-11-27 08:11:37

Any release date in mind for this?

wet · 2008-11-27 08:14:47

Nov 29th (this year, fingers crossed).

the_ghost · 2008-11-27 08:59:44

Is it possible to implement caseinsensetive search? Within russian text (cyrillic chars) case matters, but when i search english word, case doesn’t matter. I fixed this problem by editing publish.php line 619 (approx):

$search = " and (lower(Title) rlike lower('$q') or lower(Body) rlike lower('$q')) $s_filter";

As far as I patched r2964 version of publish.php currently this string may have another position.
This the end code variant. I added lower() function and it gave the result. Now search is caseinsensetive but search_result_excerpts didn’t lost Uppercase letters.

And with the last taghandlers.php tag <txp:search_result_excerpt /> has output, but doesn’t higlight query string. You can test it here:

P.S. Does it MLP adds x and y to query?

Last edited by the_ghost (2008-11-27 15:29:18)

Gocom · 2008-11-27 11:06:25

the_ghost wrote:

Does it MLP adds x and y to query?

Nope. It’s browser side thing.

And server doesn’t even send any headers that would do it so no no, it’s browser side thing. That happens (in example) if you use type="image" input in the form. Some browsers then to add image’s x and y scale to the query.

I usually fix that oddness with simple redirect.

Last edited by Gocom (2008-11-27 11:06:49)

ruud · 2008-11-27 11:26:24

Since we’re only a few days removed from a release, we’re only fixing regressions, not issues that already existed in earlier TXP versions.

Victor, I think that patch would make searching even slower than it is now. If you searched using MATCH [much faster] instead of RLIKE, would that work correctly with cyrillic chars?

the_ghost · 2008-11-28 13:33:25

More clean post about russian search after clean install with r3020:

Without any patches, at totally clear install, search within russian works, but
1. It’s case-sensetive
2. <txp:search_result_excerpt /> doesn’t output anything
I made this “path” to publish.php, at line 635 (1 – before, 2 – after patch):
1. $cols[$i] = "`$cols[$i]` rlike ('$q')";
2. $cols[$i] = "lower(`$cols[$i]`) rlike lower('$q')";
After this patch search with russian is caseinsensetive, but <txp:search_result_excerpt /> still doesn’t work.
1. But at the same time <txp:search_result_excerpt /> has good output when searching through english word
For displaying russian i use plugin, written by russian community – here is the link to download – act_search_result_excerpt.txt
1. with this pluging both russian and english excerpts have output, regardless does search query match case with found string, or not. In other words – this plugin works as native search_result_excerpt for english, but for russian text.

I hope this post can clear the situation, ‘cos i tried to describe everything as fully as it possible. If you need some russian text for testing here i uploaded some (8kB) russian text

P.S. Wouldn’t txp:if_article_image be added in this release?

Last edited by the_ghost (2008-11-28 13:38:08)

Textpattern CMS

Textpattern CMS support forum

#109 2008-11-26 19:13:04

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#110 2008-11-26 19:24:27

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#111 2008-11-26 19:36:49

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#112 2008-11-26 20:16:10

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#113 2008-11-26 22:58:37

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#114 2008-11-27 07:51:52

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#115 2008-11-27 08:11:37

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#116 2008-11-27 08:14:47

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#117 2008-11-27 08:59:44

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#118 2008-11-27 11:06:25

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#119 2008-11-27 11:26:24

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

#120 2008-11-28 13:33:25

Re: Feedback to: Help us test the release candidate for the upcoming 4.0.7

Board footer