Category: Wiki Plugin (extends basic syntax)

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

if you youse the redirect plugin in an article you cannot edit the article as it redirect the page even in edit mode

http://www.w3schools.com/tags/tag_abbr.asp
http://www.w3schools.com/tags/tag_acronym.asp


This is already possible via ((doc:PluginTag)) but dedicated plugins could be cleaner/simpler in certain cases

To use the plugin helper, you need to click the (?), and then, click plugin help.

There should be a direct link on the toolbar.

When using the UserList plugin, the links on the user names leading to their personal information pages, are shown and hidden depending on privileges of the logged in user. Unfortunately, the logic is reverse of what it should be.

Correct logic is: show links for all users that when either A.) You have admin privileges. B.) User listed is yourself. C.) User listed has chosen to make his profile information public.

Current logic is: show links when A.) You have admin privileges. B.) User listed is NOT yourself, AND user listed has chosen NOT to make his information public.

Have just upgraded from 4.3 to 6.7 and find Plugin Showpages is no longer producing output.

Looked at [http://doc.tiki.org/PluginShowpages] for inspiration and notice that the examples there do not seem to be functioning.

Suspect plugin Listpages now has --equivalent-- similar functionality. --but we have at least one other broken plugin (WantedPages), so want to ask if there is a wider issue here, please?--

Was using ~np~{SHOWPAGES(find=>FAQ_ display=>desc) /}~/np~ but I don't see how to simply display the page description with ListPages.

--Also is there an easy way to find all the pages within our wiki where ShowPages has been used so I can change them to Listpages??--

Thanks,

Martin

Updated 08May12. The issue with WantedPages is now felt to be a separate issue and I'll open a new ticket for that.

Have also now found new to v6 Mass Search & Replace tool within Wiki Admin which is great.

Since upgrading from v4.3 to v6.7 the WantedPages plugin is no longer functioning for us.

The documentation for WantedPages at [http://doc.tiki.org/PluginWantedPages] has a note "Best Results - for best results, enable the WikiWordsPlugin, I found that if this plugin is not enabled, several desired page links will be recorded in the 'tiki_links' table, but not displayed in the list result of this plugin."

I've tested our site and did see good output from WantedPages when configuration option WikiWords at Admin -> Wiki -> Features was temporarily enabled.

We did not have this option enabled on our v4.3 wiki and Wanted Pages worked. Because our Genealogy One Name Study site [http://thereevesproject.org/data/HomePage_Wiki] contains community contributed transcripts from old wills, deeds etc, enabling WikiWords is not a valid option for us since these old documents often contain CaMelCase words which we want accurately transcribed and we would not want automatically generated wiki links created for those words.

This may also be related to an existing issue [http://dev.tiki.org/item2675] but I don't think its exactly the same.

Shouldn't the ability to produce a full and valid list of Wanted Pages be independent of other wiki features being enabled or disabled?

Thanks in anticipation,

Martin

Any other Plugin used within PluginTabs doesn't show the edit button. It is not possible to edit them itself like it was before.
For Example, Tab1 with CODE and Tab2 with FANCYTABLE:

{TABS(tabs="code|fancytable|box" toggle="y")}
{CODE()}{CODE}
/////
{FANCYTABLE()}{FANCYTABLE}
/////
{BOX()}{BOX}
/////{TABS}

{syntax type="tiki" editor="plain"}
several problems in Fancytable:
1. Field separator '|' (pipe) is not working with plugins. (must use '~|~' to get it work)
2. any plugin which is used in fancytable is looking fine when only one line is in. When you add a second line, you will get a lot of html viewed.

here is an example i used to figure out these problems:
{FANCYTABLE(head="code|box" colwidths="50%|50%")}{CODE(caption="code with 1 line" colors="sql")}select sysdate from dual;{CODE}~|~{BOX(title="box with 1 line")}1st line in a box{BOX}
{CODE(caption="code with 2 lines" colors="sql")}select sysdate from dual;
select sysdate from dual;{CODE}~|~{BOX(title="box with 2 lines")}1st line in a box
2nd line in a box{BOX}{FANCYTABLE}

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

! GROUP Plugin breaks CODE Plugin

Affects both v6.7 and this site. Worked OK on v4.3

{CODE(caption="1. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}

Now add a ~np~{GROUP(groups=>Registered)}~/np~ include the same code snippet and close out the ~np~{GROUP}~/np~. Start of CODE within GROUP

{GROUP(groups=>Registered)}
{CODE(caption="2. Code inside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}
{GROUP}

End of CODE within GROUP. On v6.7 the code box is displayed and the code snippet is truncated at the start of the Else statement fro a registered user. On this site, the code box is not displayed and the code is truncated at the same point for a registered user.

For an anonymous user, on both versions, there is no code box and the user see ~np~"other content{GROUP}{CODE} "~/np~

Repeating the code snippet again outside of the restricting Group statement works
{CODE(caption="3. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}.

The code example is lifted from [http://doc.tiki.org/PluginGroup] with a caption statement added.

Happy to help test any patch,

Martin.

Hello,

i found it annoying that you cannot redirect to an anchor or that if you use sefurl you you will still be redirected to a tiki-index.php site - so i wrote a small bugfix you can find in the attachment.

I don't know how secure it is as i am no security expert but it shouldn't open any wholes as far as i can see.

A Page Selector field from a Tracker plugin on a wiki page does not populate with the name of the page even with option Auto-Assign set to 1. Replicated on clean installs of 8.1-8.4 and 9.0b. Works fine on 7.2.

Bug is still present in master.

{syntax type="tiki" editor="plain"}
When using field names with text for group titles, only the last part of the string is used. For example
GROUP [project_name] "AAA [project_name] ZZZ":H1
If the project name is "upgrade system", the group title should be "AAA upgrade system ZZZ" Instead I get "ZZZ"
Using: GROUP [project_name] "AAA [project_name]":H1 I get "upgrade system"

It looks like the parser that is separating text literals from [field names] is discarding all but the last one.

Edit 16 Jul 2012 Also broken in v9.0

Was in Tiki 8.x too. Hoped it is fixed in Tiki 9 but it is still there.

I feel the need for a tag description field (that could be) associated to each freetag. That'd allow to place a definition (what does this tag mean ? what should it be used for ?) to make it as clear as possible for users to use the tags and know what they mean.

Not sure wether it was possible or not, I posted a message on the forum : http://tiki.org/tiki-view_forum_thread.php?comments_parentId=44367&forumId=4

Some plugins were not loading in the Plugin Help tab.

A plugin requires approval. The fingerprint of the plugin is recorded, and if it is already approved, another user can use the plugin (in other words can display the page which contains the plugin).

But, if the plugin contains the fragment "/{/{user/}/}", for example
~np~{SQL(db="LOPC_XF")} SELECT `Date`, `Subject`, `From` FROM vwMessages WHERE `To` IS NULL OR `To`="/{/{user/}/}" {SQL}~/np~

then the plugin needs to be approved for each user individually.
NB - I had to put extra slashes in the above fragments to stop my username being substituted!

My guess is that the username is being substituted BEFORE the fingerprint is evaluated, which means that there is a different fingerprint for each user.

I consider that this is a bug, and that the fingerprint should be evaluated BEFORE the username is substituted, thereby allowing the plugin to be approved just once.

It ought to be a one-line fix - swap round the order of two actions - but I haven't been able to work out where in the code this fix is needed.

i have try tw 9.2 and have problem with plugin Source in wisywig editor. it give me sorce of not last version of page. How i can change it?

I couldn't get the equation plugin to work. Tracked it down to a '\end{document}' latex command that should be '\\end{document}' since PHP saw the '\e' as an escape.

The problem is around line 189 in lib/equation/class.latexrender.php.

Suggest that all strings that are written to the latex file should have lead with a '\\' within the 'wrap_formula' function, even though the only line that was giving me a problem was the '\end...'.

For future versions 11 ? 12 ?

Hi,

There are several main marked up languages that we know well.

I think that it will be useful to be able to exchange (import, export) documents with other selected marked up languages.

!!I particularly think to two categories :

!!!1- The task and documents managers used by development tools : Eclipse-Mylin Aptana environment and Bugzilla

Remark :
About this category, I redact documents using textile to describe the developments integrated into projects and bugzilla.
This because I have near fifty elementary project developed since 4.0, stabilized at 8.3 and that I am preparing for 10.x. (They remain for most of them available and someones must be adapted - galleries particularly)

!!!2- The wikies
The problem is to exchange data with users of main wiki.

The need is to use the large capabilities of tikiwiki to hold projects management and documentation. But as it is not specialized it cannot be directly used.

!!There are several ways, this is completely opened :
1- Be compatible i/O with textile which is very closed from basic tiki marked up language. This for basic articles.
2- Develop a plugin using tikiwiki as marked up language for Mylin
3- Look farther with a full XSL XSL-Fo (note that with eclipse all marked up supported languages can be exported as XSL-

!!On the way, proposal
1- First : list of major marked up languages for wiki and task managers
2- Links import export existing from one to another
3- Choose the optimum
!!
Aim :
- Prepare use of tikiwiki in project management
- Be compatible with environments as Eclipse to with other project management tools

!!Reason(s)
- Tiki provides a lot of coherent and very useful tools to manage the content of projects (documents and detailed task management, studies) and groupware life and management which is the core of project management (the classical tools for planning are only in my mind a little part). __But it cannot be connected with specialized existing tools and information systems in various businesses. The problem and aim is to prune efficiently tikiwiki into these organizations.
__
Trebly

When tiki-view_blog.php?blogId=x lists many posts, each one using footnotes, the footnotes numbers are false except for the first post.

As each post of the list is parsed, its first footnote number is not 1, but the total number of all the footnotes of the preceding posts of the list.

Versions : 6, 9, 10.
See : [http://demo.tiki.org/10x/blog2|http://demo.tiki.org/10x/blog2]
and [http://demo.tiki.org/9x/tiki-view_blog.php?blogId=6|http://demo.tiki.org/9x/tiki-view_blog.php?blogId=6]

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

r45987 - still a problem in r46589

FILES plugin (in either the wiki or wysiwyg (full html) editor) is not working correctly as follows:

*the "FileID" parameter is being ignored - FileID list should allow just specific files to be shown.
*if the "Show Parent Gallery Name" (showgallery="y")is set, then the table headings/contents get out of alignment
*--Plus in the WYSIWYG editor it now breaks completely producing garbled content. THIS OK NOW--

r45984

When the showicon option is used with the FILE plugin the image is shown too large (its the same in both the wysiwyg and the wiki editors).

FIXED

Since Tiki10 the Tiki SMARTY Plugin, using the 'eval' option to simply display a smarty variable, no longer works because the underpinning smarty function.eval.php is no longer part of the Tiki distribution - the SMARTY Plugin code checks for the availability of function.eval.php in either lib/smarty/libs/plugins/ or the lib/smarty_tiki/ folders and gives an error message "Incorrect parameter"  if it is not found. Its removal is probably due to the move Smarty 3  but it is not clear whether there is Smarty 3 version of eval available. The Tiki 9 version of function.eval.php does not work in 10/11/trunk (gives fatal errors) so this doesn't give us a 'quick fix'.  

Solution needed to be able to 'eval' and display any smarty variable type not just strings