We are migrating a TYPO3 4.7.14 site with news 1.4.0 to TYPO3 7.6.28 with news 6.3.0.
When we started all news are migrated and are ok on the new server.
But in the time after the news migration some news are added to the old site and now they must be migrated to the new server.
How could this be done?
A t3d Export / Import don't work.
The news are containing a lot of content elements, so it would be an incredible amount of work to do it by hand.
I'd advise to make the whole migration-process new, perhaps only with the news-pages, news-plugins (content-elements saved in the table tt_content with the list_type tx_news or resembling) and news-records.
Problem is primary the update to version 6.2 of TYPO3 as the FAL (file abstraction layer) was introduced and all media-files in the news are getting lost if the corresponding update is not done properly.
Keep in mind that you've to care about one setting in file-storage records (usually for the fileadmin-folder): the checkbox that case-sensitive filenames are allowed. Else a mess is predictable and much additional work too.
If you do it like I proposed only for the news-records and related records, you've to export and import also the tables starting with sys_file, but keep in mind that you really import only then in the upper version instead overwriting the whole table, as there might be still other media-files.
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 stumbled upon this website right here, where I can simply enter a URL and get the exact version of the TYPO3 that's beeing used. How do I determine that without having any login data? Does this work for any TYPO3-Version?
There is an FAQ page with details on how the version is detected. Among other mechanisms, the analyzer compares source files unique to each TYPO3 version:
How does t3versions determine the TYPO3 major version?
t3versions checks the TYPO3 frontend output, the TYPO3 backend login (if available) and the existence of files (fingerprinting), which are unique for each TYPO3 major version. In order to determine unique files for each TYPO3 major version, the files of all available TYPO3 versions (8+ GB of data excluding PHP files) have been analyzed of for uniqueness.
Typo3 current version can be find from here Typo3 source file.
typo3/sysext/core/Classes/Information/Typo3Version.php
Like
protected const VERSION = '11.5.16';
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.