Loading...
 
Skip to main content

Category: Dogfood on a *.tiki.org site

Bug or RFE for this site's Tiki
Dogfood on a *.tiki.org site
Show subcategories objects

Name Type
Check & report broken links
*.Tiki.org sites have a large number of external links. It would be nice to have a tool to check all the links and to report on status. Possibly this could be related to the cacheing feature.

See: ((Link Checker))
tracker item
PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict
See first the box saying "Even better" below.

"__PluginTogether should replace the url associated with the Edit page button so that co-editors are automagically offered to go to the session with collaborative edition instead of the warning of edition conflict__" (was --"Clicking on PluginTogether on a wiki page should provide a CoEdit button next to Edit with the right url for all."--)

This would be useful for taking meeting minutes collaboratively in the ((tw:TRM)) and ((tw:TAG)) meetings, both which take precious time from some active tiki community members but with little time to do things properly (wasting precious time in this note-taking task instead of being able to invest it in other areas requiring their help too). {sign user="xavi" datetime="2017-01-12T13:09:23+00:00"}


I've been trying to use tiki for many semester with my students at uni but I can't get them to use it with realtime collaboration with ease, so that they move to googledocs.

This minor usability change would be probably enough to convince teams to use tiki realtime collaboration feature with plugin togetherjs.
Like ourselves when taking notes on a roundtable meeting, or tiki admin group meeting, etc.
{BOX()}
__Even better__
Even easier for the end user would be to just offer a user that sees the concurrent edition warning box, a link to carry on and convert the session into a togetherJS session in which both users continue writing together. In the backend, tiki would probably:
# A new general preference should be added for this new behavior to be enabled
# when user A clicks at edit a wiki pageFoo, the url that would be created by PluginTogether is stored in tiki mysql tables somewhere, with a semaphore/flag or similar so that tiki knows that this page has been started edition and the url to allows others to go into the same edition session collaboratively.
# when user B clicks at the __Edit__ button of the same pageFoo, while still being edited by userA, userB sees the warning of edition conflict unless userB accepts to request to userA to enter into the collaborative session.
# If userB accepts to request that coedition to userA, then UserA would see some warning about that request from userB in some popup/modal/or similar, with the option to accept and get his edition saved and restarted as online collaboration among both, or reject the request, and keep writing himself alone in that page.
# therefore, save the edition in place by user A (the one that started editing the page first)
# reopen that page for edition for user A with te url adapted to the togetherjs session, and
# send user B to the edition session with togetherjs (or alternatively, show userB the same link to open the page for edition).
# if userA accepted userB to write together, they both are working with TogetherJS on that page. And in that case, when other users such as userC clicks at edit the wiki pageFoo again, userA gets the same message requesting to confirm to accept new users getting the collaborative session, and when accepted, since the TogetherJS is already on, there wouldn't be any need to restart the edition session with togetherJs since it would be already in that mode.
{BOX}

---
This is currently partly working in 21.x LTS {sign user="xavi" datetime="2020-04-01T10:32:07+00:00"}:
* user is sent automagically to open the session without "Warn on edit conflict"
* ... __BUT the together session fails to display the other users being there editing the page concurrently__:
** therefore, a new version is saved, without noticing that the versions will not be seen by each other: -+Edit Conflict triggered+-.

To reproduce the updated problem info:
Come here with two different browser engines (or one in provate browsing and hte other in normal, as usual to test this feature):
http://xavi-9794-6160.show2.tikiwiki.org/tiki-index.php?page=HomePage
user1:
u: admin
p: 12345

user2:
u: user
p: 54321

# Click on button of the side module "Co-Write with TogetherJS"
# Edit homepage as user1 (admin) in browser engine1 (e.g. firefox)
# Edit homepage as user2 (user in browser engine2 (e.g. chromium)
** accept the popup asking to join session

problem triggered: none can see that the other user is editing the page, saving, moving elsewhere, etc.

{img fileId="1397" thumb="box"}
tracker item
Clicking on the icon to stay uptodate about progress of my bug does not subscribe me to the item
but to the whole Tracker watches/notifications here on dev.t.o after submitting a bug.

Still an issue. Just did that and now I receive all bugs notifications. {sign user="luci" datetime="2014-06-20T15:35:08+00:00"}
tracker item
Clicking the control panels in the new Admin module does nothing
Tested on https://doc.tiki.org when you click the cog icon in the top bar and then one of the control panel icons in Chrome it does nothing (does not go to the control panel).
tracker item
closing tracker items make them appear in since_last_visit_new module as new items
When you close an old tracker item, it shows up again in the since_last_visit_new module as new tracker item.
This also seems to happen when you change the status to "pending".

It happens also in dev.tikiwiki.org to me (user xavi)
See this one for pending: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1946

And this one for closed:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=2124&trackerId=5&show=view

I logged in Jan 16th, and they appeared as new to me (user xavi, at least).

---

UPDATE: Still present in 12.x. {sign user="xavi" datetime="2013-11-17T09:52:11+00:00"}
tracker item
CODE plugin not parsed: instead the plugin syntax is shown as ignored (as if it wasn't enabled) in some cases
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.
tracker item
Codemirror does not respect off-bs-by-default in L&F & extra white space & false scroll
Codemirror does not respect off-bs-by-default in L&F & extra white space & false scroll

To reproduce for the time being, see
http://demo.tiki.org/12x/tiki-admin.php?page=look&cookietab=6

Codemirror set to "__Off (but switchable)__".

!!! Issue 1: Codemirror does not respect off-but switchable by-default in the admin panel Look & Feel

Custom css text area respects the codemirror default setting, but Custom HTML head does not (and neither they do custom bottom code nor custom javascript, which show codemirror on by default)

{img fileId="679"}

!!! Issue 2: Codemirror shows extra white space & false scroll

See custom code before the closing body tag

{img fileId="680"}

Notice the big space at the bottom, and the scrolling bar indicating that there is more content at the bottom (but it's not shown in the white space below).

When you scroll down a bit, you see that there some some more code indeed:

{img fileId="681"}

But that should be shown using all the available space in the textarea in the first instance.

----
Issue Still present on 06 February, 2014 15:02:50 CET- REV 49772. {sign user="xavi" datetime="2014-02-07T09:19:46+00:00"}
tracker item
Codemirror is not showing links to switch the highlighter even if prefs is correctly set
Codemirror is not showing links to switch the highlighter even if the preference is correctly set to do so.

Tried using firefox and chrome, with my user "xavi" (no admin rights) and "xavidp" (admin rights): same effect.

The preference is still set as
Configuration Wizard > Set up Text Area > Syntax highlighter (CodeMirror) Theme > "Off (but switchable)"
tracker item
Commas stripped out of wiki pages after editing/saving/previewing.
When editing a page on dev.tw.o, I will have proper grammar and punctuation, but after I save it, it appears that all of my commas "," are stripped out in the display. When I go to edit (or even a preview from an edit), the commas also disappear from the edit window.

While not really a high priority, bad, this will crash the app bug, I think it's pretty important for someone who typed in text with proper grammar to have that show up.

*** Also noticing in the tracker, that when I submitted this ticket I had selected something in the Data Type, Feature, and Version sections, but they didn't save, as well as Area and Related Project. ****
tracker item
Comment are not allowed but still posted (dev)
I just edited a trackerItem in the wishlist and save + comment.
Just after submitting I had a quick warning about "Comment are not allowed..."

Still the comment was posted.

https://dev.tiki.org/item7557-Itemlink-Trying-to-access-array-offset-on-value-of-type-null-notice
tracker item
Comments to tracker items can't be posted when codemirror is on
Reproduced in trunk and 16.x:

Inability to post a comment-Issue (due to highlighter)
Reproduced in trunk in:
* Login as admin in http://xavi-9794-3214.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

And in 16.x in:
http://xavi-9794-6132.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=5
u: admin
p: 12345

It's currently also affecting https://dev.tiki.org bug tracker comments. {sign user="xavi" datetime="2016-10-14T10:17:35+00:00"}

When codemirror highlighter is on (desired behavior in some setups, and the one produced by the new profile "Bug_Tracker_15" by default) when you click at submit your comment, you get: "__content is empty__", so you need to disable the highlighting before you can safely submit your comment.

This feature works as expected in Tiki15.
tracker item
Some wiki page SEF redirects broken on tiki.org
The page "comments" on tiki.org returns a 404 not found.

I have looked in the wiki pages, and we do in fact have a comments page, so something must be broken there. Not sure if this is a tiki bug, or bad data or what, but the error message (404) is really not very helpful.

https://tiki.org/comments -- is broken
https://tiki.org/tiki-index.php?page=comments -- works

https://tiki.org/changelog -- is broken
https://tiki.org/tiki-index.php?page=changelog --works

tracker item
Comments: Do not show Style/Sort/Threshold/Search unless enough comments
In comments (on wiki pages for example), there is a bar:

Style: Sort: Threshold: Search:


This seems like clutter when there are only a few comments.


Suggestion:
Only have this bar if number of comments is high enough that a comment pagination is needed (ex.: 10)


Related:
{wish id=937}
tracker item
Completely multilingual Tiki not just Wiki
I wish the wonderful multilingual features that the Wiki side of
TikiWiki has were available/applied consistently throughout the Tiki package.

So, it works really well to view wiki pages in your own languages,
translate into others and keep these in sync collaboratively.

While you stay in the Wiki side of things.

As soon as you leave to use files, forums and FAQs etc. etc. multilingual is patchy at best.

I'd like to be confident that whatever feature I enable, its possible
for all content in that feature to be truly multilingual.

tracker item
composer package installation fails from tiki web control panel
Composer packages can't be installed successfully through the web control panel in Tiki 23. Reproduced in dev.t.o, and also in two other servers.
In dev.t.o, the triangle icon shows up inndicating that the install failed.
In the other 2 servers, I saw a message indicating that composer.lock file was missing (on brand new tiki23 git installs, and therefore those packages could not be installed.

In all cases, running in the console (server side) the command -+composer update+- as root fixed the issue.

HTH
tracker item
Confirm action on CSRF warning causes warning to redisplay
I have "Require confirmation of an action if a possible CSRF is detected" set on tiki-admin.php?page=security. When I get the warning "Possible cross-site request forgery (CSRF, or "sea surfing") detected. Operation blocked.", and I click the "Click here to confirm your action" button, the same warning page redisplays instead of refreshing to the page where the admin action was made. This repeats as long as I keep clicking.

But the admin change does get made. If I input the admin page URL or go back in browser history to the admin page, I can see the change did take effect.

This is on my local wamp installation, so I'll need to make a show instance unless other people can reproduce this bug.
tracker item
Connection refused on d.t.o
While writing my feature request for a history on the article feature, I got several errors from d.t.o.:

{CODE(Colors="Tiki")}


Unable to communicate securely with peer: requested domain name does not match the server's certificate.. RC : 0

Error

Unable to connect to fd8f1a8b53674d9c8d46caffb484411d.eu-central-1.aws.cloud.es.io:9243 . Error #0: stream_socket_client(): unable to connect to fd8f1a8b53674d9c8d46caffb484411d.eu-central-1.aws.cloud.es.io:9243 (Connection refused)

Error

Contact the site administrator. The index needs rebuilding.

{CODE}
tracker item
Tiki.org crashes
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"}


tracker item
Content templates should be part of quicktags
It should be at the very least possible to add content templates where the cursor is, like ((quicktags)).
tracker item
Contrast and padding issue on "Tracker item actions" dropdown
See the attachment
tracker item
Convene date picker hard to use
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
tracker item
Convene improvement, attendees and confirmed people
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).

tracker item
Convene plugin missplaces the counts in columns after the winning choice
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.
tracker item
PluginConvene: avoid duplicating content under some circumstances
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&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
tracker item
convene plugin: prevent the user to add default info (Add or Add user string) instead of the real username or a different string
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
tracker item
Show PHP error messages