Category: Dogfood on a *.tiki.org site

{syntax type="tiki" editor="plain"}
At dev.t.o, when you save a ticket you landed to a "success" page with a confirmation of the operation with the ticket title that is a link back to the item, essential to check and edit it with additions.

The title is here, but the link is gone.

See: https://ibb.co/czjkGm9

The database of dev.tikiwiki.org is b0rked - it has utf-8 characters in a latin1 database, which messes stuff up. I have no idea when this happened, but it is likely that afterwards new bugs have been reported that include special characters and work correctly. It is virtually impossible to fix that afterwards. But before migrating to a new host, we wanna test that. so lets write some Umlauts and see how they get displayed after saving the bug:

ÄÖÜ äöü éèê

(luci edited and saved)

We are documenting some ((info:Use Cases)) which will become profiles. To be able to developer/test/improve these profiles, we would need a site like [http://www.opensourcecms.com/index.php?option=com_content&task=view&id=180|Open Source CMS] but for all profiles. This site only shows one profile.

These 20+ demo sites would provide admin access to easily test any profile. It would encourage people to generate and improve various profiles as well.

Related:
((Profile Manager))
((TRIM))

Organic Group Addon gone in current 14.x compared to what doc.t.o says about it

See http://doc.tiki.org/Installing+Addons?structure=HomePage+AdminGuide

But in 14.x svn r55196, no option to enable Organic Groups (no organic group seen at all in the Control Panel Features > Addons tab.)

See it reproduced here:
http://xavi-9794-5643.show.tikiwiki.org/tiki-admin.php?page=features#contentadmin_features-addons
u: admin
p: 12345

Steps to reproduce:
# go to ((Make a Wish)) on this site
# click the print icon
# scroll down and try to return to this page by clicking on the link: The original document is available at http://dev.tiki.org//Make+a+wish

I wonder why I did not see this before... But now it's clear to see.

The function to count page accesses is completely (!) out of order. My site contains > 300 pages. ALL OF THEM have an access counter in the "list pages" view of 0. Zero, nada, nothing. During my efforts to create a readable German translation I have visited numerous pages time and again, there must have been thousands of page impressions, and yet every single page is counted as having zero visits...

The absolute minimum for every page would be the number of page revisions plus one, because every page is visited after creation or modification. But all of the >300 pages list as 0...

And again, the need of a bug category "LOSS OF DATA" arises...

I discovered a problem where one of our users had created a page containing the words SeaMonkey in the description. When she later tried to link to this page with the syntax ((PageName|This is the link text)), the link broke, and tried to embed a link to create a new page titled SeaMonkey among other things. The cause of the problem, was that the description of the page she linked to, was inserted as the title of the <a>-tag.

The pagehistory button bar is ugly.
Look at : https://dev.tiki.org/tiki-pagehistory.php?page=Profiles+revamp

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

Database error on [https://tiki.org/tiki-print.php?page=Community&display=pdf]

Seem the auth token isn't getting generated maybe?

I tried to update mPDF there via admin/packages and it said it failed because:
{CODE()}Problem 1
- Conclusion: don't install mpdf/mpdf v8.0.7
- Conclusion: don't install mpdf/mpdf v8.0.6
- Conclusion: don't install mpdf/mpdf v8.0.5
- Conclusion: don't install mpdf/mpdf v8.0.4
- Conclusion: don't install mpdf/mpdf v8.0.3
- Conclusion: don't install mpdf/mpdf v8.0.2
- Conclusion: don't install mpdf/mpdf v8.0.1
- Conclusion: don't install mpdf/mpdf v8.0.0
- Conclusion: don't install mpdf/mpdf v8.0.7
- Conclusion: don't install mpdf/mpdf v8.0.6
- Conclusion: don't install mpdf/mpdf v8.0.5
- Conclusion: don't install mpdf/mpdf v8.0.4
- Conclusion: don't install mpdf/mpdf v8.0.3
- Conclusion: don't install mpdf/mpdf v8.0.2
- Conclusion: don't install mpdf/mpdf v8.0.1
- Installation request for mpdf/mpdf ^8.0.0 -> satisfiable by mpdf/mpdf[v8.0.0, v8.0.1, v8.0.2, v8.0.3, v8.0.4, v8.0.5, v8.0.6, v8.0.7].
- Conclusion: remove setasign/fpdi 1.6.2
- mpdf/mpdf v8.0.0 requires setasign/fpdi ^2.1 -> satisfiable by setasign/fpdi[v2.1.0, v2.3.4, v2.1.1, v2.2.0, v2.3.0, v2.3.1, v2.3.2, v2.3.3].
- Can only install one of: setasign/fpdi[v2.1.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.1.1, 1.6.2].
- Can only install one of: setasign/fpdi[v2.2.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.0, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.1, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.2, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.3, 1.6.2].
- Can only install one of: setasign/fpdi[v2.3.4, 1.6.2].
- Can only install one of: setasign/fpdi[1.6.2, v2.1.0].
- Can only install one of: setasign/fpdi[1.6.2, v2.3.4].
- Installation request for setasign/fpdi (installed at 1.6.2) -> satisfiable by setasign/fpdi[1.6.2].
{CODE}

A new short URLs / Search Engine Friendly / Rewrite Rule with .htaccess was added to Tiki 2.0 as experimental (great!)

However, this causes issues with pages like:

http://tikiwiki.org/Custom+email+message+to+new+tikiwiki.org+registrants
http://tikiwiki.org/TikiWikiRelease1.6


Related:
[wish2108|Equivalent characters for page linking, backlinking, searching, etc (ex.: space, underscore, period)]

Use case:

We want users to update their profiles every once in a while.

So the system should be reminding users to click on tiki-view_tracker_item.php?view=+user and update their user profile.

Eventually, an email reminder could be cool as well.

permissions "minor" seems useless on doc.tw.o: registered can't use it even if granted to them
Check it live on: http://doc.tikiwiki.org
Login as admin to check that tiki_p_minor is granted to registered. Logout and login again as plain registered user, edit a page, and you don't see the "minor" button.

Registered users need it since it is a part of the interface needed for best interaction with new translation features on 1.10 (minor changes are not counted as new content to a page is being translated; if no minor, then a minor change to an outdated page reports to the up-to-date pages that new content has been added on other pages, and thus, lots of noise is introduced in the community)

There are case admin / webmaster / editor of a website need to communicate to all its users or group no matter what preferences they set for communication.

That was the idea that lied under the "Broadcasting" feature.
Actually by default users are not accepting messages and this is simply killing this feature. While there are questions about this default setting (should it be enable or disable by default) one thing is sure when you want to contact ALL you need to be able to contact ALL with regards of other preferences.

As this is a sensible setting (we don’t want people having access to spam) it would make sense to have a permission for it so Admins decide if and who has the ability to force a message to reach everyone (internal Tiki).

A check box with a warning (are you sure you want to...) added to the permission is what we need.

Thanks Jonny for volunteering. ;-)

I've run a script on all profiles from all branches ( https://github.com/xavidp/TikiProfilesTester ) and I see that all profiles since 15.x throw this error message (which might be related to the fact that unified search index may be currently enabled by default)?
{CODE()}
PHP Fatal error: Uncaught Search_MySql_LimitReachedException: Could not perform index modification: Incorrect datetime value: '0000-00-00 00:00:00' for column 'creation_date' at row 1 in /var/www/html/15.x/lib/core/Search/MySql/QueryBuffer.php:55
Stack trace:
#0 /var/www/html/15.x/lib/core/Search/MySql/QueryBuffer.php(37): Search_MySql_QueryBuffer->realFlush()
#1 /var/www/html/15.x/lib/core/Search/MySql/Table.php(195): Search_MySql_QueryBuffer->flush()
#2 /var/www/html/15.x/lib/core/Search/MySql/Table.php(28): Search_MySql_Table->flush()
#3 [internal function]: Search_MySql_Table->__destruct()
#4 {main}
thrown in /var/www/html/15.x/lib/core/Search/MySql/QueryBuffer.php on line 55
{CODE}

Using php 5.6, and mysql (server) 5.7.12 (mysql client: libmysql - mysqlnd 5.0.11-dev - 20120503).

Profiles are applied through the command line with "php console.php p:a ProfileName"

http://mods.tikiwiki.org/details.php?type=lib&mod=phpfreechat

the fact is that even if installing by hand, the phpfreechat plugin doesn't work for me, neither on tiki 2.x (with ajax enabled, etc., cleared browser and tiki caches, etc.: just says: "chat loading, please wait, and nothing happens), nor in tiki 3beta4 (it's even not listed in the list of plugin to enable/disable)

It's a pity that we can't provide a functional chat for tiki 2.x or tiki3.x sites... (minichat module for tiki3 was getting close to functional, but since it doesn't provide the date stamp nor a way to read the log from previous conversations to specific date, it's not being used... see the example of the last TikiFestUK: dimdim, skypechat, + irc chat)

Checking Piwik on trunk

Please add a (small) timeout to the popup box that is launched on mouseover that contains user info, avatar etc.

Or add a mouseout that kills the popup, which would even be better IMHO.

Reason: If you navigate "classic style", i.e. with a mouse, over sites like dev.tiki.org, you constantly mouseover peoples' user info, and this means you have to stop in your mouse movement and go back to the info that caused the popup, which in long lists might take a while, and not before you found the source will it go away... So this behaviour blocks you in your tracks...

Thanks alot!

Noob here enjoying the site, enjoying the software and finding my way around. Thank you.

It means spending a *lot* of time at the Tiki sites.

I get the message already about the dogfood. Cool.

But every day, every page load, I must dismiss this notice to uncover what is underneath. Or scroll the viewport out from under it.

It is located on top of the navigation.

Can we not have it fixed in the page above the navigation, or permanently dismissable once logged in, or ...?

Can we just use the site now, and stop swatting at the javascript? :)

I'm just setting up svn etc now. And wouldn't have the balls to make such a visible change right off the hop anyway. It's not real important obviously. But if somebody is there and knows and can do, it would make surfing the sites more pleasant...

Cheers!!

See the 3 slides starting here at minute 16' 48'':
http://recordings.blindsidenetworks.com/bigbluebutton/a71a9df7c98b845ae41553a527a5e7c03a69fe27-1431112418160/presentation/index.html?t=16m48s

New params are added to the api, that could be exposed to tiki, so that they are shown at the description list of the bbb meetings recorded for that channel, etc.

((Plugin alias)) which I am considering renaming __Plugin builder__ permits some amazing things.

((Backlinks)) can be cool for dynamic & efficient information organization.


How can we have the two together?

Perhaps an alias of the REDIRECT plugin which includes semantic wiki link "alias" between the two pages...

More on this later...

The Plugin CODE (with or wihout codemirror) doesn't escape the __~np~~np~foo~/np~~/np~__ wiki syntax.

Example:
__~123~CODE()}~np~~np~foo~/np~~/np~~123~CODE}__

Displays:
{CODE()}~np~foo~/np~{CODE}

--------
{sign user="pascalstjean" datetime="2013-09-10T16:12:25+00:00"}

See also the following CODE Plugin Bugs. Consolidating all of them under one report
http://dev.tiki.org/item4205
http://dev.tiki.org/item4624
http://dev.tiki.org/item4111

{syntax type="tiki" editor="plain"}
Using Plugin Edit to amend a FancyTable in WYSIWYG submitting a change causes all line breaks in the table body to be removed.

The PluginEdit shows the field "Rows separated by >> in the header; for the table body, one row per line. Cells separated by | in both cases."

Creating a working FancyTable with table body rows like this:

row 1 cell 1 | row 1 cell 2
row 2 cell 2 | row 2 cell 2

after inserting with the plugin edit tool this changes to:

row 1 cell 1 | row 1 cell 2 row 2 cell 2 | row 2 cell 2

When looking at version of the page the inline editing should be disable.

To reproduce, go to https://tiki.org/tiki-pagehistory.php?page=Roundtable+Meeting+2017+04
View a previous version (not the last one) on your screen.
You are able to edit the convene plugin.
This is wrong.

Inline editing (any editing) should be disable.
A warning (notice) should tell the user something like: "Editing is not permitted on previous version of a page. If you want to use this version and edit it, first rollback the page then you’ll be able to edit it."

13.x in dev.t.o: some toolbar buttons like wiki link broken (reload the whole page) . Try while reporting a bug.

Tried to reproduce in a show instance:
http://xavi-9794-5448.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage
(u admin p: 12345)
but I can't: it works there. It seems to be something specific in dev.t.o

Seen here: http://next.tiki.org/tiki-admin.php?page=general