Category: Wiki (page view, edit, history, rename, etc)

There are several places in Tiki code where target="_blank" is used.


"Much to the chagrin of Web designers everywhere, the HTML 4.0 Strict and XHTML 1.0 Strict recommendations of the W3C no longer include the target attribute of the <a> tag. The Transitional versions of the specifications still include it, but by definition, these specs are on the way out.

Whatever your personal feelings on the practice, the most common application for this attribute -- opening a link in a new browser window with target="_blank" -- is still useful on today's Internet. So if the standards say we shouldn't use it, how should we go about creating new-window links, while following the latest Web standards?"
http://www.sitepoint.com/article/standards-compliant-world

Recently, this was addressed:
[item6423|Rollback should indicate who did the rollback]

Let's go one step further and let the rollbacker indicate a comment

If you rollback a page to a previous version, the links to that page are show with a question make instead of a proper link.

We now have an RSS feed for last changes to all wiki pages [tiki-wiki_rss.php]

It is possible to ((watch)) a wiki page and receive emails of changes. Next step is to have an RSS feed per wiki page.


Related: [tiki-view_tracker_item.php?itemId=884|RSS feed per category]

RSS feed for the wiki now links to the last 10 pages changed. And no text is provided in the RSS feed. So, we click the link and we are provided with little clue of what changed. We then need to click history. Why these extra steps?

It would be much more logical to provide the diff text in the RSS feed. (instead of nothing)

Ex.:
- John has a lamb
+ Mary has a lamb

Also, the URL should link to a nice diff version instead of the page.

Ex.:
tiki-pagehistory.php?page=HomePage&compare=1&oldver=19&newver=20&diff_style=minsidediff

Therefore, we can see basic changes just with RSS and if we click we get the nice colored minsidediff

I have the latest files for RSS, and the RSS feed is malformed. I fails to load properly in Firefox, and loads in other readers (e.g. Yahoo) but without formatting.

RSS Validator says one error is that there is an extra line before the first <xml... line, which is causing it to be parsed as HTML and not as XML for RSS. See here for an example; http://www.casesofinterest.com/tiki/tiki-wiki_rss.1.43.2.1.php?ver=2


I have spent a lot of time tracing the calls and I can't figure out why it works fine for blogs, but not for wikis as the code is similar. I hope someone who knows more than I can fix this.

The RSS feeds seem to have no permission checking. The feeds should only include information that is available to Anonymous.

The Sandbox feature is supposed to let a wiki page named "Sandbox" be available for testing syntax, trying out plugins, and so on by looking at the page preview, without saving the content, so every time the page opens, it has no content. Also there are no page versions, no page history, etc.

But in a Tiki 23 site and in the current Tiki master, after turning on the Sandbox page feature, I can save changes and see the page history and so on just like any other wiki page.

https://tiki.org/SandBox show the following : "Since SandBox has some annoying bugs I had to lock it."

This page is highly ranked when searching "Tiki Wiki Sandbox".

{syntax type="tiki" editor="plain"}
Couldn't find another bug report for this, although this is an extremely noticeable bug so there should be an existing report.

The wiki sandbox for non-admin users is useless because it doesn't show save/preview buttons.

{syntax type="tiki" editor="plain"}
On master, any page I save have the value of 1 added for the Properties: Description and Title.
All my pages have now the title of "1".

It is coming back each time I edit a page, I have to fix manually for each editing.

It is possible more options are affected, I could see only these for the options/features I enabled.

When you search for a word, if the word found is in a multiple pages context, like on the page "Formatting Standards" on the site doc.tw.o the result will show you
the first page. But the word you were looking for might be on page six, so you need to go from page to page with the little arrows in order to find the right page. This could be a problem if you have more then 8 pages like in the Formatting Standards. It should find the appropriate page directly.

When the Multilingual and Best Language features are enabled, the Tiki wiki page search results (both searchindex.php andsearchresults.php) do not append the "&bl" to the URL.

If you have your wiki pages set to display top and bottom buttons and edit icons, then some of the bottom buttons and icons don't work.

Specifically, the bottom Preview button doesn't work while editing in the normal editor, and the bottom icon for View Edit Icons doesn't work.

I ''think'' this is a week-old regression, but it might actually be a long-standing bug.

Long overdue feature in TikiWiki:

http://en.wikipedia.org/wiki/Help:Section#Section_editing

[http://sourceforge.net/mailarchive/message.php?msg_name=435AF64C.1050106%40marclaporte.com|2005-10 discussion on the developer's mailing list.]

If "edit by section"=Y as a wiki feature, all H2 should create a bookmark and a section that can be edited individually. As an option, all heading levels could become sections.

Section edit should be optional and there should be a syntax to override (either way)

More explanation from our friends at WikiMatrix:
http://www.wikimatrix.org/wiki/feature:section_editing

{syntax type="tiki" editor="plain"}
{img src="show_image.php?id=94" }

New section edit feature is very useful. Three minor adjustments:

A- There is no way to edit the section preceding the first !,!!,!!! etc
This would be nice as well.

---

B- When getting to the section via an anchor, the edit by section icon is too high. To see what I mean:

1- login to doc.tikiwiki.org

2- go to
http://doc.tikiwiki.org/Editorial+Board+Meeting+2008+05

3- Then click on an anchor like:
http://doc.tikiwiki.org/tiki-index.php?page=Editorial+Board+Meeting+2008+05#2_3_Proposed_changes_to_doc_tw_o_site

Notice how the edit button is not accessible directly? I need to scroll up a bit (not ideal)

---

C- After editing a section, I should be sent back to the anchor of the section I just edited

So I can see what I just edited.

- Go to Wiki -> Send Pages
(You'll have to activate "XMLRPC" and "Communication Send/Receive Object" in Admin-> Features for that).

- Enter the remote host information
- select a wiki-page and click "add page"
- see that the remote host information is gone

This would be very useful as we move documentation from tikiwiki.org to doc.tikiwiki.org, for example.

For data interchange with other systems too.

There needs to be a way to set a default language in the administrative settings so that you do not have to select a language in the page editor unless it deviates from the default. It's a PITA to have to manually set the language with every page you create.

It would be nice if the default could be set on a per-user basis from MyTiki settings, since users tend to do all of their work in one human language.

At https://doc.tiki.org/VideoTutorial-2737-Basic%20Tiki%20Customisation
The autotoc is in the way and it have been turned off (set to on by default on the website).

It is not applied, on some screen it is breaking the page layout.

{img fileId="1293" thumb="box"}
{img fileId="1294" thumb="box"}

There is a tab "settings", when editing a wiki page with standard editor, where you can set, whether a pagetitle is shown or not.
This tab is not visible, when using the WYSIWYG editor plugin.

It should always be visible as an option unless which editor is used... ;)

{THUMB(id=23, url="tiki-browse_image.php?imageId=23")}Share page bug on BRANCH-1-10{THUMB}

{THUMB(id=24, url="tiki-browse_image.php?imageId=24")}{THUMB}

I can no longer reproduce this behavior in 1.10. Please retest. Dave Thacker

Some versions of the Tikiwiki documentation suggest that a watch does not report a change to a web page that has been designated as a "minor" change. That does not appear to be the case for Tikiwiki 1.9.2.

If you ask me, the ability for a wiki user to make a Minor edit without bothering the "Watcher" crowd is a great idea and makes for a better community wiki dynamic.

Mouse over summaries here is OK:
http://dev.tikiwiki.org/tiki-view_tracker.php?trackerId=5

But not here:
http://dev.tikiwiki.org/Rating

The mouse over functionality has not yet been coded in the trackerlist wiki plugin.