Category: Error

This is a newly introduced problem in BRANCH-1-9. tiki_p_topic_read should not be necessary because it should only be to assign permission to a specific topic.

Many people upgrading from 1.8.x to BRANCH-1-9 have reported that their articles disappear.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1181297&group_id=64258&atid=506846|tiki_p_topic_read needs to be given to groups in addition to tiki_p_read_article]

If user watches activated (for all), any user is able to "watch" a tracker, so that he/she will receive an e-mail message with all the information from the tracker item, even if some field were declared as "hidden"... (sensitive info).

I already reported this at sf.net for 1.8 trackers. And I seem to see the same problem nowadays with Tiki 1.9....
This should be fixed for privacy of sensitive information collected through Trackers/forms

Further to my report [https://dev.tiki.org/item7001-tiki-stats-php-Day-with-fewest-pageview-duplicates|item7001-tiki-stats-php-Day-with-fewest-pageview-duplicates] that the behaviour of tiki-stats.php has changed between v15 and v18 with regard to number of dates reported against "Days with the fewest pageviews", we are continuing to see that list grow (including more duplicates) since we upgraded from 15.5 to 18.3.

(I've attached five images showing the situation, but can't work out how to include them within this text. The choose or upload image feature on this edit field seems to lack an upload and I have no idea where to find images that I've directly attached to this page)

The first screen shot shows 31 Jan, 02 Feb (twice) and 03 Feb. has having only 1 pageview. We know our wiki was used on those dates (from notifier e-mails for example), so these dates are being included in error.

Also the "Most viewed objects in period" for single day ranges (eg 01 Feb 2019 to 02Feb 2019) shoes our home page alone was hit 200 plus times. Again screen shots attached.

Whilst I would be happy to create a show instance for you, I'm not sure how to do that practically with this type of issue.

On a fresh install of BRANCH-1-9 from July 31, 2007.

To reproduce:
Log in as admin. Enable articles. Click on the word "articles" in the menu immediately to the right of the file folder icon. No page is shown. Click on "Articles Home". No page is shown. When you hover over the item, the URL in the bottom of the browser seems to be correct. The file exists. Apache does not show any errors

the page tiki-admin_categories.php page don't display
at all. The internet explorer page 'The page connot be
displayed' is shown.
When I switch off the gzip compression of output in the
general admin setting, the tiki-admin_categories.php
displays an empty page (modules and menu are
present but not the core page).
What is most interesting is that is broken on a
production linux server running PHP Version 4.3.0 and
works on wamp running PHP5 under windows... could
someone help me?

reported on ((tw:ReleaseProcess19)).

{syntax type="tiki" editor="plain"}
1- Turn on multilingual
2- restrict to 3 languages
3- go to compile one of the three

Notice crazy stats :-)

When attempting to apply a change to the "look and feel" section of Tiki admin, the following error displays:
__Sea Surfing (CSRF) detected. Operation blocked.__

Can someone explain what this means, and how I can recover from it?

UPDATE:
After many attempts to work around it, I could not resolve the problem, so I re-installed TikiWiki 4.3.
No more Sea Surfing seen.

From tiki-admin.php?page=cms (the articles admin page) when you gof rom Submissions checkbox = F to T the system doesn't automatically rebuild the Articles Menu to include the Submit Article command line.

Registered users then have no way of submiting an article because that command doesn't show up on thier menu.

tiki-admin.php?page=wiki left column eats up the whole page with Mozilla


recently introduced in BRANCH-1-9

https://tiki.org/forumthread51778

{img fileId="835"}

On a clean install, I make a backup via tiki-backup.php All seems well.

However, when I try to restore:
{img src=images/code.png}%%% {CODE()}

Warning: mysql error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '��I�!��m3.�ָb���J�:A�޷7�Y��|���C��O�' at line 1 in query:

��I�!��m3.�ָb���J�:A�޷7�Y��|���C��O� in lib/tikidblib.php on line 134
{CODE}

It seems to be caused by the special characters in the encryption of the .sql file


Broken site shows:

{img src=images/code.png}%%% {CODE()}
Notice: this site is currently unavailable.

Please try again later or contact the admin.
{CODE}

Hi,

First a warning: I am new here... and new to linux...

I installed tikiwiki and while configuring the categories and user rights I got the Message

Template Error: setRoot: . is not a directory.

It happend calling the page

tiki-browse_categories.php

and it happens with all users I configured, even the adminuser.

Any ideas?

Thanks a lot,

Christoph

If you access whatever image gallery, you will see that is not possible to view the thumbnails and images. Have a look.

This function is so important! is the unique motive that image gallery exists..

http://tikiwiki.org/tiki-browse_gallery.php?galleryId=18

{THUMB(id=39)}{THUMB}

see the effect here:
http://amette.ground.cz/shoots/index.php?shoot=2005-10-13-05-43

notice the dates like "03/31 - 07/31"

This was confirmed on two PHP5-installations

for exemple:
http://dev.tikiwiki.org/tiki-categpermissions.php?categId=2

Steps to recreate in firefox:

1. Initialize site with a new database.
2. Lock setup and login as admin.
3. Click on pretty widgets and change theme.
4. Close Firefox browser. Browser's history cache is automatically flushed.
5. Attempt to log into tikiwiki as admin/admin.

Expected behavior appears to be a page where you are prompted to change the admin password. (Nice!) Actual behavior is blank page with "No input file specified" error. Error is always present

Steps to recreate in IE7.

1. visit tikiwiki url.
2. log in as admin/admin
3. IE7 generate "page cannot be found error"

Calling tiki-check.php (via the drop down menu of control panels) causes my rented webspace to crash. Literally. First, a 500 is thrown (internal server error), and afterwards the entire webspace goes offline for a couple of minutes! Eventually it does recover, but I have no idea by what mechanism of my ISP this happens. Probably a restart of the (assumed) Docker instance.

This can possibly lead to disturbing the online presence of other customers of the same ISP, depending on the grade of encapsulation of the ISP!

Something dangerous is happening inside tiki-check.php. This must never happen, because this spells out that there is something that can lead to a DOS, either involunaterily by co-admins not aware of the danger of the function, or even by attackers who somehow manage to do whatever tiki-check.php does when this happens. Possibly even by attacking other Tikis hosted by the same ISP, if the ISPs encapsulation is weak...

I therefore propose that tiki-check.php be split up into segments that can be called individually (this eases finding the culprit) and then to have an admin configurable set of functions, so admins can disable dangerous functions.

In Directory, when you go to validate sites and check sites for deleting, the sites were not deleted after submitting the form.

I'm not sure, if the bug is in tiki-directory_validate.tpl or in it's php or lib files.

{syntax type="tiki" editor="plain"}
I'm trying to tame articles section and encountered strange problem. My tiki-edit_article.php looks like on this snapshot: http://img716.yfrog.com/i/tikieditarticle.png/ (external link) - so, no pretty formatted forms and - how bad! - no Preview or Save buttons :-(

Other edit pages (e.g. wiki) look fine - only this one is other. I played with permissions, plugins and features - no luck.

According to hints from forum I cleared cache. I'm using The News theme (unchanged). Also CSS and TPL files was untouched. I downloaded TW installation files once again and replaced "suspicious" files (tiki-edit_article.php and .tpl). Problem still persists. I checked many browsers: Firefox, Opera, Chromium, Konqueror and Internet Explorer - no difference.

I checked with LTS version - it works good. Trunk - not working. 4.1 from daily buid - not working.

I checked Opera's error console:

CSS - http://localhost/tiki/tiki-edit_article.php (external link)
HTML style attribute
Declaration syntax error
Line 1:
display:;
-----^

This message is repeated 8 times.

In XHTML source (i.e. viewed in Chromium) tiki-edit_article.php hasn't DOCTYPE declaration and bare HTML tag - no xmlns, no lang etc. - maybe this is a reason? I attach two screenshots from Chromium error console: first one is from tiki-edit_article.php, second one - from tiki-editpage.php. If you look into XHTML code, you'll see the difference.

http://img651.imageshack.us/img651/7734/tikieditarticle1.png
http://img685.imageshack.us/img685/4858/tikieditarticle2.png

Can anybode help me or check his/her installation? Maybe my TW is broken? I'm using openSUSE 11.2 x86_64.

It takes over 30 seconds to save an article using tiki-article.php. No one else can access the server while this is stalled.

To verify and determine why. Probably some bad db locking.

{syntax type="tiki" editor="plain"}
When on "tiki-admin.php?page=look" you have to enable "View Templates" and "edit Templates" to use one of the both features.
Then, if you choose to edit or view a template, tiki-edit_templates.php
is called, loads forever with high Apache load, and finally showing a blank page.

Bug for a site (e.g. drecerca) on a multitiki site (e.g. moviments.net). Using a 1.9.7cvs from a month ago (early may07, I guess)

Attempting to edit the tiki-top_bar.tpl smarty template from the web interface: http://www.moviments.net/drecerca/tiki-edit_templates.php

I got this message, when clicking on the "__save only in the theme: drecerca__" button:

{CODE()}
Warning: mkdir(templates//drecerca/styles/drecerca) [function.mkdir]: No such file or directory in /home/httpd/tiki19/tiki-edit_templates.php on line 61

You do not have permission to write the template: templates//drecerca/styles/drecerca/tiki-top_bar.tpl
{CODE}

And right place where it should attempt to save the file is:

^
templates/styles/drecerca/tiki-top_bar.tpl
^

Is this a configuration problem or just a bug?
If it's a configuration problem, the should be a tip or warning somewhere explaining how to avoid this error...

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)