Category: Release60

"Gzip output" (feature_obzip) is defective in two different tikis (in 2 different servers).... proposals/6x and trunk

Once enabled, when I attempt to visit a few pages as anonymous, for which I should see the "Error, your are not logged in. Go to Log in Page" message, I see instead a message from firefox saying that there is an error in the enconding of the content (attempting to use a compression method not valid or that it doesn't work in this application):

{QUOTE()}
Error de codificació del contingut

No ha pogut mostrar-se la pàgina que esteu intentant visualitzar perquè utilitza una forma de compressió no vàlida o que no funciona en aquesta aplicació.

* Poseu-vos en contacte amb els propietaris del lloc per a informar-los del problema.
{QUOTE}

Once I disable the gzip output, tiki behaves normally.
---
Moreover, this issue might have been the reason why the new spreadsheet features being developed in trunk by robertplummer were failing (Chrome just says that the server is temporarily unavailable) recently in a test we were doing in the same server.

And that might be the (potential) responsible for the issues with sending newsletters in prposals/6x (just before the release of tiki 6.2).

I have confirmed this bug (2184) in Tiki 6.3 using Chrome and IE7/8.

I am not a javascript guru so this may not be the most eloquent solution, but it works.

To fix, replace the icntoggle function (line 693) in tiki-js.js with the following:

{syntax type="tiki" editor="plain"}
When the PluginButton plugin is included in a User Module and that User Module is used on the wiki, it will lock down the wiki in "Internal Error 500" mode. So no matter what page you visit, you will get "500 internal error".

Tested on:
TikiWiki v. 6.1 on IIS 7.5

It would be nice to be able to select a perspective depending on the current content's categories and their respective jails.

I have made a hack that achieves this, but it would be nice to have it implemented as a feature. I described my hack and included the code here:

https://dev.tiki.org/lookup+perspective+according+to+category+IDs

{syntax type="tiki" editor="plain"}
In these last month of june or july 2011, some regression seems to have been introduced in proposals/6x, which produces that maketoc create the output twice, when sending a newsletter from a wiki page template.

{syntax type="tiki" editor="plain"}
Does the "Users Information Tracker Fields Asked at Registration Time" work for someone in 6.1? it used to work in 5.x. not pretty.

This feature was not particularly important if the trackers with registration="y" would work nicely. Read more here.
[http://irc.tiki.org/irclogger_log/tikiwiki?date=2011-01-08,Sat&sel=52#l48]

After sending a structure between 2 tiki sites (using the send pages features between tikis, xmlrpc, etc), once I clicked on the button to accept the received structure in the target tiki site, I got this error:

{CODE()}
Column 'page_alias' cannot be null

The query was:
insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`, `structure_id`) values(?,?,?,?,?)

Values:

0
70
1
0

The built query was likely:
insert into `tiki_structures`(`parent_id`,`page_id`,`page_alias`,`pos`, `structure_id`) values('0','70',NULL,'1','0')
{CODE}

Both tiki sites are running recent proposals_6x

The url on the target tiki was:
tiki-received_pages.php?offset=0&sort_mode=receivedDate_desc&accept=1

Tracker item history seems to be unreliable: it works for me on some 6x sites but I haven't been able to make it work in a local 6x or proposals_6x .

# I create a tracker item
# I edit the tracker item again, changing some fields (1 text area, and 2 text fields ) and save changes
# refresh the tiki-tracker_view_history.php?itemId=1 page but I see nothing there

((GroupMail)) is not working for me any more since I updated a site to 6.x from 4.x
In 4.x it was working me (I created most of the documentation in doc:((doc:Groupmail))

Maybe that's because Webmail is not working either...?

What I did:
* installed a new tiki proposals/6x tiki site in localhost
* added ajax_xajax feature to the groupmail profile (it was missing)
* applied Groupmail profile
* followed instructions to setup a new group (web)mail account
* the module groupmail is spinning all the time, and no messages are shown
* I've double checked that the user and pass info for that email account are all right

I also applied that profile on a remote server (a production site) and no luck either. No email is fetched.
I checked the webemail account (by means of other webmail software) and I confirm that it has plenty of read email, and 2 new messages pending to be read.
---
Update:
Weird, after I tried to unsuccessfully delete that account in the remote (production) server, it seems that webmail started to work!

:-/ Well, it looks boggy to me, or at least, for sure it's been unrealiable behavior!

At elast, for sure tehre is a bug at removing a webmail account: which is not removed (even if you ckick again at the confirmation step, the account is still there)

To allow for greater styling, it would be great to allow HTML coding and/or wiki syntax in the __Site Title__ and __Subtitle__ fields on Admin: L&F.

Tiki Articles do not support the FOOTNOTEAREA plugin. In Tiki 5 and 6 I used:
{CODE()}
foo bar {FOOTNOTE()}http://www.foo.bar{FOOTNOTE}
---
{FOOTNOTEAREA() /}
{CODE}

Tiki renders the footnote (superscript) properly, but does not include a Footnote area at the bottom of the article.

Tested & confirmed on info.tw.o using Tiki 5 and 6

Using tw.o forums and 2.0 (afaik):

You add a screenshot attachment to a reply in a forum post, and if you click on "preview" first, (as you would do on wiki pages), the image is lost (no tag is inserted on the forum post to help you link the attachment).

However, if you do the same attachment on a post, and click to post it (without previewing it first), the attachment link is shown.

Example at tw.o forums where it recently happened:
[http://tikiwiki.org/tiki-view_forum_thread.php?forumId=4&comments_parentId=29608&thread_sort_mode=commentDate_desc&was_queued=n]

---
according to comment added to this bug report, this issue is still present in branch Tiki5 still (so probably also in trunk)
---
Unbelievable, bug still present in forum posts in 12.x since 1.x! (with forum replies, there is warning, at least, but not yet with brand new posts in the forum and attachment is lost indeed) {sign user="xavi" datetime="2013-11-22T09:45:52+00:00"}

Reproduced here:
http://xavi-9794-1986.show.tikiwiki.org/tiki-view_forum.php?forumId=1
u: admin
p: 12345

{syntax type="tiki" editor="plain"}
Rule activated by dates
Rule active from
Rule active until
Upgraded tiki: Shows years 1969 till 2010
Clean install: Only gives the year 2010 to chose from
This year is almost over so whould be nice to have some later years to chose from.

on the test environment i can access tiki-calendar.php without a problem but as soon as i want to create a calendar and then access it on the live server i only get a blank page.

wether it is an already populated tiki or a clean install (wether using a completely new db or telling the tiki installer to clear the previous db and create a new one, wether using our theme or using the standard theme) i always get a blank page.

are there any special options in php/mysql/apache the calendar needs which i need to change?

the live server is a suse linux with php 5.3.3 and mysql 5.1.46
the local server is some xampp on a windows machine

Edit:
tested it with Tiki 6.3, 6.4 and 7.1

While it is a blank page in Firefox, Google Chrome says it is a 500 server error

Edit2:
Apache Error Log says:
PHP Fatal error: Call to undefined function cal_days_in_month() in .../lib/tikidate-php5.php on line 298, referrer http//...

When creating or editing a blog, the __Display Options__ tab includes two fields:
* Blog heading
* Blog post heading

There is also a __Heading Preview__ button on the tab.

1. The __Heading Preview__ does not show any sort of preview -- it simply reloads the page.

2. When ''editing'' a blog, there is a second __Heading Preview__ button, also which does nothing.

If you are in the doc.tiki.org side and edit a page, try to do a preview.

You won't be able to.

I tried in other universes and the preview option works fine.

I have two site that I've upgraded from Tiki 5.3 to Tiki 6 and on both sites, clear cache function is no longer working since the upgrade. When I open the 'Exterminator of cached content' window, thit indicates that there are no cached files. I have confirmed via FTP that there are many cached files. Also, when I select 'clear cache', there is no effect on the cached files.

When creating (editing) some event and change start date to the value that is newer than end date, user must change end date manually

{syntax type="tiki" editor="plain"}
Fact : when you submit "preview" for a new event, a great part of data are lost, there is no real preview, and when you return to creation most of optional data are lost.

Too many things don't function : the job is not ended.

{syntax type="tiki" editor="plain"}
The fact (analysis result) : view from the popup od calendar module has no data set up

Details :
When you actions the into modules calendar the event from a date, you get the popup (if prefs) which shows the events of the day, then :

1- there is no choice for an event if an alone or several
2- the data of the event are not set up
3- the action button "view" shows a "pseudo empty event" the lonely data are the default value for a new event...

The function is not completely implemented. Job not ended. Functionality not operational.

It had no time to look at 6.0.

{syntax type="tiki" editor="plain"}
Please help since we have invested much time and effort in this project, believing Tiki could filter rightly wiki pages based on perms, and since I cannot find a workaround.

When not logged in, Some wiki pages are shown, and Some others Not, while they all have exactly the same set up. They all have been categorized only in "Public Content" category which is set to Show wikis to Anonymous users, while Global perms are set to not show them to anonymous.

At this moment we have two identical wiki pages as setup is concerned:
1) http://mi.solcentral.org/tiki-index.php?page=La+Funci%C3%B3n+Esencial+y+El+Prop%C3%B3sito+de+Vida
which doesn´t show to Anonymous users (and should do it)

and

2) http://mi.solcentral.org/tiki-index.php?page=Sobre+el+Sitio+SolCentral-org
which shows well.
Note that at the botton of this page, in the listing of pages related to the category "Contenido Público" (which is the translation of "Public content"), the page "The Esential Function And Life's Purpose" (wich is the translation of "La Función Esencial y El Propósito de Vida") that is the page 1)... Then if you click on it, it will not show presenting you with the login invitation, allthough is shown in the list as categorized "Public Content".

Other extraneous behavior is that when when you use the Plugin Toc to show the structure, only shows Some wikis on some structures, and on some other structures doesn´t show any wiki.
I have used this:~np~{toc structId="26" order=asc shownum=1 type=fancy }~/np~ in the wiki:
http://mi.solcentral.org/tiki-index.php?page=e-Books%20Index

Actual estate of config is:

For anonymous:

If Perms on wiki: "La Función Esencial y El Propósito de Vida"

La Función Esencial y El Propósito de Vida Anonymous tiki_p_view Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_view_backlink Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_watch_structure Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_wiki_view_attachments Categoría: Public Content
La Función Esencial y El Propósito de Vida Anonymous tiki_p_wiki_view_comments Categoría: Public Content

Category Perms of "Public Content" are

for anonymous group perms that are ON:

Can view wiki attachments and download (tiki_p_wiki_view_attachments)
Can view page/pages (tiki_p_view)
View page backlinks (tiki_p_view_backlink)

Global Perms are:

on Wiki:

Can view wiki attachments and download (tiki_p_wiki_view_attachments) is ON for Anonymous
Can view page/pages (tiki_p_view) is OFF for Anonymous
View page backlinks (tiki_p_view_backlink) is ON for Anonymous


Fixes tried:

Have tried the opposite: allowing everything to be shown to Anonymous, and then restrict on pages that should be hidden with a "invisible" category with perms tiki_p_view OFF for anonymous group.

And it didn´t work since - again - for Some wikis worked, and for some others not. Even if they are identical.


Using:
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

When using tiki-admin_transitions.php.

If I add a Transition, then tiki will not let me modify it (by Edit) since every icon (i e: Edit) will delete the Transition. Even If I click in "Guards" data (wich appears as a "0").

Also the yellow "Key" icon doesn´t turn green as is supposed to, after setting perms.

May be other anomalies.

Please help

Using Tiki 6.0 fresh Install.

New Edit:

Since I didn´t find any reference on how to use it, I´m exploring it myself.

What I did before I was stopped by this error is:

1. I Set up some Categories
2. Go to the tiki-admin_transitions.php. The Subset Tab is on and it shows me two options: 1. Category 2. Group
3. Click on Category, so it show the availabre Categories
4. Choose two categories, then click Select button. It reloads the page.
5. Click on New/Edit tab
6. Write a label: "New"
7. Chosse From and To options
8. Click SAVE. It goes to the List of Transitions
9. If I click on Edit icon, it deletes de transition and goes to the New/Edit tab, but empty... nothing selected or filled.
If I click the Guards (number 0) it does the same

If I change to the List, the transitios has dessapeared from it.

There should be a setting to allow comments to be editable, by user and/or admin.

{syntax type="tiki" editor="plain"}
The email sent to the admin with the form that was filled by an anonymous user, it shows the email address of the user but only the part that is before de "@" sign.



Using
Tiki 6.2

and I formerly encountered this error in
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.