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

Permissions on individual wiki pages are great.

But what if you want to change the perms


__Related__
{WISH(id="2151")}{WISH}

For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]

{syntax type="tiki" editor="plain"}
I upgraded a Tiki25 to Tiki26.
When login as admin I had a warning that console command attachments:migrate has not been executed.

On execution I had the following error.


{CODE()}
/public_html$ php console.php attachments:migrate
Processing page mydomain Website Pages, attachment 15 apagename.html...
Undefined variable $galleryId on line 58 of /home/mydomain/public_html/lib/core/Tiki/FileGallery/Manipulator/Validator.php
PDOStatement::execute(): SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'comment' at row 1 on line 114 of /home/mydomain/public_html/lib/core/TikiDb/Pdo.php
A error was encountered while running a command
Data too long for column 'comment' at row 1 on line 17 of /home/mydomain/public_html/lib/core/TikiDb/Exception.php
{CODE}

The minor modifications are not properly stored in DB. tiki_history has 0 everywhere in version_minor. last_modif_pages doesn't behave properly when minor=y (see bug 2257). I'm modifying this module to support category/perspective filters. I'm leave the branch dealing with minor modifications unmodified because I couldn't test anyway. Please deal with this too when fixing this bug or tell me.

{syntax type="tiki" editor="plain"}
On the toolbar we have a "Help" button that displays common syntax to help the user editing a page.

The markdown help is quite limited with basic syntax.
It should be good to add a link to a more global cheat sheet like: https://www.markdownguide.org/cheat-sheet/

My wiki (http://wiki.alphasoftware.com/, on version 4.2) intermittently fails to respond to mouse clicks for module box and menu expand/contract toggles, tab buttons for administration interfaces, the button to toggle between WYSIWYG and Normal editing, and other buttons that invoke JavaScript Ajax actions.

Changing random administrative settings or themes sometimes changes this behavior, but it still seems to come back.

I think it might be a bug, but I might also have some inconsistent settings.

I am willing to upgrade to the trunk build if these are bugs that have already been fixed.

And make sure URLs are not broken. Report issues as needed.

tiki.org has incorrect canonicals:
{CODE()}
<link rel="canonical" href="https://tiki.org/Paypal%2Baccount%2Bpolicies">
{CODE}

Since these are now in the Google search index, a proper redirect is needed

Perm plugin is very useful and works well. It is very similar to the group plugin. It weighs just a few k and I see no advantage of putting in mods.
http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm

Similar to group plugin, we need "if/else" concept:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=994

So we could do things like this in wiki pages:
if tiki_p_edit "please click here to edit" else "please click here to login"

Also, group plugin is still in mods, but already in main code base so it should be cleaned out of mods.

When you use a wiki page as template (pretty tracker, pluginlist+semantic alias, etc) we have several component that refer to the template page name and not the item (title) it is displaying.

Things like Multilike, Forum for discussion, Wiki argument variables { {page} }, etc

They will refer/link to the page itself and not to the item title.

IE: I have a template page named __record tpl__ to display a tracker item contact (title:bernard) and on the page I have set Forum for discussion option to create automatically a topic in the forum to discuss about this contact: bernard.

Normally I would expect the title of the discussion to be bernard but it will be "record tpl" and also there will be only one discussion for ALL my items (as the reference is the wiki page object and not the itemId displayed).

Same goes for { {page} } it will show "record tpl" and not "bernard"

On Tiki24 when you use an RTL language the top wiki action menu items are aligned left instead of right.

To fix the issue, the existing classes should be replaced with bootstrap classes (start, end, reverse, etc) and not hardcoded alignment.

{img fileId="1764" thumb="box"}

When there are multiple headers of the same text, for example:

!!!!Windows Media Player

stuff about WMP

!!!!!Platform availability

WMP is available in these platforms....

!!!!Adobe Reader

stuff about WMP

!!!!!Platform availability

Adobe Reader is available in these platforms....

The links by maketoc all point to the first instance of Platform availability. This is not correct.

{maketoc}

I have another problem on TikiWiki 2.0RC2:

I have two similar TikiWiki-installations. One just for testing on my Linux-Server and the second on a WinNT-Server. The Windows-Server is the one we want to/have to use for our Wiki :-(

On my Linux-Server works everything without problems.

On the Win-Server don’t work "approve+staging".

If I wont approve changes it shows me this error:

An error occured in a database query!

Context:
File tiki-approve_staging_page.php
Url tiki-approve_staging_page.php?page=Baustelle_Test
Query:
update `tiki_pages` set `description`=? `data`=? `comment`=? `lastModif`=? `version`=? `user`=? `ip`=? `page_size`=? `is_html`=? `wysiwyg`=? `wiki_authors_style`=? `flag`=? `lockedby`=? where `pageName`=?
Values:
0
1 <p>Test</p>
2 [approved by ottonormal]
3 1217330865
4 6
5 ottonormal
6 10.40.153.101
7 225
8 1
9
10 NULL
11
12
13 Test
Message:

Built query was probably:
update `tiki_pages` set `description`='' `data`='<p>Test</p>' `comment`=' [approved by ottonormal]' `lastModif`='1217330865' `version`='6' `user`='ottonormal' `ip`='10.40.153.101' `page_size`='225' `is_html`='1' `wysiwyg`='' `wiki_authors_style`=NULL `flag`='' `lockedby`='' where `pageName`='Test'

When you have the feature "default namespace", and also the feature "Force all non-namespace page links to the same namespace", when you click a wiki-link that points to a non-existant page, the create page will have a duplicated namespace.

Show instance: http://fvtorres-11800-5958.show.tikiwiki.org
User: admin
Pass: 12345

~~#F00:__EDIT: Could not Reproduce in Show! I try to fix with an upgrade. Reducing the importance of this bug report for now.__~~

__Setup:__

* Wiki Structure: on
* Namespaces: on
** seperator: __~__
** tested also with: __:__
* Hide namespace indicator in structure path: ticked (on)
* Hide namespace indicator in page title: ticked (on)
* Force all non-namespace page links to the same namespace: both settings (on/off)

* Create a wiki page with a namespace name example:
+ __example~startstructure__
* Make a Structure from it
* Create a new page __mywikipage__ into the structure
+ page gets correctly named __example~mywikipage__

__Problem:__

When in default settings the ''__Wiki URL scheme__'' is ''__URL encode (Tiki classic)__'' in /tiki-admin.php?page=wiki.
Then the Namespace rewrite does not work and the links / urls are __example+startstructure__ instead of __example~startstructure__, why Tiki does not find the page and either gives an error message or a create page notice or a redirect to the HomePage, depending on further configurations.

__Workaround:__

When the ''__Wiki URL scheme__'' is set to ''__Replace Spaces with dashes__'' in /tiki-admin.php?page=wiki, the links / urls are still wrongly rewritten , but with dash instead of plus: __example-startstructure__ and they do correctly redirect to __example~startstructure__ .

__Additional remarks:__

I think, that the rewrite of the structures feature (wiki structure breadcrumb menu AND plugin toc) from the seperator to the dash (or otherwise the plus) is still wrong.
When I create a page __example-mywikipage__, then I can access the original page with following URLs / Links:
* __example~mywikipage?structure=example~startstructure__
* __example~mywikipage__
* __example-mywikipage?structure=example~startstructure__
* __example-mywikipage-2__

Where __example-mywikipage-2__ is somehow defined as alternative URL from Tiki (18.x) without creating that page at all.
Only __example-mywikipage__ directs to the new page!
__example-mywikipage?structure=example~startstructure__ directs to the old page!

The wiki structure feature uses __example-mywikipage?structure=example~startstructure__ as URL for __example~mywikipage__ respectively instead of __example~mywikipage?structure=example~startstructure__

I'll try to reproduce with a show instance.

It seems that the print and multi-print options are global. I would like to better control which wiki pages can be printed. It would be nice to have a tiki_p_print permission that could be appplied to pages and/or categories and/or structures.

If tiki_p_print = y, then the PRINT button will appear on the wiki page (if the print and/or multiprint options are enabled). Additionally, the page would appear in the list of available pages when using the multiprint option.

The __last_modif_pages__ module has a __minor__ parameter which is supposed to be able to permit/omit wiki pages that were last saved with the __Minor Edit__ option from appearing in the list of last changes.
*minor=y (default) -- Show Minor Edit pages in the list
*minor=n -- Do ''not'' show Minor Edit pages

However, this option does not appear to work (in 2.x).

There is nothing in the wiki page history or action log that identifies a wiki page as having been saved as a __Minor Edit__.

To reproduce:


Make a super long wiki page using:

((my super duper long extra long wiki page name the never ends because it can be difficult to find the right words sometimes and some people may be tempted to just throw in a very large number of keywords in a wiki page name and hope that it will help with search engine indexing))

The wiki page offers a question mark to create the new page but TikiWiki is unable to create a page that size so it truncates to 160 characters: ((my super duper long extra long wiki page name the never ends because it can be difficult to find the right words sometimes and some people may be tempted to jus))


A nicer error message would be nice

Want generate an unique page name from an auto incremented ID. {$f_#} does not work in pretty tracker example nor {$itemId}. I need a single Wikipage for each item generated from a tracker form.

Move all admin settings which affect all text areas to this new panel.

ex.:
Tables syntax:

In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}

In 1.10, the page position is shown on the structure nav for page. It works perfectly for new pages, because of the fix applied in http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=889

However, structure pages created in 1.9 may have pos in db that remains non-contiguous. It will be better to have a way to clean this up.

In IE7, the wiki edit help appears at the page bottom as before, always on. In Opera 9.6, the wiki edit page only displays down to the Quicktags. (I didn't check with IE6 yet.) This is in a trunk installl, Dec. 4, 2008.

This was OK in Tiki 12

Tiki13:: http://tiki.org/tiki-pagehistory.php?page=Pre-Dogfood%20Server&oldver=63&newver=64

Tiki14:: http://next.tiki.org/tiki-pagehistory.php?page=Pre-Dogfood%20Server&oldver=63&newver=64

{img fileId="825"}


Maybe related to this commit?
http://sourceforge.net/p/tikiwiki/code/49450

when I visit nextdev.t.o in mobile mode (using chrome on android), the wiki pages show up in non-mobile mode (the string "Loading..." shows up in clear text at the top of the screen).

When I move from wiki pages to tracker items, then mobile mode works as expected.

---

Fixed, thanks Jonny. {sign user="xavi" datetime="2013-11-17T08:43:01+00:00"}

A user typo whilst creating a structure can create a new page which then isn't (easily) accessed.

Whilst creating a new structure and adding pages with aliases using the "Tree" feature, if hyphen space greater-than rather than simply hyphen greater-than is entered the new page is created without an alias but with a longer that expected page name.

For example
Test_01 -> Page1 creates new page called Test_01 and alias Page1 as expected.
But
Test_02 - > Page2 creates a new page called "Test_02 - > Page2" with no alias.

Accessing this page and removing it is challenging :-))

--(Can't currently create a show instance for you, no database connection available, but I can reproduce this on the demo 18x/system)--

Using the Structures "next page" button from page Test_01 causes a wiki error "Page not found" for "Test_02 - Page2" (sic without greater-than sign).

Likewise wikilink from toc generated on pages within the structure also results in "Page not found".

Adding the plugin listpages with options find="Test_0" to the root of the structure shows the pages as expected.

Note the wikilink URLs generated by toc and listpages are different, but wikilink from listpages also results in the same "Page not found error" for the same page "Test_02----Page2"