Feedback to: Textpattern CMS 4.6.0 beta 3 released

testdeputy · 2016-09-02 11:18:54

in response to Bloke’s Q: what are they?
string(15) “10.0.20-MariaDB” int(1) int(0)

Bloke · 2016-09-02 11:28:17

testdeputy wrote #300949:

string(15) “10.0.20-MariaDB” int(1) int(0)

Bingo. It’s comparing the first digit (a 1) against a 5 instead of using the first major revision number or employing version_compare(). Although we don’t officially support MariaDB, I’ll fix that as it’ll break when (if) MySQL itself goes above version 9. Thanks for the report.

EDIT: fixed.

Last edited by Bloke (2016-09-02 11:40:30)

Bloke · 2016-09-02 11:51:49

colak wrote #300943:

The txp_img folder is excluded in the b3 archive.Is there a reason for that?

Probably because we don’t use it any more. I didn’t notice, but it’s not in the repo and probably hasn’t been for a while now. If it was in beta.2, maybe whoever built the package still had it on their local machine.

It shouldn’t overwrite anything if you’re using it already (e.g. for MLP) since it’s not included in the repo, as long as OSX doesn’t do weird things.

testdeputy · 2016-09-02 11:56:53

Bloke wrote #300950:

.. I’ll fix that as it’ll break when (if) MySQL itself goes above version 9.

fix
thanks, works!

phiw13 · 2016-09-02 12:20:44

Bloke wrote #300946:

I wonder if the upgrade assumed you were using utf8, forced utf8mb4 on you, when you were actually previously using latin1 or something. Not sure, it’s not my area of expertise.

Actually I tested with two different local installs, one is fairly old (latin1/utf8), the other one has been there since summer (latin1/utf8mb4). But I think that is a distraction.

EDIT: actually, could you please temporarily hack your textpattern/include/txp_list.php file. Find line 214ish (in beta.3) and change the line to read:

$total = getThing("SELECT COUNT(*) FROM $sql_from WHERE $criteria", 1);…

with only Title, Body and Excerpt checked:

SELECT COUNT(*) FROM textpattern textpattern
        LEFT JOIN txp_category category1 ON category1.name = textpattern.Category1 AND category1.type = 'article'
        LEFT JOIN txp_category category2 ON category2.name = textpattern.Category2 AND category2.type = 'article'
        LEFT JOIN txp_section section ON section.name = textpattern.Section
        LEFT JOIN txp_users user ON user.name = textpattern.AuthorID WHERE textpattern.Title like '%ノクターン%' or textpattern.Body like '%ノクターン%' or textpattern.Excerpt like '%ノクターン%'

And the offending articles are found (both title and body contain the string). Other searches, where the string only exists in body or keywords works fine.

The problem only seems to happen when “Search All” is checked in the dropdown – nothing is found and the mentioned error is flagged. Searching with Title, Body and Excerpt checked, or with additional criteria (Keywords, Author, Section, Categories) works fine.

Actually, include things like ID, Posted, Modified as criteria and the error pops up; of course, the given string (ノクターン) is non-sensical for those 3 criteria (but then, the same can be said of a string using Roman characters).

phiw13 · 2016-09-02 12:25:55

Bloke wrote #300945:

I like that! Very neat and collapses logically on mobile too. Maybe we could ~~steal~~ ahem ~~plagiarise~~ cough pay homage to that in Hive.

:-)

Failing that, note to self: install Sandspace in future.

It is not a bad theme… a quiet environment for a rainy day or scorching hot afternoon… Goes well with the music

philwareham · 2016-09-02 13:03:30

I’ve put the switch list multi-edit checkboxes on left now. Will investigate the save button and duplicate/create links positioning later.

hcgtv · 2016-09-02 13:19:20

Bloke wrote #300937:

Tipping the balance towards 100% perfection in favor of one group of users — even if it’s noble and just — is going to negatively impact other groups. My goal is to allow the remaining 20% in each camp enough customisation through plugins and hooks to tweak the workflow higher than the out-of-the-box 80% to suit.

Stef, as always, thanks for your post, thanks for taking the time.

My question is, why can’t we have the best of all worlds?

Desktop, Mobile, Screen Reader and Color Blind modes.

Why can’t the admin adjust accordingly, like most websites do on mobile, or be programmable via preferences?

philwareham · 2016-09-02 13:22:55

hcgtv wrote #300957:

Stef, as always, thanks for your post, thanks for taking the time.

My question is, why can’t we have the best of all worlds?

Desktop, Mobile, Screen Reader and Color Blind modes.

Why can’t the admin adjust accordingly, like most websites do on mobile, or be programmable via preferences?

Sure, create a pull request of the code and I’ll look over it.

Bloke · 2016-09-02 13:34:47

phiw13 wrote #300953:

The problem only seems to happen when “Search All” is checked

Okay, got it. Thank you. It’s the Posted and Modified columns. Comparing non-latin chars against those fields returns the ‘illegal mix of collations’ error. Question is, what to do about it.

Can’t alter the collation of those columns (as far as I know) because they’re of datetime type, which doesn’t have a collation. But joining them in the query together with character-based columns that do have a collation results in the error.

Not sure if it’s possible to force the collation in the query. Not had any luck so far. Even if we could, it has a performance impact which is a problem on sites with a large article count.

I might be able to implement an as-yet unimplemented feature ‘case sensitive’. I was intending to use it to do binary comparisons but left it out for now. As it happens, using BINARY in front of the Posted and LastMod columns allows the query to pass so if I add that feature and retrofit the Articles panel with that option for those two columns, it should work:

SELECT COUNT(*) FROM textpattern textpattern
        LEFT JOIN txp_category category1 ON category1.name = textpattern.Category1 AND category1.type = 'article'
        LEFT JOIN txp_category category2 ON category2.name = textpattern.Category2 AND category2.type = 'article'
        LEFT JOIN txp_section section ON section.name = textpattern.Section
        LEFT JOIN txp_users user ON user.name = textpattern.AuthorID
        WHERE textpattern.ID in ('льби')
        or textpattern.Title like '%льби%'
        or textpattern.Body like '%льби%'
        or textpattern.Excerpt like '%льби%'
        or textpattern.Section like '%льби%'
        or section.title like '%льби%'
        or find_in_set('льби', textpattern.Keywords )
        or textpattern.Category1 like '%льби%'
        or textpattern.Category2 like '%льби%'
        or category1.title like '%льби%'
        or category2.title like '%льби%'
        or convert(textpattern.Status, char) = 'льби'
        or textpattern.AuthorID like '%льби%'
        or user.RealName like '%льби%'
        or textpattern.Image in ('льби')
        or BINARY textpattern.Posted like '%льби%'
        or BINARY textpattern.LastMod like '%льби%';

Watch this space.

Bloke · 2016-09-02 13:57:58

Okay, anyone affected by the non-latin search bug, I think this is now fixed. Please test and report back. Thank you for the invaluable reports and feedback so far.

Bloke · 2016-09-02 14:13:17

hcgtv wrote #300957:

why can’t we have the best of all worlds?

We can… ish. A plethora of preferences to set things this way and that is one approach, but we tend to opt for convention over configuration. It’s landed us in hot water over the years (cf. the Forms panel and those blessed “fixed” Forms) but in general it serves us well by cutting down the number of prefs. The UI tries to remember what you’ve set wherever possible so you toggle something and it’s like that next time. “Soft prefs”.

Myriad “hard preferences” to tweak this and that is not the way I’d like to see the interface go, as it’d still be constrained by what we believe is the best workflow. The best workflow is actually down to the user. Hence I’d rather invest the time and energy into opening up the interface to allow a bot_wtc-style plugin to appear that can take advantage of the many hooks to customise the interface.

Longer term, drag ‘n drop reorderable blocks. So if you, for example, don’t like the Save button where it is on one panel, drag it somewhere else. It’ll remember that position for you and you alone. It’s your workflow, after all. No endless prefs, no fuss.

There’ll probably be constraints where you can drag and drop stuff, and what you can move, but on the whole I’d like to see that. At the moment we’re just trying to implement the most optimised solution for all concerned (which is going to involve compromise for now) without introducing too many prefs we’d later have to remove when the interface becomes draggable.

Textpattern CMS

Textpattern CMS support forum

#25 2016-09-02 11:18:54

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#26 2016-09-02 11:28:17

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

testdeputy wrote #300949:

#27 2016-09-02 11:51:49

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

colak wrote #300943:

#28 2016-09-02 11:56:53

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300950:

#29 2016-09-02 12:20:44

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300946:

#30 2016-09-02 12:25:55

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300945:

#31 2016-09-02 13:03:30

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#32 2016-09-02 13:19:20

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

Bloke wrote #300937:

#33 2016-09-02 13:22:55

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

hcgtv wrote #300957:

#34 2016-09-02 13:34:47

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

phiw13 wrote #300953:

#35 2016-09-02 13:57:58

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

#36 2016-09-02 14:13:17

Re: Feedback to: Textpattern CMS 4.6.0 beta 3 released

hcgtv wrote #300957:

Board footer