Upgrade to 4.3.6

[Alihesam Azari]

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.

[Lars Bjerges · Accepted solution]

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):

Error: The XML content could not be parsed. There is a problem at line 61, column 85. Parser message: Unexpected '<' in attribute value at [row,col {unknown-source}]: [61,85]

If I try to

• Edit the page I am not able to see the source but only the title of the page
• View source I get the same error message (and noting else)
• View storage format I get the wiki markup (no Xhtml)

So: How do I go about fixing this page?

There might be more of this kind, I know at leat one more but in this case the problem is that the old version of the page had xml markup that was not embedded in code-macro and this seems to create some confusion in the conversion. The symptoms are the same regaridng edit and view storage format. Most of the page is rendered however with som error messages like:

<Unable to render embedded object: File (include (xi:fallback?) > <ac:macro ac:name="anchor"><ac:default-parameter>modco1</ac:default-parameter></ac:macro> !1.png) not found.

and:

"Broken macro"

Also: Is there a way to find the pages in error?

Regards Lars

[Daniel Borcherding]

Hello Alihesam,

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.

https://confluence.atlassian.com/display/DOC/Migration+from+Wiki+Markup+to+XHTML-Based+Storage+Format

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

[Lars Bjerges]

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

1. 3.02. to 3.5 upgrade
2. install plugins
3. do 3.5 to 4.3.6 upgrade

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:

1. 3.02. to 3.5 upgrade
2. do 3.5 to 4.3.6 upgrade
3. install final plugins
4. re-run of migration

Would that be unpossible?

Regards Lars

[Daniel Borcherding]

Lars,

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.

[Sean King]

We've experienced an issue while trying to upgrade our confluence instance from 3.5.3 to 4.3.x with the composition plugin. Their website suggest disabling plugins before attempting the 4.3 upgrade. Is this an appropriate action?