I have a bug in my TYPO3 4.5 website :
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1283790586:
There is no entry in the $TCA array for the table
"pages_language_overlay". This means that the function enableFields()
is called with an invalid table name as argument. |
InvalidArgumentException thrown in file /t3lib/class.t3lib_page.php in
line 1150
I don't understand what happens, but my backend is still available.
How to fix it ?
I assume you do not know much about TYPO3 so I try to make clear how TYPO3 is working (with regards to the old version).
TYPO3 has definitions of the tables and fields in the database.
First part are the MySQL definitions (since 8 it might be other databases than MySQL).
The second part (TCA = TYPO3 Configuration Array) are the definitions how these tables build the BackEnd(BE) Interface for an editor.
As these informations can be enhanced by extensions, each extension can add it's information to a (cached) pool and this pool is considered a reference.
The database definitions are located in files ext_tables.sql. The TCA was generated in ext_localconf.php and ext_tables.php. Today TCA modifications should be done in Configuration/TCA/tablename.php (for new tables) or Configuration/TCA/Override/tablename.php (for modification of existing tables).
Before all these files are included and executed for every call they are collected and stored as one resulting PHP-file.
Your problem might occur because there is a syntax error in the collected file and up to the error all information is build up, but everything after the error is missing.
Try to clean up your installation and remove these caches: in pre 6 versions there are files temp_CACHED_<hash>_ext_tables.php and temp_CACHED_<hash>_ext_localconf.php in your typo3conf/ folder. Remove them all. The next call to TYPO3 (FE or BE) will rebuild two files. Make sure these have no syntax errors.
In the install-tool (<domain>/typo3/install/) you can clear all caches and compare the existing database with the gathered definition from all active(!) extensions. If there are differences the database can be 'corrected'. Be sure to have a database backup before you change anything.
The usal answer: TYPO3 4.5 is outdated. Upgarade your installation to a newer version. Maybe the Bug is allready solved.
If an Update is not possible then the question is what you have doing that the error is thrown. What changes were done at latest? What extension was shortly installed or updated?
Related
I'm using MySQL Workbench and I am trying to create a routine. However, At the time of creating routine some error comes,then i deleted that routine. Now I synchronize the model with the existing database, the Routine group error is coming, though i remove that routine group. Can anyone help me how to remove this error from Model?
The _SYNTAX_ERROR suffix is added by MySQL Workbench to indicate that it found a syntax error in your routine code. Once you fixed that the name will change back to what you gave it. And then you can also synchronize your model.
I faced the same issue, cause i copy&pasted some c# code into a routine group, and it immediately became invisible by workbench. Synchronization now always reporte errors, even after deleting the whole routine group. The faulty code was stuck somewhere, inaccessible through the Workbench UI.
Just found a solution atm:
Do a regular synchronization and tell Workbench to change the sync-direction on the error entries. This will remove the faulty lines of code, even if they are not accessible through the Workbench UI.
I've done quit a couple of upgrades from t3 4.X to 6.X but this time I have a persistent problem I cannot not understand. After doing the upgrade (all upgrade wizards ran fine), I can see in the database that the image column of tt_content has the FAL index values in it and not the file names anymore. The references to the FAL tables are ok as well. When I look at CEs like textpic, however, the image tab does not show any images. No images are shown in the FW either.
I could think of trying to fix this in TS but I want to upgrade this install to 8 and think that when the first upgrade needs such a clutch, further updates will be doomed right from the start.
[edit #1]
I'm 100% sure it worked before. But now, whatever I do (update ref index, ...), sys_file_reference stays empty.
[edit #2]
I now followed How to upgrade TYPO3 4.5 to 6.2 and it worked. Strange thing is that it's not really that different from how I did it all the time. Maybe it just needed me to try it 27 times :)
your problem might depend on individual contentelements. if you have individual definitions the upgrade wizard does not know, these definitions stay unchanged and as a result your 'new' images (sys_file records) are not inserted correctly.
Individual CEs might need extra care at each upgrade.
After 6.2 FAL was stable and had no big changes. I would not expect the same amount of work for further upgrades.
In TYPO3 Version 6.2 the fileadmin-folder is represented by an automatically created storage record. In this record is a setting to respect case-sensitive filenames.
If this setting is not enabled before the migration of all media-files, then all media-files with upper-case characters are written in the database but not found anymore by the file-system because they are written lower case then.
So if you never find any images on the page after migration I assume all images had one or more upper-case characters in the filename.
If you've only a few images you could change the filename in the database, specifically in the table sys_file and the column identifier, else it's the best to repeat the whole process and care about the setting in the storage-record fileadmin in time.
Storage-records are located on the root-page [uid=0] in the backend, where also backend-users are resided.
Below is a partial screenshot of the database-table sys_file:
My experience was that mysql mode SQL_STRICT_TRANS_TABLES was in the middle of the problem. Once changed, sys_file_reference begins to fill the records correctly.
Has anyone worked around the problem that Activiti (5.18.0, and I tried the 6 beta, too) won't use the database schema resp. table prefix on Postgres?
On startup, it will not find the tables, if they aren't in the public schema (or another schema that's in the search_path). After that I think it's ok.
There seem to be two bug reports, but that issue doesn't seem solved.
https://activiti.atlassian.net/browse/ACT-1708
https://activiti.atlassian.net/browse/ACT-1968
I tried different solutions, one of them was setting the search_path for the database with activiti as its first entry, but it seems that parts of a Postgres library used change the search_path dynamically, so that sooner or later Activiti will complain again.
I'm talking about the integration of the Activiti ProcessEngine in my own application.
After debugging the source code of Activity (actually, I cloned https://github.com/Activiti/Activiti (yesterday!?) and used the branch activiti6) I found that I was actually lacking an attribute.
So if you set the schema and the prefix, then you have to set the "tablePrefixIsSchema" attribute to "true"!
processEngineConfiguration.setDatabaseSchema("activiti");
processEngineConfiguration.setDatabaseTablePrefix("activiti.");
/**
* NOTE!
*
* If we set the prefix (for whatever reasons) and it's the same as the
* schema, then the following attribute has to be set to "true"!!!
*/
processEngineConfiguration.setTablePrefixIsSchema(true);
This solved the whole issue.
I'll try now with Activiti 5.18 and update this solution. (I use Postgresql 9.3 and the driver 9.3-1103-jdbc41.)
The original error was (if others run into this):
org.activiti.engine.ActivitiException: Activiti database problem: Tables missing for component(s) engine, history, identity
at org.activiti.engine.impl.db.DbSqlSession.dbSchemaCheckVersion(DbSqlSession.java:925)
Is it possible to change the order of the displayed (database) tables in the backend list module? I've got a sysfolder with several different tables of my extension and i want the "important" tables to be shown on top. TYPO3 Version is 6.2 LTS.
Since TYPO3 7 you can do that with page TSconfig:
mod.web_list.tableDisplayOrder
See also:
https://docs.typo3.org/m/typo3/reference-tsconfig/main/en-us/PageTsconfig/Mod.html#tabledisplayorder
The tables are displayed in the same order as TCA arrays are ordered in ext_tables.php in your extension.
Don't forget to Flush system cache (now in Install Tool > Important actions) to reflect the changes.
EDIT: Important for extensions built with Builder 6.2:
To make sure that works you need to replace $GLOBALS['TCA'] to $TCA in ext_tables and all TCA files!
For an example change every occurrence of:
$GLOBALS['TCA']['tx_myext_domain_model_mymodel']
to
$TCA['tx_myext_domain_model_mymodel']
Clear the system cache from Install Tool and it will work.
Recently we added a "audit_logs" table to the database, and after some frustration I realised that there was already an "auditlog" table in the database for some reason. It wasn't being used so I dropped it. I deleted the Auditlog.pm and AuditLogs.pm files from my schema, and then regenerated. For some reason DCSL again created AuditLogs.pm for the "audit_logs" table, even though there was no longer an "auditlog" table or Auditlog.pm file that would conflict with it.
I have tried just about everything I can think of to get it to generate Log.pm without success. The only thing that I can figure is that it is caching the moniker map somewhere, and I cannot seem to reset it.
I eventually tracked this problem down to an issue with the Lingua inflector. It was picking up "logs" as a singular verb instead of a plural noun. This happened because it followed the word "audit" which ends with "it." Basically, I had to write a custom moniker_map function that added an exception for audit_logs.