Category: Wiki Plugin (extends basic syntax)

{syntax type="tiki" editor="plain"}
Adding any type of code such as PHP or SMARTY saves fine but adding actual HTML code inside the CODE plugin generates some funky results.

This means that it would be impossible to create a wiki page that demonstrates on to write HTML.

Show username / password

user: admin
pass: 12345

{flash type="url" movie="display315" width="1193" height="1040"}

When you use the code plugin, the page width formatting is thrown off. Instead of seeing both left/right colums, the right column gets shoved off the screen and I have to scroll. This is with scroll bars already setup on the code plugin itself.

--
Chealer :
This happens when nowrap was not set.

Gary (chibaguy):
In my checking (trunk version, but same relevant CSS as in Tiki 3 and $), almost all browsers respect the overflow:auto rule for the code plugin and don't cause the page to widen. I put a long unbroken line of text in the code plugin, and in Opera, IE, Safari (Windows), and SRWare Iron (Chromium - webkit), even this unbroken line was broken to impose a scrollbar on the code area and avoid a scrollbar on the window. Firefox was the only browser that failed at this.

If the current rules - overflow:auto, and 90% width in some themes - then all browsers will allow the long line to display unbroken and create the page-bottom scrollbar, pushing the right column out of view. As I understand it, this is the behavior reported as a bug here.

It is weird and no idea how to reproduce but on the page https://doc.tiki.org/Changelog-1.8?page_ref_id=4088 the CODE plugin is ignored like if it was not enabled at all.

We use the code plugin with the Full WYSIWYG editor to display code snippets.
- Support Tiki's "wiki syntax" is checked
- Limited wiki parsing is unchecked
- Use Wiki syntax in WYSIWYG is unchecked
(in order to create true html wiki pages with some wiki syntax for plugins)

Steps to reproduce:
* Use code button in WYSIWYG editor, put some code in the body section and click save
{CODE(caption="Original code snippet" theme="default")}#include <iostream>
using namespace std;

int main()
{
cout << "Hello, World!";
return 0;
}{CODE}
* Clicking again on the plugin (or saving the page and view) will give you this distorted code snippet:
{CODE(caption="Code snippet after first save" theme="default")}#include &lt;iostream&gt;<br>using namespace std;int main() <br>{<br>    cout &lt;&lt; "Hello, World!";<br>    return 0;<br>}{CODE}
* Paste again the code snippet in the plugin and click save
* Code is displayed correctly
{CODE(caption="Code snippet after second save" theme="default")}#include &lt;iostream&gt;
using namespace std;

int main()
{
cout &lt;&lt; &quot;Hello, World!&quot;;
return 0;
}{CODE}

As the workaround is simple but annoying, I suppose this is quite easy to fix, is there someone who can check this out?

When page content is too large, the browser is way too large or some content is truncated/hidden:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=Hello%20World&preview=73

This is the good behavior in Firefox but not IE6:
http://www.wikicreole.org/wiki/TikiWikiCMSGroupware

Maybe CODE plugin should have wrap=1 by default, but with the horizontal scroll, it'll be OK.

Yeah, we're building a COBOL advocacy TikiWiki site. The CODE plugin removes leading indentation. FIXED format COBOL uses a 6 character sequence number, column 7 as a special indicator and actual code starting at column 8. The initial $code = trim($data); is inappropriate for COBOL, and perhaps for other snippets that need to be cut'n'pasted with indentation intact.

I'd almost just go ahead and commit the change, but I'm not experienced enough with the technical details of PHP, and worry that the solution I'm using locally is not an unacceptable performance hit or that using the > v4.1 charlist feature of the trimming functions breaks legacy Tiki installations. I doubt it, but I thought I'd start here and get expert opinions.

{img src=images/code.png}%%% {CODE(colors=>php, title='lib/wiki-plugins/wikiplugin_code.php')}
function wikiplugin_code($data, $params) {
if ( is_array($params) ) {
extract($params, EXTR_SKIP);
}
$code = trim($data);
$parse_wiki = ( isset($wiki) && $wiki == 1 );

// Detect if GeSHI (Generic Syntax Highlighter) is available
{CODE}

All that is required is changing trim($data); to rtrim(ltrim($data, "\n\r\0\x0B")); so that leading spaces and tabs (tabs, they should be removed ... just because ... but that's not playing nice with others) are left intact.

We're using GeSHi, but this trim occurs regardless.

Thanks for listening,
Brian

As of Friday 4/15/2011, code plugins stopped displaying their contents on my 7.x head site.

For example, I have a code plugin with no options set that contains:

{CODE()}function validate_a as p (e as p)
'Sample validation function.
'Data for the current row is available in 'e.data'.
'For example, e.data.firstname, e.data.lastname
if e.data.a = "" then
validate_a.hasError = .t.
validate_a.errorText = "a cannot be blank."
end if
end function{CODE}

On my site, nothing displays except the edit marker for the plugin.

When the 'rel="shadowbox"' parameter is used with a wiki image, the popup expands to the full size of the original image, so scrolling is needed to see all of the image. Previously, the popup size was limited to some percentage of the viewport size.

Also, the "prev/next" links are missing when 'rel="shadowbox[[gallery]' is used; this is also a regression from before.

Sorry for the multi-drawer report.

On a Tiki25 I have a "tracker_item_modify" action (see last point, can be debatted).

## Wiki Page vs CLI

When applying manually the action on a __wiki page__ it work just fine.

When I run the command through the __scheduler__, while verbose and logs says it was done, in reality the action is not applied.

When I use the __CLI__ I have this error:
{CODE()}
php console.php list:execute "List executes control page" "Resave evaluations"
Undefined property: Search_ResultSet::$errorInQuery on line 313 of /home/happyhome/public_html/lib/wiki-plugins/wikiplugin_list.php
Action Resave evaluations executed on page List executes control page.
error: Error executing action Resave evaluations on item 1677099144: tracker_item_modify action missing value, calc, add or remove parameter.
{CODE}

After fixing the issue (again see below) the __CLI__ is still reporting an error but the action is completed correctly.
{CODE()}
php console.php list:execute "List executes control page" "Resave evaluations"
Undefined property: Search_ResultSet::$errorInQuery on line 313 of /home/happyhome/public_html/lib/wiki-plugins/wikiplugin_list.php
Action Resave evaluations executed on page List executes control page.
<feedback>feedback: Action Resave evaluations executed successfully on 1 item(s).
</feedback>
{CODE}

## Scheduler inaccurate report
The scheduler report (run now) and logs make the admin believe all went right while the CLI shows errors.
If an action is not completed the logs should show the output (from the console).

## Empty action to re-save item with item-list
The targeted item has been created from list execute with a duplicate action and has 2 item-list.
The item-list field are not populated after the action, and they need to be "manually" edited/save to get the other items values.

To make it automatic, I added a list execute with an empty tracker_item_modify action set only to force a "manual" save of the item.
{CODE()}{step action="tracker_item_modify" field="dailyevaluationDate"}{CODE}
This work manually but failed when using the CLI

I changed for
{CODE()} {step action="tracker_item_modify" field="dailyevaluationDate" calc="(concat (add dailyevaluationDate 1))"}{CODE}
This work (it change the date and time, but it is not critical in this case - all stays within the same day)

Editing https://tiki.org/Consultants and https://next.tiki.org/Consultants or visiting pages like https://tiki.org/tiki-admin_tracker_fields.php?trackerId=22 made the server crash half a dozen of times. When t.o crash I had also crash on next.t.o doing something else.

From my understanding both are not on the same server.
Is it possible something still ties them together or could it be (extraordinary) random server crash occurring at the same time ?

{img fileId="1219" thumb="box"}
{img fileId="1218" thumb="box"}
{img fileId="1217" thumb="box"}
{img fileId="1216" thumb="box"}
{img fileId="1215" thumb="box"}

Note: It happened before I rebuilt the index using the web interface. At the end of the rebuilding they were multiples errors (much diverse than the screenshot show).

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

If the content of a remarksbox __which is part of a list wiki syntax__ contains a line (carriage return) the part below it is displayed outside the remarksbox.

{img type="fileId" fileId="1257" thumb="box" desc="Plugin content"}

{img fileId="1258" thumb="box" desc="Plugin display"}

I create page content outside of tiki. I tranform content from a file to HTML code which I then paste into a new page in tiki with the given ~np~{HTML()}{HTML}~/np~ tags so it gets displayed formatted.

The actual problem is if I search for unique content of one of those pages, the search feature can't find it. Strangely content on some pages which are also created and displayed with HTML Code only, are searchable.
I read into the search feature and tested it with a few other searches of other pages to be sure it actually works. I also simply copy pasted the not working pages into a new page without the HTML and then the search feature also worked.
I can't seem to find the actual reason why some pages get properly searched and some not. Help would be appreciated.

* can't show the bug because no instance could be created and is not clickable anymore now

On the convene plugin the month selection arrow are not visible until you move over. Today’s date is not shown anymore.

It may after other areas than the convene plugin.
Can be tested here : https://dev.tiki.org/Improving-and-fixing-tiki.org-using-Tiki-22

On our Tiki Roundtable Meeting page there is a lot of redundancy task to manage the information.

One of them, at https://tiki.org/Roundtable-Meeting-2020-05 we have the convene plugin (people that voted to decide the time of a meeting based on their availability) and we have a list of confirmed people.

While it is not 100% the same, it would be nice and look alike most of the similar tools to have the "confirmed" list directly populated from the convene list.

This would be optional (a plugin parameter) to have it displayed.

We could extend it (like most calendar tools, including Tiki calendar) to have 3 options:
Coming, Interested, Not coming. (each one being displayable or not).

I think it all started when I was filling my availability row. This requires scrolling right, so I did not see the left-hand "save" icon. I saw a similar icon in the bottom and I clicked it (thinking "how clever, a floating save icon").
But it made me change pages to the calendar item of the top-selected time :-( (ooops!)
Then when I came back to the page, no availability was shown on my row (obviously) and I could not edit again (there was probably a lock) nor delete my whole line either.
Later on, I came back and I could fill availabilty agin and save.

Then I tried to add a new participant "Jyhem.logger" for confirming the issue
Then "Jyhem" was showing as if no availability was selected
But when I edited the line all was correctly selected. Just not shown
Also, I could not delete "Jyhem.logger" line

It was like there was some interference between the "Jyhem" and the Jyhem.logger" lines.

Then I edited the whole page and saw Jyhem had the proper selections. I cancelled edition of the page (no change).
Then all was good : I could delete "Jyhem.logger" and see the "Jyhem" availability
That's it

Convene plugin missplaces the counts in columns after the winning choice. See it reproduced in the screenshot below:

{img fileId="1093" thumb="box" width="600"}

In
https://tiki.org/Roundtable+Meeting+2016+09

After the count with the more votes (7, at the time of this writing), and the icon with the checkbox-like icon to indicate that this was the winning choice (Thu 15 Sep 2016 15:00 CEST), there is a button box in orange in the screenshot that should show a calendar icon, and that button allows to send that date to the pre-defined tiki calendar.
https://tiki.org/tiki-calendar_edit_item.php?todate=1473944400&calendarId=7

But no calendar icon is shown, and the count of votes for the next date (column in the table) is shown there instead ("3" instead of the calendar icon), and the next counts are also one column before where they should be.

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

From a quick view it seems there is a best day for the meeting.
however if we take a better look, there 3 possible days.

Instead of pointing (green success colours) to the first top result, there should be a better way to visually mark the 3 possible options.

It seems like for every added user it duplicates the votes entries in the plugin body.

It works when the duplicates are manually deleted from there so presumably the duplication is unnecessary and unwanted.

See:
https://tiki.org/tiki-pagehistory.php?page=Roundtable%20Meeting%202016%2009&compare=1&oldver=23&newver=24

Same thing is happening still with tiki 20.x on t.o. Reproduced these weeks here:
https://tiki.org/201909-TAG-Meeting?latest=1&amp;page_ref_id=1318

I just edited this morning a couple of options in my choices, through the convene UI, and the edition added itself in the background a clone of the plugin body several times {sign user="xavi" datetime="2019-08-28T13:35:45+00:00"}:
https://tiki.org/tiki-pagehistory.php?page=201909+TAG+Meeting&newver=45&oldver=44

convene plugin: prevent the user to add default info (Add or Add user string) instead of the real username or a different string

See it reproduced here:
https://tiki.org/Roundtable+Meeting+2016+09

((RoadMap)) shows "Fatal error: Call to undefined method TikiDate::getDate() in /home/tiki/public_html/lib/wiki-plugins/wikiplugin_countdown.php on line 60". This happens when using the COUNTDOWN plugin on PHP 5.1 and later due to a missing definition of getDate() in the lib/tikidate-php5.php TikiDate. The old TikiDate (lib/tikidate-pear-date.php) declared that function (via inheritance).

This was introduced in r14129 and widely exposed in r20047 on lib/tikidate.php.

Tiki Wiki is a content management system. And it can be used to distribute text (but also images, music etc.) to the world.

In Germany, there is no copyright as it exists in the US. Instead, authors have inalienable rights to their works (which cannot be sold or transferred) and for the usage royalties apply.

There is a system of collecting those royalties like VG Wort. If a publishing house reprints text that are declared by the author, publishers pay to VG Wort, they pool all those royalties and pay their members on the basis of the amount published by an author.

For several years now, VG Wort has a system for online texts (METIS). In order to participate, web sites must include "count marks" together with the texts. The author requests (personal) count pixels from VG Wort, and the website must be programmed so that it deliveres those pixels.

In essence, such a count pixel is just an img loaded from VG Wort's servers, a transparent GIF with 1x1 pixels in size. The author gets them in form of HTML lines like this, for example:

{CODE(Colors="TikI")}
<img src="http://vg08.met.vgwort.de/na/e1c16c290fc545d8809d5990b2295aa6" width="1" height="1" alt="">
{CODE}

There is one specific pixel per text, not per author.

It would make things vastly easier if Tiki could automate the process. Pixels get handed out to authors either als a PDF or as a spreadsheet table (CSV...).

A system could be devised where a Tiki user would upload such a CSV, and a plugin could be integrated into a content page (article or wiki). Less sophisticated, the user would indicate a "text ID" to identify the text. A more sophisticated system would, when the plugin gets called, look up if the calling content already has a pixel assigned, and if not, assign one and track the relationship of pixels with contents and then playout the respective pixel alongside with the content.

This system could also inform the user if the amount of pixels is less than the amount needed by current online content and create nice reports :-)

Systems for collecting royalties ("copyright collectives") exist in every country, so this would not only be useful for German Tiki users, but for practically everyone that shells out copyrighted texts larger than 2K...

https://en.wikipedia.org/wiki/Copyright_collective

I have stumbled upon a problem when a feature (especially Hotwords) is enabled it creates lot of issues incorrectly parsing the content of Wiki pages and other parts of Tiki where wiki or smarty syntax is involved resulting in links inside rendered HTML attributes or WSODs. So here is my wish:

It would be super useful to have a plugin which would prevent some enabled features auto-parsing or allow parsing of its body depending on params, something like:

__The next example would prevent (ignore) parsing of the Hotwords and CamelCase WikiWords in the plugin body.__

{CODE()}
{PARSE(ignore="feature_hotwords:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

__The next example would allow only parsing of Wiki syntax and WikiWords and nothing else in the plugin body.__

{CODE()}
{PARSE(only="wiki_syntax:feature_wikiwords")}
I am a ((Hotword|Hot word)) and I don't want to be double-parsed.
CamelCase is WikiWord? Yes!
__I am bold__ and I am not.
{DIV()}I am a div.{DIV}
{PARSE}
{CODE}

Other candidates for the "ignore" and "only" params:
feature_wiki_allowhtml
feature_autolinks
feature_wiki_argvariable
feature_wiki_paragraph_formatting
smarty_syntax
wiki_plugins (meaning all wiki plugins)
wikiplugin_div (meaning specified wikiplugin)
etc.

I think it would be useful also for the LTS versions.

Anybody takes the challenge ?

{sign user="luci" datetime="2013-12-12T20:48:49+00:00"}

We (geoff and xavi) were considering the benefits of creating a Profile out of a use case of trackers, plugin list and custom search. To achieve such a goal, a pre-liminary step is to implement a tiki site in a show.t.o instance here in dev.t.o, which is similar to a custom setup that Geoff has for some project. And then, convert that setup into a profile in profiles.t.o

More to come. And feel free to join us if you have some ideas or spare time to contribute to this project! :-)
(you will learn how to create a profile out of a tiki site)

show instance (based on Tiki12 LTS):
http://xavi-9794-5603.show.tikiwiki.org/
u: admin
p: 12345

When I use the image plugin in TikiWiki 18.3 and set the text to flow around the image (imalign=right|left) then the text flows around as it should.

When I set a caption to the image (desc="") then the flow is immediately disrupted.

Captions, when no text flow is set, work perfectly, so these two features disturb each other. I posted this as a question in the forum, and got a workaround and the advice to report this as a bug.

Thanks for your help
hman

{syntax type="tiki" editor="plain"}
On a Tiki27.x updated the customsearch plugin stopped to automatically load the page load results.
{CODE()}
{CUSTOMSEARCH(tpl="featuredFaq_customsearch.tpl" id="faqCustomSearch" recalllastsearch="0" searchonload="1" requireinput="0" customsearchjs="1")}
{CODE}

I can see an error in the DOM

{CODE()}
min_main_635f6700bf01c878afa54f2ab788dacc.js:108
Uncaught ReferenceError: jQuery is not defined at min_main_635f6700bf01c878afa54f2ab788dacc.js:108:98
min_main_abcaaa9d363b26f17986183396fe6829.js:43
Uncaught ReferenceError: jQuery is not defined at min_main_abcaaa9d363b26f17986183396fe6829.js:43:37
wikipage:499
Uncaught ReferenceError: $ is not defined at trackeritemtitle:499:1
wikipage:596 Uncaught ReferenceError: $ is not defined at wikipage:596:1
wikipage:1
{CODE}

In the Settings -> Performances admin panel
Minify JavaScript
Minify late JavaScript
Are enable.

If I disabled them both, the searchonload work again

On demo Tiki29 we can see an error feedback.

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