Category: Dogfood on a *.tiki.org site

doc.t.o 12.x: print structure ("Tiki Reference Guide") stops after a two pages only or so.

Structure toc is something like this:
{CODE()}
Admin Home
General Admin
General Preferences
General Settings
...
...
{CODE}

and page General Preferences is the last one shown.
Url was like [https://doc.tiki.org/tiki-print_multi_pages.php?printstructures=%255B%25223610%2522%255D&find=&print=Print|this one]

In addition, tabs in the shown pages do not work. Maybe because js comes loaded at the end, and page didn't finish loading?

In any case, the best option for tabs in multiprint is that the __notabs__ option should be automagically implied when doing a multiprint.

I attempted to upload a simple image to a doc.t.o page (it seems to be using 19.x and elfinder) and I got error message about CSRF
{QUOTE()}
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

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

I had to disable elFinder to allow uploading images to doc.t.o.

Feel free to re-enable elFinder feature in doc.t.o anyone once it's confirmed to have been fixed.

(Seems dev also have issues, I couldn’t upload screenshot in the file galleries due to multiple timeout)

Doc is very slow and got very bad ranking on speed page test.

__Google: ranked 14/100, Time to Interactive 19.6 s__
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdoc.tiki.org

__GTmetrix (Vancouver, Canada): ranked E(58%), 5.6s to load__
https://gtmetrix.com/reports/doc.tiki.org/OJessE4M

__Pingdom (San Francisco, USA): ranked C(73), 4.99s to load__
https://tools.pingdom.com

---

Update 1/06/2021 on https://doc.tiki.org/ (worst)
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdoc.tiki.org
__Google: ranked 12/100, 15.8s to load__

__GTmetrix (Vancouver, Canada): ranked E(51%), 7.2s to load__

__Pingdom (San Francisco, USA): ranked C(73), 4.99s to load__

I saw this error when visiting this url: http://doc.tiki.org/preview564

{CODE()}
( ! ) Notice: MemcachePool::set() [<a href='memcachepool.set'>memcachepool.set</a>]: Server 127.0.0.1 (tcp 11211, udp 0) failed with: SERVER_ERROR object too large for cache (3) in /path/lib/cache/memcachelib.php on line 169
Call Stack
# Time Memory Function Location
1 0.0004 797536 {main}( ) ../route.php:0
2 0.0016 1069608 include( '/path/tiki-download_file.php' ) ../route.php:245
3 3.6856 80335592 Cachelib->cacheItem( ) ../tiki-download_file.php:369
4 3.6856 80335592 CacheLibMemcache->cacheItem( ) ../cachelib.php:44
5 3.6856 80335768 Memcachelib->set( ) ../cachelib.php:387
6 3.6856 80336192 set ( ) ../memcachelib.php:169
{CODE}

{img fileId="720" thumb="y" rel="box[g]"}

{syntax type="tiki" editor="plain"}
Background info:
http://tiki.org/tiki-view_forum_thread.php?comments_parentId=46281

So when you visit http://doc.tiki.org/Features, the actual list of features comes and goes.

You can see from the video below (I put a watch alert on that page) that it has been going on for months:
{flash type="url" movie="display251" width="1126" height="528"}

{syntax type="tiki" editor="plain"}
This is annoying!

Workaround is to remember to pick category again when you save.

A newly registered user cannot edit most of doc.tw.org

An anonymous user cannot edit doc.tw.org, even with CAPTCHAs.

There is no clear text on a page of doc.tw.org which tells a user why they cannot edit that page, or what they can do about it.

Thanks to this:
http://doc.tikiwiki.org/Forum+and+List+Synchronization

This:
http://sourceforge.net/mail/?group_id=64258

Should be mirrored here:
http://tikiwiki.org/tiki-forums.php

jCapture was understandibly removed from Tiki because browsers deprecated Java applets. Yet, the bug reporting process was not adapted.

To do:
* Make ((doc:RecordRTC)) work on dev.tiki.org
* Review all forms and documentation about reporting bugs (which included some parts about jCapture)
* https://dev.tiki.org/Make+a+wish+-+demo+your+bug?itemId=8023

Next servers are down (but next.tiki)

https://nextdoc.tiki.org
https://nextdev.tiki.org
https://nextthemes.tiki.org

502 Bad Gateway
nginx/1.12.2

This would be great ((tw:Dogfood)) to better organize our community and let users join groups according to their interests.

When this is fixed:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=986

This would be even better:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=829

but let's not wait!

See:
http://dev.tikiwiki.org/tiki-tracker_rss.php?trackerId=5

An example:
http://dev.tikiwiki.org//tiki-view_tracker_item.php?trackerId=5&itemId=280

Affects most of not all RSS feeds. Happens in non multi-tiki setting.
---
Double slash is a pretty common problem - happens sometimes, not always! That's hard to track and not really RSS related... often happens with tiki-login, too...
- amette
---
marc found a reproducable error, that also is a strong indication for where the double slashes occur - it seems that the last slash in the URL gets doubled, like here:
http://www.doc.tikiwiki.org/img/wiki_up//WikiUser-HomePage.png
You get this double-slashed URL, when you select "View image" from the context-menu of your browser on this page:
http://www.doc.tikiwiki.org/tiki-index.php?page=Using%20Wiki%20Pages

When trying to drag & drop a very large image into the drawing applet, I get the error below.

{img src=images/code.png}%%% {CODE()}
Exception in thread "AWT-EventQueue-4" java.lang.OutOfMemoryError: Java heap space
at Acme.JPM.Encoders.ImageEncoder.encodePixelsWrapper(Unknown Source)
at Acme.JPM.Encoders.ImageEncoder.setPixels(Unknown Source)
at sun.awt.image.OffScreenImageSource.sendPixels(Unknown Source)
at sun.awt.image.OffScreenImageSource.produce(Unknown Source)
at sun.awt.image.OffScreenImageSource.addConsumer(Unknown Source)
at sun.awt.image.OffScreenImageSource.startProduction(Unknown Source)
at Acme.JPM.Encoders.ImageEncoder.encode(Unknown Source)
at org.jgraph.pad.actions.FileExportGIF.convertToGif(Unknown Source)
at org.jgraph.JGraphpad.uploadToTiki(Unknown Source)
at org.jgraph.pad.actions.FileSave.actionPerformed(Unknown Source)
at org.jgraph.pad.GPDocument.close(Unknown Source)
at org.jgraph.pad.actions.FileExit.actionPerformed(Unknown Source)
at org.jgraph.GPGraphpad$AppCloser.windowClosing(Unknown Source)
at java.awt.Window.processWindowEvent(Unknown Source)
at javax.swing.JFrame.processWindowEvent(Unknown Source)
at java.awt.Window.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
{CODE}

You can see here:
http://dev.tikiwiki.org/tiki-searchresults.php?highlight=mouseover&where=pages&search=Go

Version 2.0 now offers an ((doc:Interactive Translation)) feature.

Next, we could set-up the web-based, interactive translation feature, and translation commits to main code base could be done regularly from i18.tiki.org to SVN. We would need to find a way to credit the translators in the CVS log.


References:
http://i18n.tiki.org

https://translations.launchpad.net/

How are the various *.tiki.org sites different in their configuration?

How about compared to the default setting?


How could we have a diff of 2 site's config? Perhaps this could be exported as a profile, and thus an easy way to "copy"/migrate configs from one site to another.

Ex.: in a staging & prod setup...

See: ((Configuration Management))

Related:
https://bugzilla.mozilla.org/show_bug.cgi?id=539151

edit article doesn't save if you change any setting in the advanced tab: to email.

Reproduced in
https://tiki.org/tiki-edit_article.php?articleId=442#content_edit_article1-5

Add any email in the "to" field, and you won't be able to save your edition, or your new article if it was the first time you were writing that.

The action log, in addition, says:
{CODE()}
/New article post at tiki.org [Invalid "To" header; contains no addresses]
{CODE}

Edit a page
Save

If latest wiki source is now different than what it was when I clicked edit, Tiki should tell me so I can manually merge issues.

Related:
{wish id=1191}
{wish id=2488}

{syntax type="tiki" editor="plain"}
In Opera (no need to mention version number; every Opera user uses the lastest version ;-) ), in the last day or so the edit textareas in branch 6 have been missing or misplaced, for wiki pages and trackers, that I've noticed so far. (Forum post forms are ok.) On the wiki edit page, the edit textarea is far down from the toolbar. Sometimes clicking on fullscreen edit and back again will bring it up to the toolbar. On the dev.t.o bug-submitting tracker form, the textareas for description and solution don't appear at all. I clicked on fullscreen editing and back, and a textarea appeared but it seems to be the solution textarea, not the one for the bug description. This affects the regular wiki editor; I didn't check yet about the wysiwyg editor.

{syntax type="tiki" editor="plain"}
{img fileId="361"}

This is a duplicate of the bug report submitted by Xavi...

If you are in a site with some "documentation" activity (a bunch of images already in the default folder), it's not easy for the end user to insert the image he/she has just uploaded to Tiki thorugh the toolbar icons/actions.

With the former file gallery interface to upload a file, you see the thumbnail or icon of the image/file just uploaded, so that it's very easy to find it and click on it to get the corresponding wiki syntax inserted in the text area, so that the file is used within the text.

With elFinder, this simple task becomes difficult, annoying, and time consuming (plus irritating at some times, if you can't seem to find the image you have just uploaded and you KNOW it's there somewhere).

Usual case (can be easily reproduced in doc.t.o):
# Log in doc.t.o
# Edit a documentation page
# Click at the toolbar icon to insert a new image from your local harddisk. elFinder interface is shown.
# Click at the icon to insert the file from your harddisk. Select your file, upload it.
# Once the file has finished uploading, you have no clue where the image is, and it's way more complicated to have your image inserted for you in your wiki page or text area.
** You have to start scrolling and scrolling there in the elFinder window to look for something... I know my image was called (real example from today) "tiki13_tracker_events_00.png".
** I typed "tiki13_tracker_events" in the search box, and nothing was shown (!).
** I typed "tiki13_tracker" in the search box, and nothing was shown (!).
** I typed "tiki13" in the search box, and dozens of images where shown (!!!).

At this time, my annoyance started to increase quite a lot, as you can image...

We need to make the lifer easier for the end user (and for the *.t.o Tiki contributor)

^ Expected behavior with elFinder:
* Once the file has finished uploading, we expected to have elfinder automagically search for that file name ("tiki13_tracker_events_00.png"), and display the end user JUST the icon/thumbnail of that file just uploaded, so that this human being can easily click on it to have it inserted.
^

Thanks for improving this lovely elFinder interface! :-) {sign user="xavi" datetime="2015-01-26T10:13:55+00:00"}

I think something has to be changed on tiki-admin.php?page=general with the SMTP settings (or perhaps Sendmail could work again?).

Flash plugin doesn't work well embedding videos from vimeo.com
Example, the video from vimeo.com at:
http://tikiwiki.org/TikiFestMadrid_videos

However, from blip.tv (or youtube, etc.), videos are embedded fine
---
UPDATE: Probably more than outdated (see current improvements in VIMEO by jonnyb in 12.x. {sign user="xavi" datetime="2013-11-17T09:50:12+00:00"}