I have an old Typo3 installation which was upgraded many times before. At the moment it's at version 4.5.
Because I had several severe problems upgrading, I am thinking of setting up a clean Typo3 6.2 LTS setup and migrate the pages, instead of upgrading again.
My question is now, what is the best way to transfer the pages as well as the calendar, news and TemplaVoila from version 4.5 to version 6.2? I have more than 1000 pages.
Thanks
You can upgrade a TYPO3 4.5 website to TYPO3 6.2 as soon as all extensions used in TYPO3 4.5 are compatible with TYPO3 6.2. I think this will still take some weeks until the major extensions are provided with an update for TYPO3 6.2
If you dont want to wait, you can try to use the patches named in the smooth migration wiki
At least, there is a patch for tt_news.
In case of TemplaVoila you can try using this version which could be compatible with TYPO3 6.2
In case you do not know: The TemplaVoila extension will not be maintained any more (more details about that here), so it is not very future safe to use it on a TYPO3 6.2 website.
If you want to use FluidTemplate and Grid Elements instead of TemplaVoila, you can try to use my extension tv2fluidge to migrate your TYPO3 4.5 website to FluidTemplate and Grid Elements. This is of course a lot of work (creating new page templates and Grid Elementes), but you can keep your page structure and content and do not have to wait for an TYPO3 6.2 version of TemplaVoila.
I don't know if it will be work for 100% but you can copy all tables with prefix tt_news, calendar etc. and pastle them to new db. If you have some images and other files you will find it in uploads/tx_ttnews/ - you should copy it too. I don't use TemplaVoila so I don't know how to move that to another site. And you have to remember about pid and id of pages/ce - they have to be the same
Related
After upgrading our TYPO3 website from 8.7 to 9.x to 10.4, a custom-made extension has become twice as slow. More specifically, the reading and writing of the database queries have become slower.
The extension uses (long and complex) TYPO3 Extbase repository queries and are full compliance with TYPO3 code conventions.
How come the exact same, unaltered queries run twice as long in TYPO3 v10 compared to v8.7? It is important to mention that no changes were needed to the repository/query code (other than the TCA code and other configuration files) to successfully run the extension in TYPO3 v10. The only issue is the reduced database reading/writing speed.
Also, the v10 TYPO3 instance runs on the exact same server and the same environment. The only difference is the PHP version (7.1 vs 7.3).
Any insights into this would be greatly appreciated.
One thing that comes to my mind is SQL indices, which TYPO3 v9 creates automatically for typical fields (pid,deleted) of a DB table, but maybe you had some additional indices before? can you recheck this?
In addition, if it is related to languages and overlays this might be an issue as well. Is this only in Frontend environments or also observed in TYPO3 Backend?
Since the TYPO3 forum seems a bit dead, I thought I'll try my luck here. If anyone knows a different place to ask, be sure to name it and I'll delete this post.
I recently acquired a project with TYPO3 webistes that I need to migrate from 6.2 to 7.6. I will probably need to rewrite a lot of customized extensions and I want to start with the login system. The main site uses shibboleth_auth (which is discontinued) that has been partially rewritten to fetch login data from different endpoint.
Now, what is the current alternative for this extension? And how do I "extend" an extension so that It can still be upgraded, but also uses my methods? ( in this case, the custom endpoints for login verifications ).
I know that the University of Austria and Munich are currently working on a shibboleth authentication plugin that will work with 7.6. They asked a couple of weeks ago about feature requests and funding.
Our agency is maintaining a friendly fork of EXT:shibboleth_auth, it can be found at GitHub and Packagist. It is currently compatible with TYPO3 8.7 CMS and a version for TYPO3 10.4 LTS will follow shortly.
I am maintaining a TYPO3 installation using 7.6.11 and there are the extensions flux and fluidcontent installed. How can I quickly check if those are really used?
use the extension additional_reports to get an overview about all used ContentElements.
also have a look in the list of available ContenteElement types. are there more than the usual?
I have just migrated six websites from TYPO3 4.x to TYPO3 6.2
In all of these, I use the htmlArea RTE, but only in one of these, the RTE does not work.
It's installed fine, but when I open a content element, the RTE keeps trying to load and simply does not open.
I know that there was a bug related to this (TYPO3 can't enable htmlArea RTE) but this is NOT the solution for my problem.
Because all my other TYPO3 installations work fine, I am really clueless and would appreciate any help.
SOLVED! Just in case anyone else is having a similar problem:
In my PageTSConfig, I had this entry:
RTE.default.buttons.blockstyle.tags.table.allowedClasses.classesTD
But it needs to be this:
RTE.default.buttons.blockstyle.tags.table.allowedClasses
Now everything works perfectly
I successfully upgraded TYPO3 version 4.7.12 to 6.1.7, and also followed all steps for upgrading.
http://wiki.typo3.org/Upgrade
All functionality works fine in both side frontend and backend.
But the backend content view looks ugly, see attachment image.
Templating method: TemplaVoila
Please help me where I missed something.
You should be aware, that TemplaVoila is not actively developed any more. It also is not 6.x compatible and will most likely not be fixed to become compatible.
From the looks of things I'd say either TemplaVoila or any other non compatible extension break your backend view. I'd suggest you disable all extensions that are not explicit 6.x compatible and try to enable your way back until you know which extension causes this, and TV is a good candidate for this.
As a possible replacement have a look at fluidcontent or write your own content elements via a simple extension.