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

When visiting dev.tw.o (homepage), I can't see anything in the central column of HomePage when I'm loogged in, but just the left column. When I'm not logged, I can read everything fine at homepage or any other wiki page.

My browser is Mozilla firefox 1.0.3 catalan. Maybe this has something to do with showing content for specific languages, and not speficied for the visitor's language? (or usage of default one?)

I have no idea (just started today to use 1.9.0 for production... I'm very excited after a year of long wait! :-) Thanks marc, sylvie and all devels (if you read this bug report) for this hard work of you all!
Cheers,
Xavi

P.:S Maybe adding a switch-lang-menu would help the user to select another language so that we can see the content on the homepage?

If wiki page x has a description (with preference feature_wiki_description) which contains a hotword, internal links ("wiki links" using the double parentheses syntax) to that page are broken. A ~np~((x|label))~/np~ link to page x will display...
{CODE(colors="null" theme="default")}
Part of page description..." class="wiki wiki_page">label {CODE} ... with a link to the hotword target on "Part of page description...", but no link to page x.

Hello

I went to enable HTML on all wiki pages so that I could do text wrap around an image. However, it appears that the code still appears instead of actually correctly wrapping the text as if it doesnt understand the html code afterall.

-Kat

{syntax type="tiki" editor="plain"}
When viewing the source for previous versions of a page an html line break tag (<br />) shows every time there's a line break.

See screenshot
{img fileId="367"}

{syntax type="tiki" editor="plain"}
as described in the topic

if you are trying to edit a page in a multilingual wiki where you have currently a language other than english selected (i only have german allowed in my tiki) you only see something like this (complete html output):
{CODE(wrap="1",ishtml="0")}<div class="floatright">
<a class="previewBtn" title="Vorschau Ihrer Änderungen." href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/magnifier.png" alt="Vorschau Ihrer Änderungen." width="16" height="16" style="border: none" class="icon" /></a></div>
<h1><a class="pagetitle" href="/test/tiki-editpage.php?page=test_de">bearbeiten: test_de</a>
</h1>

<!-- templates/tiki-preview.tpl start -->
<div class="wikipreview" style="display:none;" id="autosave_preview"><div>
<div style="float:right;">
<select name="diff_style" id="preview_diff_style">
<option value="" selected="selected">Vorschau</option>

<option value="htmldiff" >HTML diff</option>
<option value="sidediff" >Side-By-Side Vergleich</option>
</select>
<a title="Popup preview" onclick="ajax_preview( 'editwiki', autoSaveId );$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/arrow_left.png" alt="Popup preview" width="16" height="16" style="border: none" class="icon" /></a> <a title="Close preview" onclick="$('#autosave_preview').hide();return false;" href="/test/tiki-editpage.php?page=test_de"><img src="pics/icons/close.png" alt="Close preview" width="16" height="16" style="border: none" class="icon" /></a> </div>
<h2>Vorschau : test_de</h2>
<div align="center" class="attention" style="font-weight:bold">Hinweis: Dies ist nur eine Vorschau und wurde noch nicht gespeichert!</div>
<div class="wikitext">

</div>
</div><span id="autosave_preview_grippy" class="ui-resizable-handle ui-resizable-s"> </span>
</div>
<hr style="clear:both; height:0px;"/>
<!-- templates/tiki-preview.tpl end -->

<form enctype="multipart/form-data" method="post" action="tiki-editpage.php?page=test_de" id='editpageform' name='editpageform'>

<input type="hidden" name="no_bl" value="y" />



<table class="formcolor" width="100%">
<tr>
<td colspan="2">

<input type="hidden" name="page" value="test_de" />




<div id='edit-zone'>
<div class='textarea-toolbar' id='editwiki_toolbar'>{CODE}

Hi, I've just started a new Tiki 1.9.0, with new db with profile "Basic enabled for easy use", and after configuring the language in catalan, disabling some basic features, leaving just wiki, categories, etc., and clicked on the l10n Home link at the main applicationmenu, I got this error:
{CODE()}
Fatal error: Smarty error: [in tiki-show_page.tpl line 37]: syntax error: invalid attribute name: 'pàgina' title='seguiment' (Smarty_Compiler.class.php, line 1516) in /home/httpd/tiki19/lib/smarty/libs/Smarty.class.php on line 1088
{CODE}
Using style: __smartiki.css__, __tikineat.css__, but not on __simple.css__
If I change the language to English, for instance, I have no problems with __tikineat.css__, etc.

Probably, same bug as the one reported at:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=189&show=view&status=op&trackerId=5&sort_mode=created_desc]

Long and extra long wiki pages are not correctly displayed by the IE. Also no scroll bars are shown, so the content vanishes completly on a certain point of the page.

Long and extra long wiki pages are not correctly displayed by the IE. Also no scroll bars are shown, so the content vanishes completly on a certain point of the page.

Also articles are affected. :-(

just like this ((text中文))

it can't be parsed correctly as a page referer.

If 'Store attachments in file galleries' is enabled (feature_use_fgal_for_wiki_attachments , in File Gallery admin panel: "Use file galleries for wiki attachments"), a new file gallery is created each time a new wiki page is created.

When you removing a wiki page, the file gallery (which may carry no files at all) is left in place. The user would expect to see an option to remove the file gallery of the attachments too, along with the remove wiki page confirmation step.

Like when attempting to remove a wiki page from a structure: remove wiki page from structure only, or remove wiki page itself also.

Attached images are now broken on wiki page where they are used see:

https://doc.tiki.org/Currency-Amount-Tracker-Field
https://doc.tiki.org/Manager
http://doc.tiki.org/PluginMemberPayment

The images are here (example: https://doc.tiki.org/tiki-download_wiki_attachment.php?attId=51) the code that display them is broken.
{CODE()}{img attId=51}{CODE}

Hi,

Using Wysiwyg, I upload a image then it is stored in like .../wiki-up/image/xxx.jpg.
Under MutiTiki environment by domain name, this page does not show the uploaded image.
The source of the page shows that ".../wiki-up~~#FF0000:/domain_name~~/image/xxx.jpg" while that image was stored in .../wiki-up/image/.

So I guess that FCKEditor has to store a image into NOT .../wiki-up/image/ but into .../wiki-up/~~#FF0000:domain_nmme~~/image/ under ===MutiTikiwiki environment===.
(How to know for FCKEditor that the site is under MutlTikiwki, I don't know)

Thanks and Best Regards,
Shigeru Serizawa (Japan)

I can't upload images any more to wiki pages at doc.tw.o since upgraded to tiki4.
Using firefox 3.5.4 under GNU/Linux

Can anybody confirm on other OS or browsers?

Lately, all images inserted into wiki pages are taken by the "system gallery" system.

That is realy cool BUT can be very problematic.

My anonymous don't have to see gallery images cause this is restricted to registred or members peoples. But they could till now see pages with images in it, buttons, whatever.

With this new "system gallery" they can't see no image nowhere. That is not what it should be.

I tried to find the so called :"System gallery" to see if i can change individual permissions. On the list, logged as admin, i can't see it. When i click on the menu at "System gallery" (tiki-list_gallery.php?galleryId=0) this goes to an error (No gallery indicated)... I can't neither.

This is bad as my anonymous user see red x everywhere instead of pictures.

It should be easier for new users to migrate to tikiwiki: an import blog function (e.g. from wordpress) would help.

Import HTML: in wiki edit page should be option (ideally a perm). Option is there but it's not working

1. The {include page=“name”} command is tremendously useful for naive wiki users who add content. It lets them create macros and re-use them at will.

So I suggest that this might deserve an alias {macro } and deserve a description in the wiki syntax help.

Also a slight simplification. If there is no ‘page=”name”’ text but there is {macro “name”} then use “name” anyway.

Any user could do {macro “myheader”} at the top and {macro “myfooter”} at the bottom and {macro “myusualrant”} wherever they want. They just have to make an orphan wiki page for each macro they want.

2. This is so useful and flexible that you might deprecate the “apply content template” thing on the Properties tab. It is hardly any easier to use, and it allows the user to choose only one macro at the beginning. It should keep working for the users who have already used it, but there’s no particular reason for anyone to use it again.

3. To really put the icing on the cake, you might let admins have two macros for each user page, one at the top and one at the bottom. These should not be visible when the user edits the page. So for each page category, the admin could decorate it a special way. Some might automatically get polls or other info visible. Or dancing bunnies, or whatever. It lets admins customize user wiki pages without coding, in ways that are hard to do without coding now. Without annoying users with the displayed calls on their edit pages which they might edit wrongly.

I just came across a problem with the vertical offset for targeting headings with autotoc. That is, a problem caused by this code:
{CODE()}
h1:target::before, h2:target::before, h3:target::before, h4:target::before, h5:target::before, h6:target::before {
content: "";
display: block;
height: 83px;
margin: -83px 0 0;
}
which is inline CSS when autotoc and the sticky top navbar (in this case 83px in height) are used. In a page with some links just above a heading, the links can't be clicked because the transparent 83px-high target overlaps them from the heading below.

I tried a few tweaks to the CSS but didn't have any success. Probably at least it should be documented, that every heading or other in-page anchor targeted by a link will have a zone above it equal to the navbar offset set in L&F admin that shouldn't contain links or other HTML that needs to be clicked, etc.

Say I include a bunch of pages in one larger page.

I click edit, and find that it's an included page. I should be able to edit directly that included page (assuming I have permissions), a bit like ((doc:section edit))



Benefits:
*Each page has independent history.
*They can be edited in parallel.



__Can page renames also survive inclusions?__


Related:
*{wish id=2668}

{syntax type="tiki" editor="plain"}
I have a problem similar to [http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=291|this one]: "Edit" button in Wiki points to "/\/tiki-editpage.php?page=HomePage".
Other buttons also have invalid URLs, links have correct URLs.

Configuration: TikiWiki 3.2, Windows XP, Apache2.2, TikiWiki is in the server root directory.

MediaWiki/Wikipedia has an interesting way of dealing with meta-data concerning a wiki page. [http://en.wikipedia.org/wiki/Help:Infobox|Infobox] is very flexible and is very suitable to an encyclopedia. It's easy to create new ones and they are very flexible to adapt to the topic. As soon as a bunch of pages have something in common, you can create one and it gives visitors and quick overview of what characteristics this entry has.

There are over a hundred of these templates:
http://en.wikipedia.org/wiki/Category:Infobox_templates

Here is a simple one:
http://en.wikipedia.org/wiki/Template:Infobox_Animal

Here is a more advanced one where special language codes, when parsed, are shown with a nice presentation:
http://en.wikipedia.org/wiki/Wikipedia:Babel

This is a great way to have ad-hoc, organically growing meta-data around wiki pages which share some sort of structured/comparative data.

In TikiWiki, we use ((doc:trackers)) for tabular data. We need to have an even tighter integration.

Goal: that the metadata be stored both in the wiki page and the trackers
That you can update in one or the other. This would permit us to make lists/tables with all the data from all the infoboxes, without duplicating the data. (not sure if/how to do this with MediaWiki)

We'd need a Wiki Page field-type in trackers. Say I have an "Animals" tracker with all the Meta-Data. One of the fields should be the name of the associated wiki page. And that wiki pages "knows" to get latest data from tracker (like we do now for ((doc:PluginTrackerList)) and ((doc:PluginTrackerItemField)).



{img src=images/code.png}%%% {CODE(caption="2008-06-22 on #mediawiki on freenode.net", wrap=1)}
[09:48] marclaporte: Say I have lots of data in various infoboxes, is it possible to make a report/list/table of all these infoboxes and have them link to the various wiki pages?
[09:48] Splarka: you can use Special:Whatlinkshere on each infobox
[09:48] Splarka: (sorta)
[09:49] marclaporte: tks, would you know of an example?
[09:51] Dantman|FS: SMW
[09:51] Dantman|FS: Doing that with data is basically the purpose of SMW
[09:52] Splarka: http://en.wikipedia.org/wiki/Special:Whatlinkshere/Template:Infobox_Aircraft
[09:52] marclaporte: There are some lists here: http://en.wikipedia.org/wiki/Comparison_of_wiki_software -> how to reuse that info in infoboxes on each page
[09:52] marclaporte: tks
[09:53] marclaporte: Splarka: : yes, that's what I am looking for
[10:05] marclaporte: Splarka: : So now I know where the template is used. What if I want to make a mega chart for all the planes from all the infoboxes?
[10:06] Splarka: well, that might be something more for the category system
[10:06] Splarka: (or ask Dan about SMW, unless he means Super Mario World)
[10:08] Dantman|FS: heh
[10:10] marclaporte: Dantman|FS: : What is SMW?
[10:10] Dantman|FS: Semantic MediaWiki
[10:10] Dantman|FS: http://semantic-mediawiki.com/
[10:11] Dantman|FS: It's an extension for MediaWiki
{CODE}

!!Other things to think about:
*When watching a wiki page, how to watch tracker(s) which are associated with that wiki page?
*In page editing of tracker data, have a quick & nice interface like the ((doc:dynamic variable)) feature

Related:
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1781|Support for the Wiki creole markup (syntax)]
*[wish1220|MediaWiki import script]

When a user creates a new page from an existing page (either through the Create Page module or by clicking on a "?"), categories could be inherited.

The problem is that this is not necessarily behaviour required for all TIki installs, and might have to be coded as admin configurable.

When I have a plugin in a wiki page, and "Edit icons" is activated in the Page Actions dropdown list, when I click the plugin edit icon, nothing happens. I've tried this with PluginList and PluginHTML. I'm trying this in Tiki master that is up to date, and I'm using Firefox/Windows 11.

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"