TYPO3 Core

Ditto this for 4.5.0 final when upgrading from 4.5.0rc1 (how much could have changed?) Changing linked typo3_src back to rc1 (tried beta3 as well) does not help.

When I changed back to rc1 I tried running the upgrade script to install sys extensions... and when I went back to the ext manager, I noticed that it was the new hyper-ajaxified version... but the issue showed up before (when the ext manager was old-school) and the ext manager upgrade didn't affect the error.

Dropped all tables from the db and tried to re-install fresh, no dice. COMPARE fails.
Deleted all files in httpdocs and reinstalled new dummy... same error.
Re-pointed typo3_src to 4.5.0rc1 (on top of new dummy and empty db) and boom... everything works again.

So, feels like a javascript error... is that possible?

PHP 5.3.4
Mysql 5.1.49
RH kernel 2.6.18-194.26.1.el5PAE <-- weird 32bit kernel for addressing +3gigs ram... don't think that's the issue, but it is a weird part of the setup on this server

I think you are experiencing a different problem.
Did your "COMPARE" function work for you in the Install Tool?
From what I have understood, is that you are having a problem with the new Extension Manager? Am I right?
I'm having a problem with the Database Analyser in the Install Tool where the PHP function is illegally passed an array instead of a string which causes the database update to fail.

Exactly the same problem... it shows up both in the install tool and the ext manager.

And... evidently, it is something that showed up between 4.5.0rc1 and final.

Edited to add:

I found your bug report by googling the php warning that you mentioned above... same line, same file. I was finding the warning thrown when installing an extension via the ext manager (old, and later new versions). The net result was that the ext could not modify / update the db...

After that I went to the install tool and found the issue was the same there... (same warning in the log, same file, same line).

I then repointed typo3_src back to rc1 and cleared typo3/temp_* ... this did not change the error which I thought odd. I then tried repointing to beta3... same issue.

So, I figured, maybe the issue is in the db:

I dropped the db and attempted to recreate it in the same source (4.5.0final) / dummy environment with only the typo3conf/temp_* files deleted (note that cached js still existed... not sure that influences the install tool, but...). The install tool would not allow the db COMPARE to install the db. I did not, at this point, verify that it was the same error... however it appeared to be the same.

Then I erased the entire dummy environment to make sure all cached files were gone.

I honestly do not remember if I tried a clean install of 4.5.0final or not... I'll try that here in a bit and see what results I get...

Anyway, at this point I just repointed to 4.5.0rc1 and installed fresh, and everything is fine.

hth

Maybe your problem is the same, but I do not suffer your extension manager problem. After using the new ExtJs based EM I am not able to find error log entries.
This causes me to believe that these problems are not related to each other.

well... all I know is that the same inability to install db tables, and the same warning showed up using the old EM and the new EM (and the install COMPARE tool) and didn't go away until I a) got rid of all cached files and b) used rc1 source.

If anyone wants to test on my server, am willing to allow access.

What further information can we provide to help get this issue fixed?

I think I've spotted the problem and already found the source of it and maybe even a fix:

Source is the fix introduced in RC1 #17221, which solved the problem with "DROP TABLE" but apparently added this whole new problem with all other statements (ALTER and CREATE TABLE).

The fix should be reverting the solution of #17221, and adding the "DROPTABLE" check to the same place which used to be only INSERT (code is commented out). I'll attach a patch which should fix that, you might try it out, while I contact Xavier which will be able to solve that in DBAL so that we can integrate the fix in 4.5.1.

Thanks for reporting!

Xavier, could you please take a look at it if my patch is ok, so that we can have that in for 4.5.1? Thanks!

After applying the patch and deleting all cached files I can confirm that this patch has solved my problem.
The database scheme is now correct and no further error logs are found

I had the same problem. The COMPARE in the install tool couldn't create, delete or update tables. But this patch fixes the problem and everything works ;-)

Hi,

english is not my native language, sorry. Can anyone help me and tell me, what I have to do to fix this problem?

Please tell me what to do and where!

Hi Martin

You need to download the attached file (17399.diff) and patch class.ux_t3lib_db.php as following:

patch /path/to/your/typo3/sysext/dbal/class.ux_t3lib_db.php < 17399.diff

Thanks for your reply. I am using the newest version of Typo3 Winstaller. I tried to patch the data, like it is explained here in the bugtracker. But it does not work.

I downloaded the diff data and opened it. I saw the PHP Code to put into the php-data instead of the old code.

I saved it and it does not work.

I was describing the patch process in an unix environment using the "patch" command.
Have you cleared all caches and removed all temp or cached files before trying again to see if it worked?

Hi Ernesto and Xavier,

This patch fixes the problem.

I have one question. I can use the unix command with my shell programme?

In Shell I should write "patch /path/to/your/typo3/sysext/dbal/class.ux_t3lib_db.php < 17399.diff"?

The patch file includes the relative path to the file to be patched (because a patch could affect more than one file). Usually this is relative to the typo3_src root directory (as in this patch). So you should do:

$ cd /path/to/typo3_src/
$ patch -p0 < 17399.diff

The "p0" tells patch to strip "no leading pathnames" from the filenames. You should use "p1" if the patch was created from one level above (meaning it contains a "typo3_src.orig" component in the filenames).

@Martin: You are talking about Winstaller, not a version from SVN. It looks like you never have done anything with SVN at all and it seems you're working on a Windows machine.

When you want to patch files, you need to know more about SVN, patching, etcetera. It would take too much space here to explain exactly how it works, especially when you've never done this before. There is a lot of good information on the Internet.

I would recommend to take a look at WinMerge, a free Windows program which can patch for you without using SVN. Don't ask me how it works, it was a long time ago I've used it.

For Windows machines I can strongly recommend TortoiseSVN when working with SVN, but first read some documentation how SVN works.

PS: We are going to switch to GIT instead of SVN, so if you have to learn SVN, I would recommend to start learning GIT instead :-)

Good luck!

I use trunk and dbal enabled and experience the same problem. The comparison lists some db updates but they won't be applied.

No error message or warnings in install tool visible.

AdminTools -> Log:

Core: Error handler (BE): PHP Warning: mysql_query() expects parameter 1 to be string, array given in /var/www/makler/typo3_svn/trunk/typo3/sysext/dbal/class.ux_t3lib_db.php line 2937

Committed to:

- DBAL trunk (rev. 43947)
- DBAL_1-2 (rev. 43948)