#337 Moin 1.6 upgrade

Created 8 years ago by mmcgrath

Moin 1.6 is out, we'll need to get a version built for RHEL5 and see how it goes.

I didnt saw this ticket, sorry about it. Should i duplicate this one, or the other that i created to track the upgrade

Just a few things I noticed on a quick glance.

  • I logged in successfully, but all pages are immutable. Including my own wiki page. My name was still in the EditGroup page.

  • The Recent Changes link shows "This page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists."

  • In the footer where it shows who last edited the page, it shows 'localhost'. Ah, just checked, looks like that is because of the conversion to 1.6 markup. So probably a non-issue, but might be worthy of warning folks about prior to the live upgrade.

Ooops, didn't mean to change the ticker priority, corrThis page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists.

Replying to [comment:4 jeffreyt]:

Ooops, didn't mean to change the ticker priority, corrThis page does not exist yet. You can create a new empty page, or use one of the page templates. Before creating the page, please check if a similar page already exists.

Ahh yes. So the recent changes page bit the dust during the upgrade (it was a rough process) I suspect I could get that back in and going.

The immutable pages thing concerns me, I got right in but I do have better permissions.

there are { { {

pages that, for whatever reason, have changed. Basically the { { { needs to have no characters directly after it or it doesn't work right (worked in 1.5.8, doesn't in 1.6.1). I'd think a sed would fix this.

Replying to [comment:6 mmcgrath]:

there are { { {

pages that, for whatever reason, have changed. Basically the { { { needs to have no characters directly after it or it doesn't work right (worked in 1.5.8, doesn't in 1.6.1). I'd think a sed would fix this.

I saw one instance where html block (computer output) hasn't been parsed right because it includes <> enclosed email address and treats '<' as an invalid opening tag. Changing it to { { {<sometext>} } } works in both versions. So I guess some {{{#!html snippets will have to be looked at in a wiki.

--vladimir

Replying to [comment:7 vnk]:

Replying to [comment:6 mmcgrath]:

there are { { {

pages that, for whatever reason, have changed. Basically the { { { needs to have no characters directly after it or it doesn't work right (worked in 1.5.8, doesn't in 1.6.1). I'd think a sed would fix this.

I saw one instance where html block (computer output) hasn't been parsed right because it includes <> enclosed email address and treats '<' as an invalid opening tag. Changing it to { { {<sometext>} } } works in both versions. So I guess some {{{#!html snippets will have to be looked at in a wiki.

--vladimir

Please ignore, I just saw what you mean.

We just addressed some ACLs problems, and from the pages i do know, everything seems WAI. Please let us know if you find any ACL problems, lack of ACLs, inheritance problems, etc.

The footer shows correctly the last edited after i edited something :) Also we need to fix the 3day mapping on RecentChanges. If you go directly to RecentChanges page it works correctly, but not the right side menu RecentChanges link.

Small note:

macros markup is in 1.6 <<macro>> and [[Name]] is used for linking

The block usage {{{ }}} is not displaying correctly if there is a space before the {{{. The wiki is enforcing the proper usage for {{{ }}} blocks, which is to put the brackets on a line by themselves. Unfortunately, there are a mix of styles in the old content because the older code did not enforce the {{{ }}} block usage.

It's possible we can work up a regexp that can find the following and fix them, without messing with the inline uses.

{{{foo }}}

{{{foo }}}

{{{foo }}}

Note the commonalities:

  • The opening {{{ bracket is either at the start of a line or has one or more spaces before it, no other characters
  • If such a {{{ is detected, it should have no characters after it save a line break
  • If there is another character, a line break should be inserted just after the {{{
  • Reverse is true for }}} as being on a line alone without any leading or trailing spaces

A well constructed regular expression could find all these instances and fix them. I suppose.

This officially isn't happenening. We're going to Mediawiki!

Login to comment on this ticket.