Category: Documentation (or Advocacy)

Fresh install of Branch-1-9 daily build.
The help system (the system that turns the feature descriptions into live links that point to the docs) is not enabled by default.

Not Enabled on a fresh install of Sa Jun 16 15:42:39 CEST 2007

When upgrading to 2.0 rc4 from 1.9.11 install failed because I was not logged into the app. By the time I reached that stage, I was no longer able to login. Need to make note at the beginning of the upgrade procedure instructions to FIRST LOG INTO TIKIWIKI AS ADMIN

I know this is a new feature, but it is better to deal with this earlier than later... ;-)

At doc we have : https://doc.tiki.org/System%20Trackers that is about "system trackers" and mention "new section in Control Panels > Trackers > 'System Trackers'"
When I go to a fresh Tiki 23, searching for "System Trackers"in the admin search preferences doesn't help. (results are really not what I'm looking for)
If I search for "System", the option "Exchange rates tracker" is displayed among too many things (yeah System is used I Tiki ;-) )

This feature (section) is important enough to deserve its own tab (it will also rank the degree of "importance") and this section is (will be) a collection of trackers so it will grow and even with 3 or 4 tracker option (accordion) that will be awkward at the bottom of the page.

I run the following search on Tiki Doc: https://doc.tiki.org/tiki-searchindex.php?filter~content=wiki+syntax&search=Search

Many results point to files in the file gallery that show a broken result "invalid backend".

One of the result is : https://doc.tiki.org/tiki-list_file_gallery.php?galleryId=137&highlight=wiki+syntax

It turn to an error:
{img fileId="1204" thumb="box"}

So, i am encountering this error while running setup.sh on Bluehost shared environment.

PHP 5.2, 5.4 & 5.6 are installed and available for my use.

Currently PHP Version 5.6.17 is the default php version (confirmed with phpinfo), which has been set by an apache set-handler in the .htaccess.

After many attempts to modify setup.sh, I managed to by pass the warning by manually changing the php calls to php56s (my local php5.6). Now I get a error with composer saying that it should be run with the command line version of php. This has clearly gone past my expertise. Help please!

I have set this as a bug as I have met the requirements outlined and have followed the documentation here: https://dev.tiki.org/Get+code

I have solved the issue on bluest shared environments. I wrote a little tutorial on how to fix it located on the [https://tiki.org/Bluehost|Bluehost page].

I updated the ((Get code|Get code)) page, so if one reads and follows the whole, thing, it will eventually lead to the Bluehost page.

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.

This is not a wish or a bug. We just need the show instance for training.

Hi Devs, I need one show.t.o instance to show all (or most) of the bugs, which I find for Tiki pre-13.

I have a few smaller websites in production with pre-13 trunk to have a productive testing environment.

The bugs will be reported individually and refer mainly to this show instance instead of individual instances, where it makes sense (at least in my mind).

In case of questions or comments to this tracker item / show instances / bugs, you may write to torsten@tiki.org

Please read:

[http://irc.tiki.org/irclogger_log/tikiwiki?date=2009-04-18,Sat&sel=117#l113]


Something like:

{img src=images/code.png}%%% {CODE()}
{if isset($objectCategoryIds) and in_array(1, $objectCategoryIds)}
This is the documentation for {$page}. For bug reports and feature requests, please visit [http://dev.tiki.org/{$page}]
{/if}
{CODE}

Today I solved a longstanding issue, that I could not (for several years and many Tiki versions) load a site logo other than HTML-pointing to an image file, which thus had to be FTP-uploaded, and would not be as easily changeable as an image from an image or file gallery.

My error lies in the documentation of the Look & Feel page, where the blue info text clearly says " or the syntax to display an image in a Tiki gallery". That is not quite correct. It's not entirely wrong, but misleading.

The solution: Enter
tiki-download_file.php?fileId=nn

That works. The syntax to display Images from a gallery would have brackets around, so I would like to ask that this info text include the advice to leave out the brackets.

Documentation of Tiki (doc.tw.o) needs some help, as well as any other tiki site aiming to produce structured documentatation to be exported as "printer-ready" (.pdf, .odt, ...)

!!- (1). Original idea, as posted in devel list (but improved, and made it easier, below, in (2) )
I include here a copy of the [http://sourceforge.net/mailarchive/forum.php?thread_name=467565F1.9080905%40ub.edu&forum_name=tikiwiki-devel|original post at tiki-devel list]:

{QUOTE()}
[Tikiwiki-devel] New documentation file: Tiki198alpha.pdf
From: Xavier de Pedro Puente <xavier.depedro@ub...> - 2007-06-17 16:44

(...)

There are some issues that, it solved from coders, they would make
easier to produce next documents like the pdf ones:

(1) Page Title is not automatically shown on wiki pages on the server,
and thus, manual header1 was added everywhere (Almost). But when
printing to html, page title is duplicated. => if Show Page Title option
is disabled under "Admin > Wiki", Page title should not be added
automatically at print-to-html time.

(2) to produce the same structure (same level structure of headings) as
in table of contents http://doc.tikiwiki.org/Documentation , some hack
(optional) would be very welcome so that heading 1 in doc.tw.o pages is
not printed as heading 1 in through the multiprint, but as header 2, at
least. (optional).
This is, for instance, what is produced when printing a full structure
from a Workspace - AulaWiki Mod - : a coder could grab the code from
AulaWiki Mod as a reference....
In there, the description of the page is set as the Page title (header
2, I think), and the page title is included below for completeness (in
lower font, and with version number next to it)...

edutwo_ws_print_structure4.png

(3) Numbering of headings: somehow, in Workspaces this is handled
internally, and the user/documenter doesn't need to bother with manual
numbering: it's produced also at print time.
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Example of print structure differences between Tiki's multi-print and
Workspaces print structure:

Print to html "Aula-Wiki Tutorial" from here:
[http://edu.tikiwiki.org/tiki-print_pages.php]

or from here:
[http://edu.tikiwiki.org/tiki-workspaces_view_structure.php?print=4]

Well, as you could imagine, some changes to the code to make the work of
documenters a bit easier would be very wellcome also... :-)

(...)

{QUOTE}

!! (2) Update July 20th: Easier solution
Easier solution: Get levels for first heading in each wiki page of the structure not from the content of the page.

^__Example__: a page may start with a "! Title of page" (first level heading), and after that, "!! Subtitle of page" (2nd level heading), ...

Imagine that this page corresponded to "2.3.1 Module whatever" as the level in the table of contents of such structure.

The solution would be then that "!Title of page" (in that page "2.3.1 Module whatever"), when sent to (or fetched by) tiki-print_pages.php as a whole structure, was converted to "!!! Title of page"; and "!! Subtitle of page", should be converted to "!!!! Subtitle of page"..., and this way sequentially for all the title headings on each page from the structure...
^

The procedure below should become a 1-click from wiki (structures) to[http://doc.tikiwiki.org/Tiki19beta.pdf|PDF]. Please see:[http://doc.tikiwiki.org/Printing+the+Documentation|How to produce the .pdf out of the .odt]

-----

Dec 13 2008. Update:
Previous problem is fixed. However, I notice that automatic numbering with heading within a page (!!#, !!!#, ...), should be also considered in the global autonumbering.

Plus width of wide images and tables would be better if not that wide when exported to html (maybe an option), for the case when you plan to import it to OpenOFfice, and they are too wide to the document. Should this be another RFE or bug report?

---
REOPENING BUG
update on Jan. 7th, 2009:
See the other bug report: autonumbering didn't work for me with doc.tw.o/Documentation, even if it did a month ago on another site/structure

Related (and newer) bug report/RFE:
[http://dev.tikiwiki.org/bug2255]

{syntax type="tiki" editor="plain"}
When the system is set up to use staging & approval and the Structures are turned on, pages/topics created using the Add Page feature included with Structures get created with a staging name. The structure fails/disappears when the page is approved (fails in that the structure loses the staging name and does NOT substitute in the page without the staging name).

{syntax type="tiki" editor="plain"}
Here:
http://doc.tikiwiki.org/tiki-index.php?page=Structure&structure=Documentation -> structurs is 8.48

Yet, here: http://doc.tikiwiki.org/tiki-index.php?page=Documentation&structure=Documentation , it is 4.31


I don't understand the 8.48

Should be 4.31, no?


See related chat log:
http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2008-12-16,Tue&sel=315#l311

Currently, Tiki Manager lives without a release version, making sometimes hard to understand the version that is being used.

I would like to suggest a Tiki Manager software versioning, and making a release each month (if there are code changes).

The master (should we rename it to main?) would be the release branch, where tags will co-exist.
And on the side, we would have a 'develop' branch, that would hold all the code changes (that are not hotfixes) and released by merging to 'master' by the end of the month.

The tag would be the ending month: 2020.07 (YYYY.MM)
Hotfix tag: 2020.07.1 (YYYY.MM.*)

This strategy also allow, us developers, to use the 'latest' nightly version and found/fix issues before release date.

Feel free to comment or suggest.

This shows the World we are keeping up to date, and help with troubleshooting if a bug is discovered

* For major versions (ex.: 17.0): since last minor version of previous branch (16.3)
* For minor versions (ex.: 17.2): since previous minor version of same branch (17.1)
* Would be slick to have a chart like the following for all dependencies, like the "Package" table at https://distrowatch.com/table.php?distribution=clearos

Tiki trackers are great for a bug tracker, as we are dogfooding here.

But what about for a "help desk" setting? -> Private requests from many customers to one company.

Imagine a hosting company. They may have public forums & trackers. But they also have a place where customers can ask direct support requests. And only the customer and the company can follow this tracker.

There is a way for people to just modify their own tracker. But this is more for a user profile, than a series of support requests.
http://doc.tikiwiki.org/tiki-index.php?page_ref_id=3204

You can also give permission to add a tracker item but not view. But they can't modify existing tracker items. (like sending in a black hole)

If we want people to submit many tracker items, but only see/edit their own, what should we do?

Currently, there is and option "Item creator can modify his items?" at tiki-admin_trackers.php

Maybe we need one: Only item creator can view his items?" Of course, staff working for the company would be admins and could see the trackers for all companies.

Or there could be login drop-down, and only that user can see. Even nicer would be that it's possible for people of the same group to see.

Maybe this possible with the current feature set. In which case, just documentation is necessary.

Some things to experiment:
"My items" in tiki-my_tiki.php

Current workaround is to make a tracker for each customer.

Please see: ((Issue Tracker))

---
Related:
Trackers need "tiki_p_trackers_view_own" permission to view own items only
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=211

If install script fails (for some reason), we should at least let user proceed with manual installation.

when performing a search only the first page of results is available, the pagination links at the bottom of the page do not navigate to the subsiquent pages.

TikiWiki Powered Sites listed [http://info.tikiwiki.org/tiki-browse_gallery.php?galleryId=1|here] contains many websites which are moved away from Tiki, for example [http://wiki.kde.org|KDE Wiki]. A total clean up of invalid websites is required for the listing.

On Tiki22 on a tracker list items view I want to see in the listing the date and the modifier. I enabled "Show item last modifier".

Nothings happen.

Is it a bad description for the option ? (only work for item view)
Or something we used to have and is now broken ?

They are cases It would very handy to be able to list items and see the last modifier.

__Solved - PHP 8 is not yet supported by Tiki and is planned to become supported in Tiki25.__
__Tiki22, Tiki23 and Tiki24 LTS require min and max version PHP7.4 __

When I run a new installation on a quite decent shared hosting (all-inkl.com) with __PHP8.0__ (or __PHP8.1__) and same time __active feature Category__, then it is not possible to create a new tracker.
The modal starts to open, but disappears before it is folded out.
For a glimpse of a second it is possible to see the title of the modal which includes an error message.
The error message is in red color as following:
__Error loading content.__

''Either'' deactivating __Category__ ''or'' switching __PHP from 8.0 to 7.4__ allows me create a new tracker.

__Conclusion:__
There is a bug affecting Trackers, that occurs in combination of active Category and PHP8.x

What I did:

1. test the bug in a show2 instance
__result:__ bug not reproduced ... tracker created successfully

2. deactivate features on the devs local website step by step to find out the conflict
__result:__ bug on local instance, not on show2.tiki.org, narrowed down to Category feature

(:question:) Think about possible differences of local instance and show2 instance ...
(:idea:) Git vs SVN? http vs https? PHP version!

3. check PHP - local was on PHP8.0 - tried PHP7.4 and PHP8.1
__result:__ the bug disappears, when I set another subdomain and run the very same website on PHP7.4 whilst the bug consists on PHP8.1.

{syntax type="tiki" editor="plain"}
This is an ongoing task.

It will never be finished as we are always adding more features :-)

Info:
on tw.org the naming convention is to use a ,xx suffix where xx is the lang code. For example "Home" is linked to "Home,fr"

The comments on the page ((doc:permission)) report a couple of typos that should probably be fixed since they claim to date from March 2006.

People want to help Tiki.
Tiki needs more energy.

Let's make it easier to connect!

1st thing is to review all documentation. Make it faster/simpler/easier to transform a casual user into an active contributor.


1- http://tikiwiki.org/Participate

2- Update documentation at ((tw:ReportBug)) and at ((tw:RequestEnhancement))

3- All links/info on dev.tw.o

Star name was forgotten in code at the last release:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/branches/11.x/lib/setup/twversion.class.php#l31

If this is useful, it should be indicated in ((Releasing)). If not useful, it should be removed from the code.