In Gridelements 11.0.0-dev and TYPO3 11.5.24 the following error occurs, if a content element is moved by drag and drop to an empty gridelement:
Attempt to insert record on page '[root-level]' (0) where this table, tt_content, is not allowed.
In my opinion, the current page uid is not passed when pasting the content element.
Does anyone have a solution for this error?
Gridelements is still not officially available for TYPO3 v11.5. If you rely on Gridelements, you should consider supporting the crowdfunding campaign. There you get access to a protected GitHub repository with a v11.5 compatible version.
Otherwise you should consider to migrate to alternatives like EXT:container (which is quite popular lately) or similar extensions.
Related
Is there a possibility to update all slugs of all pages in all languages?
In an installation of one of my clients are hundreds of pages in multiple languages with wrong slugs (e.g.: prefix translate+german page name instead of translated page name etc.).
I remember an upgrade wizard in TYPO3 v9 but in version i cannot find this wizard.
This upgrade wizards appears if you just empty all slug fields of the table pages which is the fastest way to renew all slugs.
For special cases, maybe you would like to build your own Command.
Some nice thoughts (and helper methods) have been collected under TYPO3/Extbase How to create unique slug within create action?
I am working on a TYPO3 v10 LTS website with integration of the news extension v8.3.0. Many news are assigned to multiple categories and they are displayed on different detail pages according to their assigned categories. Now I would like to define one categories as master and use this category for the generation of canonical links to avoid duplicate content problems. On an older version of the website (TYPO3 v7 LTS) I used the solution explained here: https://www.typo3.net/forum/thematik/zeige/thema/116056/
I'm not so experienced with TYPO3 v9/v10 LTS yet, but I think that there must be a solution with routeEnhancers.
Any hints are welcome.
You need no route enhancer, just use the basic configuration of EXT:news.
one solution would be: for detail-view (show) always use one page. in this way each news will have a unique url. (problem: you can't ´return´ to the former list view with a hard link[1], as you don't know from which list you came)
2nd: configure a show-page with your news-categories: this page will be preferred for detail view (it always will be the first category) and each news will always be shown on this category detail page. (no ´return´ to the original list as above)
[1] you can't use a page as link target, but you can use javascript:history.back()
TYPO3 Environment
TYPO3 v9.5.3
EXT:news (7.0.8)
EXT:indexed_search (9.5.3)
Use Composer: No
The Problem
On EXT:indexed_search result listing page, Custom extension record's slug URL are not generating. The slug only contains TYPO3 page URL.
Example; The URL should be http://thedomain.com/news/detail/announce-first-news/, but it currently only generates http://thedomain.com/news/
As per our analysis, it seems TYPO3 v9 site management's slug feature cause issue, and there could be following possible issues.
Issue #1
The major issue is, After enabling site management's slug setup, No more indexing happening for a custom extension.
Issue #2
Indexing result will lose after the page will refresh or move to another page (After clear cache data will show again).
Issue #3
If we create new records for a custom extension, then the created new records will not be indexing.
Issue #4
If anyhow, we have done the indexing and search works well, then at search result listing page, The link redirect to the main action like Listing. Because cHash is missing to each record, That's a bit strange!
Does anyone have any idea/solution? Highly appreciate your any thoughts, Thanks a lot!
Cheers,
Team NITSAN
This has been fixed with release of 9.5.5, released 4.3.2019. Check out the release notes which you can find here: https://get.typo3.org/release-notes/9.5.5
The issue for the bug is https://forge.typo3.org/issues/86994
However there has been also a regression detected which is described at https://forge.typo3.org/issues/87855 but it has already been fixed as well. The bug occurs if MYSQL strict mode is used
I'm using tx_news with imported news entries from tt_news.
The import worked well, but some news contain "old" links in the body field of this form
/index.php?id=10&tx_ttnews[tt_news]=123&tx_ttnews[mode]=single&tx_ttnews[backPID]=2&no_cache=1
Can these links be "mapped" somehow to work with tx_news?
Using Typo3 7.6.12
In short, this is not possible. However there are several options I am thinking of. In general those links should be defined by using the EXT:linkhandler
1) Convert manually: Sounds sad but if not too many links are there, it is certainly the fastest one.
2) Use one of the hooks of TYPO3 which are used during the bootstrapping and do custom redirects. E.g. $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/index_ts.php']['preprocessRequest'].
3) Hook into the error handling and redirect right before showing any error page. One example to check out could be an ext I did: https://github.com/georgringer/fast_redirect. It must be certainly modified to fit your needs.
What you can actually do as well, which I did for a big import a while ago: Remove all news records again, truncate the table and use any PHP script and fill up the table tx_news_domain_model_newswith the same amount of news entries found in tt_news and set the uid to the one of tt_news and set the import_source field to TT_NEWS_IMPORT and the import_id field as well to the uid of the tt_news uid. After that, the import will pick the dummy tx_news_domain_model_news record, found by findOneByImportSourceAndImportId() and will enrich it with the regular data. You will end with news records having the same uid.
In TYPO3 7.6, when I exchange an image in the base language I am not able to add this image in an already existing translation record.
For example: I added image pic1.jpg in English (L=0), on translating to German (L=1) pic1.jpg is available for activation. Later I remove pic1.jpg and add pic2.jpg, probably clipping or otherwise modify the relation so I have data that I want to preserve.
I'm able to delete the German translation record and add a new translation in both list view and page->languages:"Add Translation" with new image(s) and all its modifications preserved, but that is a work-around loosing all translated fields in the process.
If my memory doesn't fail me, there was a dimmed FAL record appearing in the translation media tab once it was added in the base language back in former versions of TYPO3 (6.1).
Bug? Or am I missing something?
It's a TYPO3 v7.6 core bug which exists since 2014 but it was never fixed. See bug report: https://forge.typo3.org/issues/57272
There are multiple ways to solve this issue. I had this problem too and for me it only worked with the first solution.
1. Create a ViewHelper
It's a solution from Kai Tallafus who shared his ViewHelper in the comments of the bug report 57272 (see link to bug report above).
ViewHelper: https://forge.typo3.org/attachments/download/32333/FalTranslationFixViewHelper.php
Usage of the ViewHelper in Fluid Template:
<util:falTranslationFix record="{record}" tableName="tx_myext_domain_model_foo" relationFieldName="files" as="files">
<f:if condition="{files -> f:count()} > 0">
<f:for each="{files}" as="file">
{file.properties.title}
</f:for>
</f:if>
</util:falTranslationFix>
2. Install an Extension
I found two extensions who probably will fix the bug. I recommend the first one but it doesn't work for me but maybe it will for you.
repair_translation
faltranslation (only available on bitbucket -> bitbucket.org/t3easy_de/faltranslation/src)
3. Enable sys_language_uid field for the FAL Media
There is a workaround for the translation of the FAL Media in which you enable the sys_language_uid field. When enabled the enduser can select the language for the media element. This also not worked for me but I know from a friend that in one of his project it worked. Manual (in german): www.npostnik.de/typo3/workaround-fuer-uebersetztungen-der-datensaetze-mit-fal-media/
4. Update to TYPO3 v8 LTS
When you're working on a project which could be updated to the new Version, you should consider to make an update. The Bug is fixed in the TYPO3 v8 LTS.
The viewhelper won't work for the field media in tablep-pair pages/page_labnguage_overlay. (TYPO3 8.7)
You have to seperate your translateted parts in the fluid-template. The where-clause in the query should check for 'pid' instead of 'uid'. And you have to check for a relavant entry in the media-field of the $rawRecord.