modxcms / revolution

MODX Revolution - Content Management Framework
https://modx.com/
GNU General Public License v2.0
1.36k stars 529 forks source link

modx-2.5.1-pl "new" install fail #13121

Closed max-dark closed 7 years ago

max-dark commented 8 years ago

Summary

setup fail

in logs

$> head core/cache/logs/install.config.2016-09-09T10.52.55.log
[2016-09-09 10:52:55] (ERROR @ /home/max/sites/cms/modx-revolution/setup/includes/tables_create.php : 116) Could not create table `revo_access_policies`
SQL: CREATE TABLE `revo_access_policies` (`id` INTEGER unsigned NOT NULL AUTO_INCREMENT, `name` VARCHAR(255) NOT NULL, `description` MEDIUMTEXT NULL, `parent` INT(10) unsigned NOT NULL DEFAULT '0', `template` INT(10) unsigned NOT NULL DEFAULT '0', `class` VARCHAR(255) NOT NULL DEFAULT '', `data` TEXT NULL, `lexicon` VARCHAR(255) NOT NULL DEFAULT 'permissions', PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`), INDEX `parent` (`parent`), INDEX `class` (`class`), INDEX `template` (`template`)) ENGINE=MyISAM
ERROR: Array
(
    [0] => 42000
    [1] => 1071
    [2] => Specified key was too long; max key length is 1000 bytes
)

[2016-09-09 10:52:56] (ERROR @ /home/max/sites/cms/modx-revolution/setup/includes/tables_create.php : 116) Could not create table `revo_content_type`
$> head core/cache/logs/install.config.20160909T105327.log
[2016-09-09 10:53:27] (ERROR @ /home/max/sites/cms/modx-revolution/core/xpdo/om/xpdoobject.class.php : 240) Error 42S02 executing statement: 
Array
(
    [0] => 42S02
    [1] => 1146
    [2] => Table 'cms_modx.revo_context_setting' doesn't exist
)

[2016-09-09 10:53:27] (ERROR @ /home/max/sites/cms/modx-revolution/core/xpdo/om/xpdoobject.class.php : 240) Error 42S02 executing statement: 
Array
$> head core/cache/logs/error.log
[2016-09-09 10:53:28] (ERROR @ /home/max/sites/cms/modx-revolution/core/xpdo/om/xpdoobject.class.php : 240) Error 42S02 executing statement: 
Array
(
    [0] => 42S02
    [1] => 1146
    [2] => Table 'cms_modx.revo_context_setting' doesn't exist
)

[2016-09-09 10:53:28] (ERROR @ /home/max/sites/cms/modx-revolution/core/xpdo/om/xpdoobject.class.php : 240) Error 42S02 executing statement:

Step to reproduce

just try to install it and go to /manager/

Observed behavior

in console

$> php-server
PHP 7.0.10-1 Development Server started at Fri Sep  9 14:53:24 2016
Listening on http://localhost:8000
Document root is /home/max/sites/cms/modx-revolution
Press Ctrl-C to quit.
[Fri Sep  9 14:54:32 2016] ::1:46714 [500]: /
[Fri Sep  9 14:54:52 2016] ::1:46716 Invalid request (Unexpected EOF)
[Fri Sep  9 14:55:01 2016] ::1:46726 [404]: /manager/
[Fri Sep  9 14:55:13 2016] ::1:46728 Invalid request (Unexpected EOF)

in browser

503 Error

Page not found

The page you requested was not found.

Expected behavior

i don't know

Environment

modx-2.5.1-pl "traditional" package OS: Debian GNU/Linux 'testing' amd64 DB: MariaDB 10.0.26 with default config run on PHP 7.0.10-1 Development Server (php with -S option)

$> uname -a
Linux node 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
$> php --version
PHP 7.0.10-1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.10-1, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans
$> mysql --version
mysql  Ver 15.1 Distrib 10.0.26-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
$> LC_ALL=en_US apt list apache2
Listing... Done
apache2/testing,now 2.4.23-4 amd64 [installed]

DB Variables

$> mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 578
Server version: 10.0.26-MariaDB-3 Debian buildd-unstable

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> select @@SQL_MODE, @@GLOBAL.SQL_MODE \G
*************************** 1. row ***************************
       @@SQL_MODE: 
@@GLOBAL.SQL_MODE: 
1 row in set (0.00 sec)

MariaDB [(none)]> show global variables like '%mode%' \G
*************************** 1. row ***************************
Variable_name: gtid_strict_mode
        Value: OFF
*************************** 2. row ***************************
Variable_name: innodb_autoinc_lock_mode
        Value: 1
*************************** 3. row ***************************
Variable_name: innodb_strict_mode
        Value: OFF
*************************** 4. row ***************************
Variable_name: old_mode
        Value: 
*************************** 5. row ***************************
Variable_name: slave_ddl_exec_mode
        Value: IDEMPOTENT
*************************** 6. row ***************************
Variable_name: slave_exec_mode
        Value: STRICT
*************************** 7. row ***************************
Variable_name: sql_mode
        Value: 
7 rows in set (0.00 sec)

MariaDB [(none)]> show global variables like '%strict%' \G
*************************** 1. row ***************************
Variable_name: gtid_strict_mode
        Value: OFF
*************************** 2. row ***************************
Variable_name: innodb_strict_mode
        Value: OFF
2 rows in set (0.00 sec)

MariaDB [(none)]> show global variables like '%sql%' \G
*************************** 1. row ***************************
Variable_name: slave_sql_verify_checksum
        Value: ON
*************************** 2. row ***************************
Variable_name: sql_auto_is_null
        Value: OFF
*************************** 3. row ***************************
Variable_name: sql_big_selects
        Value: ON
*************************** 4. row ***************************
Variable_name: sql_buffer_result
        Value: OFF
*************************** 5. row ***************************
Variable_name: sql_log_bin
        Value: ON
*************************** 6. row ***************************
Variable_name: sql_log_off
        Value: OFF
*************************** 7. row ***************************
Variable_name: sql_mode
        Value: 
*************************** 8. row ***************************
Variable_name: sql_notes
        Value: ON
*************************** 9. row ***************************
Variable_name: sql_quote_show_create
        Value: ON
*************************** 10. row ***************************
Variable_name: sql_safe_updates
        Value: OFF
*************************** 11. row ***************************
Variable_name: sql_select_limit
        Value: 18446744073709551615
*************************** 12. row ***************************
Variable_name: sql_slave_skip_counter
        Value: 0
*************************** 13. row ***************************
Variable_name: sql_warnings
        Value: OFF
13 rows in set (0.00 sec)

logs.zip

pixelchutes commented 8 years ago

Seems related to #12987 and possibly strict mode w/ MariaDB.

EDIT: As a temporary workaround, if disabling strict mode is an option for you, I believe that can at least get you installed while this is looked into further.

OptimusCrime commented 8 years ago

Indeed. MariaDB is not supported yet

Jako commented 8 years ago

If MariaDB strict mode is not supported, this should be fixed soon.

Some index keys are getting too long (this occurs with MySQL and a utf8mb4 collation too #12445). I suppose name and class. Would it be a solution if the field length of both fields is reduced to 249 or less?

muzzwood commented 8 years ago

If any lengths of fields do get changed, hopefully it can be changed so any varchar fields aren't longer than 191 in order to support utf8mb4.

OptimusCrime commented 8 years ago

I don't understand just what is causing this error. Can anyone shed some light on this?

FBachofner commented 8 years ago

How many DB tables does a default MODX installation have?

I have 71 in mine.

This thread seems to indicate that a table containing the name "revo_context_setting" or possibly "revo_content_type" should exist.

I do not have either one such named tables in both working and "non-working" MODX installations [I have a file manager display problem _only_ (no other apparent problems) -- see issue #13148 ].

Interesting side note: in the error log posted above, the installer is trying to create a table "revo_content_type" but the error comes back: "Table 'cms_modx.revo_context_setting' doesn't exist"

The table prefix "cms_modx." can probably be safely ignored, but what about the huge apparent mismatch between the table names?!

OptimusCrime commented 8 years ago

Mine has 71 too. No custom tables in that installation

Jako commented 8 years ago

@OptimusCrime The index length issue/solution is described at http://stackoverflow.com/questions/6172798/mysql-varchar255-utf8-is-too-long-for-key-but-max-length-is-1000-bytes

There are two different length restrictions with a max length of 1000 bytes and 767 bytes depending on the storage engine (the default of InnoDB is shorter). So 191 bytes for an indexed field should be safe.

See: http://stackoverflow.com/questions/20123824/how-can-i-alter-an-indexed-varchar255-from-utf8-to-utf8mb4-and-still-stay-unde

Jako commented 8 years ago

Since changing the field length would be a BC, we should discuss how a smooth AND a 'as fast as possible' change could be done.

sottwell commented 8 years ago

The allowed max for InnoDB depends on strict mode. In strict mode, it's 191, otherwise it can be any length but will be truncated in use.

sottwell commented 8 years ago

https://github.com/modxcms/revolution/issues/12445

OptimusCrime commented 8 years ago

@Jako Well, following BC it can't happen before 3.x, but I'd argue that this is so breaking for MODX as a platform that the changes should be applied to 2.x too.

Mark-H commented 8 years ago

I'm thinking we can actually fix the index lengths in a 2.x release if it only affects new installations.

OptimusCrime commented 8 years ago

Will it though? I thought these lengths are also reflected in all the related xPDO models too? Although they might not have any effect.

Mark-H commented 8 years ago

The updated lengths would indeed be in the model classes/maps, but if the index in the database has a different length, xPDO doesn't automatically truncate it to my knowledge on reading or saving. Would need to be tested to be sure, but if that works as I think it does that could potentially be solved in 2.x.

If you were to call $modx->getManager()->alterField or alterIndex if that exists as well, that would probably update the database field/index according to the model, so we shouldn't do that in this case.

OptimusCrime commented 8 years ago

Sounds like a plan

sottwell commented 7 years ago

I think this one is a duplicate and can be closed?

rthrash commented 7 years ago

@sottwell do you realize how many points this would have been worth at the Munich #modxbughunt? ;)

FBachofner commented 7 years ago

@sottwell, @rthrash:

Do I get original "credit" for identifying and referencing (effectively) duplicate issues in my post about the forthcoming mySQL 8.x ? ;-)

pixelchutes commented 7 years ago

Closing as dupe... šŸš« šŸ˜‰

no_points_for_you