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.
Related
I am usung TYPO3 V11.5.3 and figured out, that some pages not working anymore. The reason was, that in the database of the extension, in some entries the delete flag have been set.
If I set this values back to 0 with phpmyadmin, the next day these values are again set to 1 and the web pages are not working.
What's going on there?
How can I avoid it, that TYPO3 sets again these values?
Edit
Rudi, this extension has worked for about 1 year without any problem.
The extension has 3 databases, Album, Discs and Tracks. A album has one or more discs and a number of tracks. The extion is collecting this information (BE) and displays it (FE).
Can it be, that TYPO3 is automatically setting back the changes I have made with phpmyadmin?
** EDIT **
I tried several things, but they didn't solved theproblem!
Finally, I deleted the effected tables and but them new. These seems to solve the problem.
Finally I figured out was the problem was.
I generated my extension via extension_builder. And extension-builder created a list view for the frontend, which I didn't use, but also not deleted. This list view was found by GOOGLE and executed the delete function of this list view!
There are several duplicate files in my TYPO3 installation. Also some dupes in sys_file for the same file (different 'uid', same 'identifier' and 'storage').
These have several reasons:
first of all, this is an older site, so the previous behaviour (before FAL) resulted in duplicates anyway which were then moved to _migrated. (I am not sure if the upgrade wizard at that point did some cleaning up as well.)
editors just upload things more than once sometimes and lose track of existing files (in spite of filemounts used and a sensisble directly structure and thumbnails)
I don't know the exact reason for the dupes in sys_file, but they appear to be mostly related to the _migrated files.
What I would now like to do is create a script / extension to clean this up or assist editors to clean it up (e.g. show duplicates).
files with same content hash (but different filename / path) could be merged which means also merging all references
duplicates in sys_file should also get merged
I have a rough idea how this could be done but would like to know if there are already tools, experiences or knowledge anyone could share.
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?
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.