forum,

I just upgraded from 2.0.something to 2.6.0 (also php4 to php5). Everything went smoothly enough, but I'm having a small problem now. If I go to any Wiki page (use the example "Single Sign On"), I can edit the entire page, but not sections (as designated by !'s)

An example:

The page is
ttp://wikiserver/wiki/index.php?page=Single+Sign-On

The "Edit" link at the top goes to:
ttp://wikiserver/wiki/edit.php?page_id=12

I have a subheading called !OpenDS Requirements. When I click the edit next to that section, it goes to:
ttp://wikiserver/wiki/edit.php?content_id=18&section=1

The first "Edit", for the entire page, works as expected. Any of the subheading "Edit"s open to a "Create Wiki Page" version of the page, instead of the "Edit $title" page that should be there.

Thoughts?

Thanks!

Wes

Not sure if I'm guilty, but I added a fix to fill in the title when the link was being used to create a new page. It was annoying me that it had stopped working, but looking back at the code I'm not sure what happens for the section stuff. I'm running html content, so the section edits do not appear, but something that looks wrong to me is the use of content_id in the section edit - while it should not make a difference, things should be consistent, so either we use content_id in both cases, or page_id.

I've tried to check here but can't get sections edit at present, and I'm not even sure the title mode made it to R2.6 anyway ...

As a followup, the content_id (18) is correct. If I replace it with a hybrid, by entering ...page_id=12&section=1 then it does work correctly. Looks like the problem is not correctly loading content based on content_id, even though it's correct.

I'll see if I can sort the links to put the right thing in for page_id but I've just spent the last few days trying to get PHP5.3 on windows in a state where we can actually use it. The official builds have lost some key components, and I'm still working my way through an unofficial build ...

I can confirm the described behaviour of "Section Edit". Are there any updates on the status?

I'm not using tiki wiki format, so there are no section edit headers to play with here :( The only problem is to get these to correctly use page_id rather than content_id. The content_id is processed at a higher level and should not be used for these secondary functions.

Line 666 of format.tikiwiki.php just needs tweaking, but I'm not sure if page_id is actually available in the data hash.

I took a look at the link construction. The wiki site in question belongs to a wiki book.

site urls to reach wiki page, all work:

(the first one shows up when accessing the site via the wikibook structure toc)

1. .../bitweaver/index.php?structure_id=49
2. .../bitweaver/index.php?content_id=58
3. .../bitweaver/index.php?page_id=30

section edit url on mouseover:

this link doesnt work; it shows a new wiki page
.../bitweaver/wiki/edit.php?content_id=58&section=1

correct, self-constructed section edit:

these urls both work:

• .../bitweaver/wiki/edit.php?structure_id=49&section=1
• .../bitweaver/wiki/edit.php?page_id=30&section=1

Any ideas? ;)

As I said 'page_id' should be used with 'section' but I don't have any systems here using tikiwiki syntax to check if 'page_id' is passed in the hash that is creating the links :(

So you would need a prototype using wiki syntax to play with? Or could you give me instructions so I'm able to help you?

Sorry guys; I went on vacation and then we had a Samba server meltdown. Things have finally calmed down a bit so that I can back to this.

After some superficial glancing, in wiki/edit.php on line 25 there is

unset($_REQUESTcontent_id>'content_id');

Of course, this is a bit of "duh" and commenting it out fixes the problem immediately. But it probably isn't the *answer*. However, it works for me for the moment.

It looks like the real changes need to be made in

liberty/plugins/format.tikiwiki.php

at line 666