Category: Community projects

The Quality Team had a break time, and hasn't restarted yet.

Implement a sustainable solution:
* ((Quality Team - How to reduce the workload))
* ((tw:code.tiki.org))

Tiki directory was closed down from anonymous viewing for security reasons.

This section should stay restricted:
http://tikiwiki.org/tiki-directory_browse.php?parent=2

But the rest of the directory can be available.

How can we do this via permissions or category permissions?

At https://tiki.org/Get-Involved there is a lot (like a lot lot lot of 🤭) of explanations and it is hard to find the essential inside the text : __Where or How to register as a member of the community.__

While text should aerated with more spaces and illustrations, a first main block should display a big and nice: "Join the Tiki Community - Register" (or something like this).

--Tiki 18.x no longer needs mods.tiki.org-- It would have been nice to delete mods before 18.0 but it's somewhat late now...

Ref: https://tiki.org/forumthread67983

Presumably, we shut down mods.tiki.org in April 2021, at the end of the support period for 15.x?
https://doc.tiki.org/Tiki15

Auto-TOC is now activated on dev.tiki.org

This is nicer than ~np~ {maketoc} ~/np~ and th way going forward, but now, we have hundreds of pages with duplicate Table of Contents.

# Find them all via http://dev.tiki.org/tiki-searchresults.php?highlight=maketoc&date=0&searchLang=&where=wikis&search=Go
# Remove all the maketoc instance with an edit comment "Auto-TOC is now activated"
# Check if page looks OK. If not, report issue in Auto-TOC category, so it will appear here on ((Auto-TOC))

1- Deal with tiki-gmap_usermap.php and templates/tiki-gmap_usermap.tpl in a way that takes into account upgraders via FTP

2- Review any gmap-specific wishes to see if anything is still useful, and thus, move to general map category and for the rest, close with "won't fix" or "outdated"

3- Review all instances of gmap and googlemap in the code base

{syntax type="tiki" editor="plain"}
In order to make show*.t.o servers more sustainable (in terms of disk-space consumed by show*.t.o instances), a suggestion was fired in the [https://tiki.org/Roundtable-Meeting-2020-09|TRM of September 2020]]: once a bug report is closed, then "the system" could delete the tiki file tree linked to that bug report. Mysql db could be kept, but the many hundreds of Mb in current tiki versions from the file tree on disk could be removed to respect disk resources & availability for new show*.t.o instances.

Example: show2.t.o currently consumes something like 10 new Gb per month, due to the instances being created by users.

TRIM should use ssh-rsa keys instead of ssh-dss. For more information see https://www.archlinux.org/news/openssh-70p1-deprecates-ssh-dss-keys/

1) Document the state of testing going on tiki.org sites, collect historical information, and produce monthly report on pass/fail on various checks. (some of these checks might fail a lot of the time with no problem, but collecting the historical info is useful to tune the tests for future, notification can be disabled for most of these checks).

2) If possible, provide easy access to the monitoring dashboard for tiki.org sites.

After submitting a bug report I click on "Reproduce your bug using our feature called Tiki Show. Click here to reproduce your bug now" and then I get the error in the Subject.
Might be a current discrepancy?

Review all mods and decide what should be added to BRANCH-1-10
http://mods.tikiwiki.org/

Please see: ((To mods or not to mods))

criteria:
*license
*size
*security
*potential popularity of feature
*non-reliance on 3rd party code


Plugins that will now be in core (and removed from mods):

*include ok in 2.0, should be removed from mods
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=perm|perm]
*group (ok) should be removed from mods: wikiplugin_group.php
*[http://mods.tikiwiki.org/details.php?type=wikiplugins&mod=files|wikiplugin_files.php]
*wikiplugin_listpages.php ok?, just remove from mods?
*[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1550|wikiplugin_mouseover.php needs to be fixed, then moved]
*wikiplugin_trackeritemfield.php __done in 2.0__

Reason:
*Great plugins
*Mods installer doesn't work for everyone and there is no documentation for manual install

^
Let's coordinate here: ((Monitoring revamp))
^

Copied some suggestion I just throwed on irc..., after fighting each time on some of my production sites to manually send messages to many users which are kind of lost some times at the beggining of their participation in a tiki-site-powered community.

{QUOTE()}
(11:37:39) xavi: I was just wondering about a new and easy improvement of the registration process of new users to a community sit eusing tiki
(11:38:07) xavi: just through allowing an admin to add acustomized welcome message to new users successfully registered to the site...
(11:38:29) xavi: ... with the text and links he might need to tell to new users....
(11:38:52) xavi: ...in a similar way to what mailman does for the welcome message to new users...
(11:39:48) xavi: ...I imagine a simple text area, like site identity does, where the admin can write any simple text (with or without wiki markup? like the newsletter feature does/allows)...
(11:40:45) xavi: ...so that the admin can set that message easily (without manualy searching for the appropiate template to hack through ftp)...
(11:42:48) xavi: ..and the the new user, can review the infos and tips that he/she needs to know on that site: "now you can: # watch that forum where that important thing is discussed.... #join that newsletter/blog/articlefeature to be up to date about news from that community, #review and/or subscribe to that tracker..., ...
(11:45:22) xavi: oh well, I can't code php+mysql myself (yet, at least ;-) ), but I guess that this shouldn't be that difficult nor time consuming to an experienced coder, provided that that person agrees on that this feature is "low hanging fruit" to improve the experience of newcomers to a community, through improving the communication while the first steps of that person in the community site...
{QUOTE}

This could also be important for ((Workspaces)), and ((Organic Groups)). So that, not just to register (join the registered group), but as a customized message per group, so that, when joining a new group (at registration time, or later on through the subscribe groups plugin), you get the specific message with hints, links and remindings of things adapted for that group.

Various *.tikiwiki.org sites are managed by different volunteers on various hosts. That is good.

Each domain should be systematically copied over to someone else.

Something like:
||domain|managed by|backed up by
fr.tikiwiki.org|mose|marclaporte
themes.tikiwiki.org|marclaporte|luci||


Related:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=482

RSS feed for Articles in tiki.org produces WSOD. Reproduced here:
https://tiki.org/tiki-articles_rss.php?ver=5

or
https://tiki.org/tiki-articles_rss.php?ver=5&css=y
(as indicated here https://profiles.tiki.org/RSS+Handler which used to be a valid url afair)

or
https://tiki.org/tiki-articles_rss.php?ver=2

However, it works well in themes.t.o:
https://themes.tiki.org/tiki-articles_rss.php?ver=5

I wanted to add that articles rss feed to the Admin UI backend rss module ( loaded from here https://profiles.tiki.org/Unified_Admin_Backend_Default_Dashboard_1 ), but there is no point if it triggers some error 500 or WSOD by any other reason.

Any tip anyone on how to solve? @ohertel maybe?

On https://doc.tiki.org/Documentation#contentdochome-3 you can see under the "The latest Tiki news" that there are links to latest articles on tiki.org but each article title is repeated there 3 times - each with slightly different link, for example:
{CODE()}
https://tiki.org/tiki-articles_rss.php/article447-Tiki-17-0-released
https://tiki.org/tiki-articles_rss.php/img/smiles/article447-Tiki-17-0-released
https://tiki.org/article447-Tiki-17-0-released
{CODE}

Only the third one is correct and should be there. Please fix if you know how ;)

Thanks,
luci
---
Update 9/10/2018:
This is still there and it is not helping us with automatisation that are (could) help us to spread our news on different social network tools.
https://tiki.org/Community show 8 feeds for The opening of Tiki Online Open Hours

Gary mentioned that a new feed is create on each editing. Seems related.
---
Update 11/10/2018:
I tried to understand better and check setup different websites:
# On my local, debugger on, I can’t reproduce
# On my own website; https://bsfez.com/playground
## First check I have a single entry for each article in the feed module
## Second check (can’t say if it is hours later or days laters) I have 2 entry for each article. It is really unlikely I edited each one once and only once so it moderate the editing option (each edit add an entry).
+ {img fileId="1233" thumb="box"}
+ {img fileId="1234" thumb="box"}
# On tiki.org, they were some edit yesterday (by Luci) and now we have 4 entry for the last article
+ https://tiki.org/Community
+ {img fileId="1235" thumb="box"}

Document for ((Suite:ClearOS)) for backup on same server, and these backups archives can backed up off-server with ((suite:Syncthing))

It asks for password, but then, give "Error saving image: HTTP/1.1 401 Authorization Required"

I attempted to use the connect feature from wikisuite.org (using tiki15), and after providing the site details, saving, come back, and click at send info, tiki showed:
^
400 Remote service inaccessible (404)
Remote service inaccessible (404)
^

This profile https://profiles.tiki.org/Bug_Tracker_15 makes an attempt to allow the user to set the sender_email if they haven't done so yet (which is usually the case when we are creating new show.t.o instances, or reproducing some scenario in localhost to debug some feature, etc.)

I'm using the same type of syntax which seems to be working in other profiles:
But this one in Bug_Tracker_15 profile seems not to work:
{CODE()}
sender_email: $profilerequest:sender_email$YourEmail@example.com$
{CODE}

while these other ones, in [https://profiles.tiki.org/Easy+GeoBlog|Easy GeoBlog], for instance, work as expected:
{CODE()}
style: $profilerequest:style$gradiant.css$
sitetitle: $profilerequest:sitetitle$My Easy GeoBlog$
sitesubtitle: $profilerequest:sitesubtitle$My thoughts and musings$
browsertitle: $profilerequest:browsertitle$Easy GeoBlog$
{CODE}

I tried if the issue was adding an "@" character in the working fields of Easy Geoblog, but that worked as expected also even if an email was written there.

Time session is too short on Tiki.org.
They were complains about this for user and super users.

https://dev.tiki.org/tiki-phpinfo.php show that session.gc_maxlifetime=1440 (24mn).

Long edit session or complex forum answer that require test or screenshot may take more than 24mn (especially with one or two call in the middle).

Anything about 1h00 or 1h30 without causing resources stress will be great.

Setting User Tracker id login and registration fields from Profile fails

See example in this profile:
https://profiles.tiki.org/User_Trackers#Group

{CODE()}
permissions:
Members:
description: members of the association
include: [ Registered ]
user_tracker: $user_tracker #and once this work, we need to tell the system about which field ID to connect to
user_tracker_field: $login # On a clean install, the following both should be at "1"
registration_fields: $profileobject:user_name$
{CODE}

names as indicated in the documentation:
http://profiles.tiki.org/tiki-index.php?page=Permission%20Management&redirectpage=Group%20Handler

There are some issues with dropdowns and tablesorter data with trackers.
Reproduced in a show.t.o instance (just after the bug item is created):
http://xavi-9794-5607.show.tikiwiki.org/tiki-index.php?page=Wants
u: admin
p: 12345


(1) Tracker item status displayed in a PluginTrackerList as dropdown has no values (this is fixed in Tiki14.x, it seems). Fixing in 12.x LTS will be appreciated.

Response: This is not backportable to 12x unfortunately. This ability sort and filter based on the image title wasn't added until tablersorter version 2.17.5 and Tiki 12 uses 2.14.4. But I have fixed as much as possible and it is now possible to filter using o, p or c in 12x

(2) Dropdown field. An item has no value for that field. How do you select those records with empty value? Could some filter like "empty/not empty" be added to the fitlers?

Response: I don't see an easy way to do this. Would suggest using the sorting to sort empties to the top, or in some cases setting dropdowns or range properly could capture empties (e.g., if they actually have a 0 value). Will ask the tablesorter developer for a fix.

(3) when the order of the fields in the plugin trackerlist doesn't match the order of the fields in the tracker definition, the results are unexpected: it seems to overrule the order in the trackerdefinition.

Response: after further discussion this is not an issue - the sort parameter needs to be set to y for columns to follow the order of the field parameter.

Thanks in advanced!

Sheets do not place charts properly (almost hidden, in doc.t.o sheet intended for documentation)

This used to work in some earlier version of Tiki. (sorry I can't be more precise)

To reproduce, visit:
https://doc.tiki.org/sheet2

and click at tab : "Charts". You will see that at column C Chart, charts are placed to the left, below column B, and therefore, almost hidden.
{img fileId="1016" thumb="y" rel="box[g]"}

A Show Instance for a simple shopping cart.