I'm Looking for a kind of guide how to migrate extensions to work with TYPO3 V10.
I don't find much when I try my luck on google and don't really know where to start.
We are actually using TYPO3 9.5 and I will need to migrate Comsolit's owl_slider which we are heavily using on our website. TER doesn't offer a Version for TYPO3 V10.
Any hints are appreciated.
Since it is not built by you, if an update comes, all of your changes will be overwritten. With that being said, if you decide that you want to update it to TYPO3 10 by yourself then you should first avoid the "*" if you are on composer mode and you have to insert the current version so next time you run composer update, composer won't update the extension. Still, composer will check if the extension is compatible with TYPO3 v10 and if not then it will not run. So you will have to remove it from the composer and manually download it to your ext directory. If you are on non composer mode, just avoid clicking the update button in the extension manager.
For Frontend not much have been changed. The most common error that you can get is the <f:switch/> viewhleper where the defualt case has been changed from default="true" to defaultCase Changes.
Now you will have to deactivate the extension and update your TYPO3 installation to v10.
The first thing you need to do is to change the TYPO3 dependency to 10.99.99 or something greater than your current version (ext_emconf.php). From this point on, is try and error. You have to install the extension and go step by step through the errors that appear if any. Here you can find the changes that have been made. It would be wise to avoid deprecated function since in TYPO3 11 or 12, will be removed.
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog-10.html
You can not know rom the start what can go wrong unless you test it. Even if you know exactly what has been changed, you will still need to try and error.
Best regards
Related
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
I got a problem. I want to upgrade my app during installation process, but I run into problem with versioning. I use version number in format e.g. 5.5.789.0, some new version has version number in format 5.5.12.1. I know that installer only works with first three numbers from version so MajorUpgrade is not suitable for me. New version would not be installed in this case. Is there a way in which I can check versions in some custom action and plan upgrade from there? I cannot change the versioning as app building goes through some automatic post-processes that also works only with first three numbers and it is not possible to change that behavior.
Thanks for suggestions.
EDIT:
I am using WiX#.
It's not obvious to me why you can't use the WiX majorupgrade element. The settings would be AllowDowngrades=yes, maybe AllowSameVersionUpgrades=yes.
Using Schedule=afterInstallValidate is (as the docs say) removes the old product entirely before installing the new upgrade.
Just getting ready to upgrade from 5.1 to 6.3. We have never performed an upgrade before.
About the upgrade path: When installing the updates, do I need to install the hotfixes, or just the major releases? (My gut says only major releases).
I found the documentation here:
http://www.sitefinity.com/documentation/documentationarticles/upgrading-you-sitefinity-5.1-project-to-the-latest-version
Is this documentation enough to make a smooth upgrade?
Yeah, just follow the documentation in the link you posted.
My process is to take full backups of the site files and database then perform the upgrade locally. Do the first step in the upgrade path then run through the site to test, back end and front end, then run the next step in the upgrade, and so on. I suppose if you want to be extra careful you could take additional backups between each upgrade step but that's probably overkill.
When making the web.config changes, there is an option to have Project Manager merge them for you but I end up just using Beyond Compare to compare the _EmptyProject folder in the extracted Project Manger files to my local files and do the web.config changes through a file compare. It cuts down on the differences in files from upgrade to upgrade and shows you whats been changed. The _EmptyProject folder is essentially the vanilla Sitefinty site files for that version.
Once the site is fully upgraded locally, I just publish the site in Visual Studio, copy the files over to the live site and overwrite the live database with a backup of my locally upgraded database.
Hope that helps.
I have upgraded Sitefinity 5.1 to 6.0, on a website which is in production (which included going through a couple of steps for the versions between).
I just followed the guidelines, and it went fine.
Now there are a couple of things you need to be aware of :
Source control
If your Sitefinity solution is on "Source Control", you should create a new duplicate of your solution, and disconnect this one(newly created) from "Source Control" before starting the upgrade. And of course you do the upgrade on the solution which is not in Source Control. Because you will probably have a lot of dll's to integrate, and if you have the project manager, your sitefinity project will run correctly, even though the new dll's aren't properly integrated in your solution and possibly "source control".
Unexpected behaviours of previously working elements
Secondly, I didn't test the frontend and backend during the different steps (Sitefinity versions within upgrade), but I tested everything once my solution had reached the last Sitefinity version. I thought I had checked everything, but it wasn't the case, and some of my custom Widgets didn't work properly on the latest version of Sitefinity. Next time I'll go more in detail on all custom parts, since from a working version of Sitefinity, you can end up with a newer version that breaks some behaviours. If you notice this, you might better wait a bit more for a fix, or the next release which might fix the problems.
Outside access to website during upgrade.
Furthermore, once you need to do the upgrade on the production database/website, the website shouldn't be accessed by people, since the upgrade of database might take some time.
Time needed for upgrading everything
One more thing I would like to add, it takes time to perform upgrade of several versions.
The first time I upgraded (I needed to go through 2 versions), and having to upgrade locally, to a development database, deploy the website on developement environment, then make it again on test. I took about 4 hours before everything was fully working. Make sure you have enough time, because it can be more tricky if you need to stop everything then come back to it.
Whenever you hit 'the check for update' button, IntelliJ checks for IDE update and starts by checking and updating all your active plugins.
The point is that I use a pretty crooked plugin which only works for me in an old version (a release from last year).
To be more specific, I'm talking about 'QA Plug PMD' which is not compatible with my imported sonar rules in its last version.
Actually, QA Plug PMD's last version is based on PMD 5.0.x and I need QA Plug PMD's 2012 version which is based on PMD 4.3.
In summary, when the QA Plug PMD plugin gets updated, my coding rules are all reseted because the plugin is not backwards-compatible.
That being said, I need to know if there's a way I can tell IntelliJ not to care about this specific plugin during its update process and leave it alone :)
Goto File -> Setting -> Appearance& Behaviour>System Setting->
Updates->Uncheck the Automatic uppadte checkbox.
Tada.. Done.
Danke,
Rahul
The best way would probably be to not install it from the plugin repository. Try to install it from disk instead. Download it from the link you provided instead (the zip file will be downloaded):
Then choose to Install plugin from disk... instead:
And then point to the pmd.zip file:
Edit
During the update you will get a question whether you want to update the plugins as well and you can always uncheck that plugin:
Edit2
Make sure that you don't have the Check for updates in channel checked. That might help you out:
So, in college I had a Debian server which used to host a wiki, with mediawiki version 1.9. This server stopped working, and all I have now is its HD. I want to transfer this wiki to a new server, which also runs Debian, but I can't do that with Debian's current stable version of mediawiki, 1.15, because it is not possible to transfer a wiki to another version of mediawii.
So, my idea is to install mediawiki 1.9 on the new server, and then move the wiki. But I am having problems with installing it.
When I go to http://my_hostname/config/index.php, to configure the new wiki, so that I can transfer the other one, I get the following message, and nothing happens:
Checking environment...
Please include all of the lines below when reporting installation problems.
PHP 5.3.3-7+squeeze8 installed"
I really don't have a clue on what is wrong. ANY help would be greatly appreciated!
Like you commented yourself, it would certainly be worth a try to using your existing configuration. The configuration is typically some site preferences and database configuration, so make sure dat your database is setup in the same way as before.
Regarding your configuration problems, maybe php filters away the errors. You can check this by searching for error_reporting in your php.ini.
Just follow the instructions at http://www.mediawiki.org/wiki/Manual:Upgrading. Probably no point in trying to install at MediaWiki 1.9.
You may want to do a clean install of MediaWiki 1.18.1 first just to make sure your system is ready, all dependencies met, etc.