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.

minor update... this is an encoding issue
It works: http://publictest10.fedoraproject.org/wiki/RecentChanges?max_days=3
Doesn't work: http://publictest10.fedoraproject.org/wiki/RecentChanges%3Fmax_days%3D3

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!