I have to refactor a few very old TYPO3 extensions. they are compatible with ^4 but the company I'm working for now needs them for ^8 (the development for this extensions stopped for whatever reason).
I was wondering what is the best approach for me to get this task done -
are there some major resources I could use to get into that topic?
or a general changelog for TYPO3 extensions based on the version up from 4-9?
Any information is much appreciated.
Trying best to answer this, it's up to you how you maintain your site. Off course you need to check the complexity of the extension you build.
Check a few parameters below:
1. Complexity of the extension
Off course you have a big challenge to maintain code (Probably PI-Base extension). Your code should work with TYPO3 8.x as well as PHP 7.0.
2. Code Scalability
A simple thing, your code must be clean so understand better.
Now, you have two way to maintain your extension which is:
Re-build
Use existing extension (Migrate & make this compatible)
Re-build Extension
If you don't have complex application in your web site, you can follow #Aristeidis Karavas and rebuild the completely new extension (Extbase approach off course).
I'll recommend, re-develop for better quality product and to get optimized speed! What do you say?
Migrate Extension
For TER extension (which is available at extensions.typo3.org) might provide migration extension, such as EXT:tt_news to EXT:tx_news. For the custom extension, you can write your own SQL script which migrates your extension data to the new extension.
Compatibility Extension:
You can use compatibility extension available at TER which provide some easy solution to map TYPO3 classes.
Useful Links:
Here is some useful link could bring you to the bright side and will make your stuff easier:
EXT:compatibility6
EXT:compatibility7
Blog: Upgrade Guide
Bernd has given deprecation lists Links here
Hope this will help you!
Related
Yes, I'm beginner. and I used Webstorm but now using Vscode.
I know to say 'extension' in Vscode.
But sometimes to say 'plugin' in Vscode.(ex. Do you know Vscode's Prettier plugin?)
Can others understand this?
I understand it like this Python's pip and Node's npm to understand.
Just different name.
Is that what I understand right?
There is very thin border line between the two.
Extension and plugins often confused people. And Mostly people believe both are same.
The main difference between the two is that plug-in provides extra functionality which does not modify the core functionality.
While extension is made for modifying core functionality, may be provided due to version change or improvement.
Securing plugins is more complex than extension.
Extension are individual identity so one extension needs one set of privileges, whereas plugins are more complicated and needs to identify privileges for each application runs plugins rather than a whole plugin.
Extension is specific to particular application. It extends functionality of a particular application or software.
While plug-in can be made generalized which may runs independently in coordination with particular application or software.
Can we write the Feature files and step definitions in Swift Automation framework using XCUITEST Framework ?Is yes , Any jar files or plugins we need to install ?
I am unable to find much support in this
While this is not an appropriate question for StackOverflow, I will oblige you an answer with Cucumberish. I have used it in the past, it works, but I generally steer clear of third party frameworks as they add a layer of complexity and leave you in the lurch if they lose support.
I have worked a bit with CucumberSwift and got it to work fine, reading German-language Feature files and letting me define steps in Swift using all the functionality that XCUITest provides.
However, we have not adopted this in the end but are writing Feature files in Gherkin and then write ordinary XCTestCases that we link to the Feature files by mentioning Scenario names in comments. We develop the same functionality for three platforms and it was difficult to see how BDD tooling would work across all three or how we could make it work given the resources we have. Like Mike Collins we also felt that running without the complexity of additional frameworks was an added benefit.
Having said this, CucumberSwift seems promising, perhaps check out this discussion about documentation and add to it?
I am totally new to creating extensions in VS Code, and all the official examples of extensions are written in Typescript/Javascript, which I have no experience with. Is it possible to create VS Code extensions in other languages, such as Python or C++?
If so, could anyone point me to any resources to get me started?
It is possible by creating a C++ module for Node.js, which can then be loaded like any other node module. Of course, some glue code written in JS or TS is necessary to register the extension and translate calls to/from vscode.
I've gone this way in my ANTLR4 extension, but gave up eventually, because of the troubles I had due to incompatible dependencies (you have to make sure the extension uses the exact same V8 version, which was used to build the underlying Node.js used by vscode, on all supported platforms).
This situation might have change, I don't know, but with that in the background I don't recommend it.
If you want to add support for a new language in vscode you can also write a separate language server, as is mentioned in the linked SO answer. For other type of work, I'm afraid, you have no alternative to use.
No, as #rioV8 said, since VSCode is an electron app and runs on Javascript.
I want to set up an open data website with the typo3 cms. For open data I do not know how I can manage with typo3. After a tour on google I found the CKAN API.
My questions: is it possible to integrate them? If not, are there any other solutions with Typo3?
Thank you for your possible answers
I don't know an implementation of the CKAN API and a quick search in the TER (TYPO3 extension repository) never showed any results.
Nevertheless there exists an extension filemetadata which is doing probably partially the requested features. Here the links:
filemetadata on Packagist.org
filemetadata on github.com
For the case that the features are not enough or the structure is not like desired a new extension could be programmed where some basics could be taken from the extension above, at least it could serve as example how some things are done.
It has to be mentioned that some extensions are never registered in TER but only available on github perhaps. So before programming something a deeper search might be advisable.
In former times another extension was common for Digital Asset Management, the extension-key and Name was dam. That extension is not compatible with current TYPO3 versions and taking it as example is probably no good idea as much outdated code had to be adjusted.
Nevertheless the advised example above is not the only possibility, the search for file metadata still shows other extensions that are compatible to current TYPO3 versions 7 and 8 which could be taken as examples. Perhaps changed search-words still let you discover more useful extensions.
The mentioned extension in the top is supported by the TYPO3 core team, the others are provided by other developers. I never compared the extensions and you had to see code or/and features by yourself. So I never endorse any of these solutions as usage is rarely requested.
If you search for the most recent code it's always good to search on github first for the development branch or a release that is not (yet) published in TER. Another source of information is forge.typo3.org, there many extensions are listed too, some even with repository on git.typo3.org, perhaps it's worth it to mention that this source is abandoned by some developers in favor of github.
Technically it would be even possible to extend any found extension and add more features or change something just by another extension - without touching the original extension. But before thinking too far you should first have a look if any found extension could satisfy your needs already.
For further questions that might be already related to coding you should open new question(s) with more detailed explanation and code-examples, even if that doesn't work yet.
EDIT 15th Oct 2018:
Just got a hint about a helpful extension for those purposes: extractor. Additional fields shall go to sys_file_metadata and be a part of the extraction service.
As I never did verified it by myself I can't give further hints in the moment.
I currently got the task to upgrade a custom made CRM extension named "kbs". It was developed on TYPO3 4.7 and using old namespaces in its classes like "Tx_Kbs_Service_TestService" etc.
I want to upgrade this whole extension to be able to work properly with our current backend version of 6.2. More specifically i want to be able to use the extension builder to make changes to this extension which i am currently not able to do on the 6.2 TYPO3 backend. It is not even an option to select the "kbs" extension in the extension builder.
Of course i reasearched the web but I find it very difficult to find information what you have to do in order to addapt a custom extension.
So far I assume that i will have to change all the namespaces in all my classes manually and maybe watch out for decrecated classes. But I do not really know if that is the way to go.
Does anyone have and guidelines, links or tipps for me? I would really appreciate it!
Thanks in advance,
Simon
To the first question:
In extension_builder only extensions are changeable, they had their original configuration made by extension_builder.
Extension builder itself is only an option to use, and there were also other options to kickstart an extension.
Update:
This is true, that extension builder is not an "editor" for extensions but a tool to help kickstarting an extension.
If I would get the task and extension_builder would be available I would not use it to make changes on the code. It is not 100% sure, that manually changes were not made on the code after its last automatically generated version. And if dummy actions were changed and properly excluded from the config they could be also deleted.
I think your best choice to change the things manually.
There are two source to read first:
TYPO3 6.2 Release Notes.
What's new presentation (TYPO3 6.2)
They contains breaking changes and some example.
If you do not change the PHP version, than changing the Namespaces and some deprecated functions. (The sources above could help to get an idea on those)
One tricky part could be to migrate old image logic into the "new" FAL (File Abstraction Layer). If you don't need to deal with images, then it must be an easier thing to go with.
There is also an extension to help with some migration stuff: smoothmigration.
You can find some hints in this presentation also:
jweiland: Smooth Migration TYPO3 4.5 > 6.2 LTS