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!
Related
We have a large number of deleted pages in our application. However, the versions still exits in the version storage. Is there any way to delete them.
I tried by traversing through the /jcr:system/jcr:versionStorage and identifying the deleted pages. However, when I try to Delete the version, I get the following error.
javax.jcr.nodetype.ConstraintViolationException: Item is protected.
Also, if I try to Purge the page through code, due to the high volume of deleted pages present in the repository, I get the error based
(org.apache.jackrabbit.oak.plugins.index.property.strategy.ContentMirrorStoreStrategy) - Traversed 10000 nodes (31911 index entries) using index cqParentPath with filter Filter(query=sele
ct [jcr:path], [jcr:score], * from [nt:version] as a where isdescendantnode(a,
Please help, as I am literally stuck with this issue.
So basic question is, is there any way to delete the nodes containing the versions for deleted pages in JackRabbit (AEM)
I need to create an export of all pages and get information about the last modification date and who did the last modification.
Last modification date is easy: that's stored in SYS_LASTCHANGED in the pages table. But how can I find the information about who did the change? For changes to pages that's easy as well, as I can check sys_log and sys_history and search the pid in the field recuid in combination with tablename. For tt_content records I can do a select first to get all records for a specific page. And then search recuid and tablename accordingly.
But how about all the other records, e.g. from plugins? Do I really need to iterate over all tables and the pid field to get all possible records?
I think you have a lot of work to do, as the information SYS_LASTCHANGED is not very trustworthy.
Depending on the rendering process multiple records are used for building up a page. and more and more information does not come from records but from files, which are versioned by chance in a git repository (or similar).
Just in case all(!) information is stored in records (tsconfig, typoscript, fluid templates in records (sys_file for files)). There are thousands of ways a page is generated and which information influences the current page rendering.
just some examples:
the typoscript is changed. does it result in a rendering change of the current page?
a record (e.g. tt_content) is deleted. so this record will no longer show in the page. will you consider all invisible (delted, hidden, time restricted) records?
TYPO3 has constructions like: show content from page X, show content records X,Y,Z from other pages
translations: does a change in another language than the current is a change to the current language (a fallback might be possible)
if you consider links in menus or text: if another page which is linked in the current page gets disabled TYPO3 does not generate a link any longer
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.
I started using django-simple-history in order to keep the history but when I delete an object (from admin page at least) I notice that it is gone for good.
I suppose I could create tags and "hide" objects instead of deleting in my views but would be nice if there is an easier way with django-simple-history, which would also cover admin operations.
When objects are deleted, that deletion is also recorded in history. The object does not exist anymore, but its history is safe.
If you browse your database, you should find a table named:
[app_name]_history[model_name]
It contains a line with the last state of the object. That line also contains additional columns: history_id, history_change_reason, history_date, history_type. For a deletion, history_type will be set to "-" (minus sign).
Knowing that, it is possible to revert a deletion programmatically, but not through the Django Admin. Have a look at django-simple-history documentation for details on how to do it programmatically.
Hope that helps!
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.