We are doing a Confluence upgrade from 3.0.2. to 4.3.6 and have a question regarding the relationship between syntax conversion and plug-in installation.
From what we have found the conversion takes place between 3.5 and 4.x but, to be able to do the conversion, confluence must also have access to the 4.x plugins.
If so; what is the sequence of steps to do when going from 3.5 to 4.3.6?
When does the syntax conversion take place?
When do we have the opportunity to install the plugins?
We would be grateful for a any information regarding this.
Thank you beforehand.
As it happend (in the test environment) is that all upgrades were done thru 4.3.6 when I was notified.
Since I had a pretty good clue to which plugins were missing (some of theese were mentioned in the log) I installed new versions of these and after som editing of select pages I found that it seemed to be OK.
As I looked at the logs I could not find the "Wiki to XHTML Exception Report" but I found the "in progress" reports (Migration:thread-4- Migrated 1000 of 28783 pages, this batch migrated 500/500 without error). Looking at these I can conclude that 31 out of 28783 pages had some errors. I don t know how to find them however since I was hoping to have seen them in the Exception report (summary).
By chance however I found a page with the following error message (should have been an image but I don't know how to attach):
I want to try to first unpack what you are saying to me so I can answer you more completely.
Moving from Confluence 3.5 to 4.0 does see a content migration from wiki markup to xhtml storage. This task kicks off an tries to convert as many pages as possible. Pages that contain incompatible markup like legacy user macros or incompatible plugins are wrapped in an "unmigrated-wiki-markup" tag. This is so that these pages can be later reconverted using a couple of tasks that I will include below.
You do not have to have the latest versions of your plugins installed before you perform your migration from 3.5 to 4.x. I would recommend that you upgrade your plugins to the most recent version that is compatible with 3.5 before performing the upgrade. There are a number of plugins that have versions that are only compatible with 4.x and up so it would be impossible to have them installed on 3.5. Once your plugins and instance upgraded you can run both of the content migration tasks outlined in the document above. That will look for those "unmigrated-wiki-markup" tags and reattempt the migration procedure.
Please let us know if you have any further questions
Just out of interest: Why do you need to install the plugins on the 3.5 level. It was my impression that they would only come into use when e.g. viewing a page (which will not be done in the 3.5 version). I would obviously understand the need to have them available when doing the conversion because the invocation syntax would be needed when doing the conversiion.
In the referenced document it does not really say that the plugins should be available in the 3.5 installation but, if that is so, would it be possible to do the
Then what? Will the old (version uncompatible) plugins remain and have to be replace by the new (4.3.x versions)? Then we do a manual re-run of failing pages.
I would be more happy with the scenario that we don't need to bother with plugins in 3.5 but rather do like:
Would that be unpossible?
I suggested the plugin upgrade for the 3.5 stopover so you could user 3.5 and see what functionality was broken or missing. There is no issue if you want to upgrade through 3.5 to 4.3.6. You can just install your plugins at your final upgrade step.
I think our users have the best success when they have a stop over at an intermediary and expose a test instance to a small population of testers. Problems at this stage can be rooted out and not obfuscated by the subsequent upgrade attempts. From the support side it is easier to help diagnose problems you have encountered if you are only changing one major variable at a time.
Wither path is more than open for you. It comes down to personal preference at some point.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG