And this is why we do not say we support mariadb @jeckodevelopment

On 7 September 2016 at 20:39, Phil Taylor notifications@github.com wrote:

Steps to reproduce the issue

[image: screen shot 2016-09-07 at 20 38 29]
https://cloud.githubusercontent.com/assets/400092/18325837/18e23528-753b-11e6-8eeb-4164acf9c0e9.png

Out of the box mariadb has a default sort_buffer_size of 2M (according to
their docs https://mariadb.com/kb/en/mariadb/server-system-variables/)

On the bare CentOS Linux release 7.2.1511 system I investigated the
default of 2M was overwritten with

sort_buffer_size = 64K

in the /etc/my.cnf...

Increasing the sort_buffer_size to 256k fixes the problem - however, the
issue Im raising to be fixed is not the buffer limit - but the generic
unhelpful error message that is generated, this error needs capturing and
explained better
Expected result

Every back end page has a red "Error" message with content that is helpful
information and not a generic error message that is unhelpful and doesn't
point to the root cause of the problem.
Actual result

Every back end page has a red "Error" message with content "An error has
occurred" and no other helpful information
System information (as much as possible)

mysql -V

mysql Ver 15.1 Distrib 5.5.47-MariaDB, for Linux (x86_64) using readline
5.1

cat /etc/redhat-release

CentOS Linux release 7.2.1511 (Core)

Additional comments

Also Discussed here: http://forum.joomla.org/viewtopic.php?t=916306

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11979, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8RyP7jWvE8SVpNGxS6xjZ7W7vuYNks5qnxL1gaJpZM4J3RyD
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

And this is why we do not say we support mariadb @jeckodevelopment

ok so new approach then

1. Fix The installer to not allow installation of Joomla on unsupported database servers

2. On the next release start shouting at current users using unsupported database services in the same way as the eol or php eol plugin does... pushing the responsibility to the user to use the supported services instead of having users moan (to me and you) that Joomla doesnt work on their "unsupported" configuration.

Apply 1 & 2 for all other known unsupported services...

it was an off topic remark

On 7 September 2016 at 20:50, Phil Taylor notifications@github.com wrote:

And this is why we do not say we support mariadb @jeckodevelopment
https://github.com/jeckodevelopment

ok so new approach then

1) Fix The installer to not allow installation of Joomla on unsupported
database servers

2) On the next release start shouting at current users using unsupported
database services in the same way as the eol or php eol plugin does...
pushing the responsibility to the user to use the supported services
instead of having users moan (to me and you) that Joomla doesnt work on
their "unsupported" configuration.

Apply 1 & 2 for all other known unsupported services...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#11979 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8W-vwS7AP3FLzMsNjqQuMx2Q3Ms0ks5qnxWUgaJpZM4J3RyD
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman why did you tag me?

werent we talking about mariadb being added to the list of supported
databases the other week and the argument was that although it may claim to
be 100% compatible we dont test with it. (if it wasnt you then forgive my
old age)

On 7 September 2016 at 21:02, Luca Marzo notifications@github.com wrote:

@brianteeman https://github.com/brianteeman why did you tag me?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11979 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8aWJrdwjxmLvMmxKML9XruS3kd3Zks5qnxhagaJpZM4J3RyD
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@PhilETaylor is there a method to test for the buffer size

Joomla also mentioned here in same context https://forum.synology.com/enu/viewtopic.php?t=91829

Lots of helpful information and links here http://dba.stackexchange.com/questions/60078/how-to-determine-the-optimal-sort-buffer-size

Current value can be found with the following (mysql) sql or reading the value from /etc/my.cnf (or other config files)

SHOW GLOBAL VARIABLES WHERE variable_name = 'sort_buffer_size'

most linux distros now use mariadb. Imho joomla should already officially support mariadb...

More references:

• http://joomla.stackexchange.com/questions/16536/error-out-of-sort-memory-consider-increasing-server-sort-buffer-size
• #9432

Imho joomla should already officially support mariadb...

It's not that Joomla can't. The comments I think Brian's referring to are the ones I made in Glip in the last couple of weeks. From the PHP application stack's perspective, there is no difference between MySQL, MariaDB, Percona, or any of the other "drop in MySQL replacements". So there's nothing to test at a PHP code level. To "officially" support any of those environments we're basically running our existing test suites and instead of connecting to a MySQL server we have it connect to a MariaDB, Percona, etc. server and ensure that the integrations function the same way as if we were connected to a "native" MySQL server.

One of my past projects made use of Percona versus native MySQL and we were running with the Framework's Database package as well as Doctrine for another part of the stack (different apps, different configs). In the time I spent researching the setup for that everything basically came back to being unable to differentiate between the different server types because the underlying PHP binaries are using the same MySQL libraries regardless of what you're connecting to. So you're reliant on having to read data out of the server's config to make a distinction or in the case of MariaDB since they have a different versioning schema reading that.

Long and short, anything that is compatible with the MySQL libraries used by PHP will in theory work with Joomla (or any PHP application). But there is no way at a code level to test for or apply behaviors specific to those environments.

So if i understand this correctly it is NOT a maria_db issue. It is simply a configuration issue where the default value used on some systems is below what both we need and what the db themselves recommends.

The question then is what to do.
1. We could add it to the pre-installation check - but to be honest that probably wont help in these cases.
2. We could add it to the published system requirements - but to be honest that probably wont help in these cases.
3. We could add it to the system information page - but to be honest that probably wont help too much in these cases.

1. What you are asking for is an error message that says "Error - your buffer size is too low" or something like that Is that something that can be done by php?

At the end of the day I can do 1,2,3 fairly easily but a developer like yourself will have to work out the 4

What I read about that error IMHO joomla should also do:

• display error with sql query for backend.
• display correct error message from mysql for backend.

If admin of website will get that info about error then can create ticket for support team of server.

Travis CI does allow testing against Maria DB, and multiple DB's in a more independent way from how we currently test, but I agree with @mbabker in that I'm not sure what we would get out of that testing, or if anything is testable. There are lots of sites in the wild that are running Maria DB. I think in the last year I remember 2 items brought up as "issues". One is this issue, the other was likely a Maria DB server config issue.

I agree that the Error message for the sort buffer size should be improved to be informative.

so what's the solution regarding the OP? I have this same generic pink error box in admin backend of a site and nothing (from Joomla forum) seems to resolve issue (making it go away).

in the /etc/my.cnf...
Increasing the sort_buffer_size to 256k fixes the problem

Or better still increase it to the MAriaDB default of 2M

Or replace the offending statement in administrator/modules/mod_menu/helper.php around line 41:

$query->group('a.id');

The original line was a fix for mssql, so that shouldn't be an issue!

You can find out about the offending statement by add

JLog::addLogger(array('text_file' => 'dberror.php'), JLog::ERROR, array('database','database-error'));

to libraries/cms.php. I placed it on line 63. This will make sure errors are logged and can be dealt with by those responsible for the infrastructure. As a result you'll see log/dberrors.php with:

2016-09-08T14:52:53+00:00 ERROR ::1 database-error Database query failed (error # 1038): Out of sort memory, consider increasing server sort buffer size SQL=SELECT a.*, SUM(b.home) AS home,b.language,l.image,l.sef,l.title_native
FROM j362_menu_types AS a
LEFT JOIN j362_menu AS b ON b.menutype = a.menutype AND b.home != 0
LEFT JOIN j362_languages AS l ON l.lang_code = language
WHERE (b.client_id = 0 OR b.client_id IS NULL)
GROUP BY a.id, a.menutype, a.description, a.title, b.menutype,b.language,l.image,l.sef,l.title_native

which can be traced back to helper.php. Although the fix will get you the proper menu in the backend, you might expect proper error handling. Note that the individual menu items don't appear due to this issue. No functionality lost, the menu items are still available and reachable through the all menu item.
That means you need to catch the error in administrator/modules/mod_menu/tmpl/default_enabled.php around lines 143

// Menu Types
    $menuTypes = ModMenuHelper::getMenus();
    $menuTypes = JArrayHelper::sortObjects($menuTypes, 'title', 1, false);

Note that the processing of the menu's ($menuTypes in code) continues to line 203.

It is fixed at #12991