Category: Error

Imagine you have 2 wiki pages. Page A and Page B, and Page B is assigned to category X.
In page A you use the CATEGORY plugin to list all objects from category X, and thus, it lists the "Page B" name, which links to it.

Then you rename Page B to Page C. In page A, the plugin category still shows name and link to "Page B", and not the updated name and link: "Page C".

This bug has been here for almost a year, and it is present in 1.9 and 1.10
---
bug still alive on tiki 2.1, and confirmed also after deleting pages, and clearing tiki caches.

It can be tested on (production) site for registered users at:
http://uniwiki.sima.ourproject.org

Using workspaces, when changing workspace names after creation, editing the category to rename its elements works OK for wiki pages and file galleries, but perspectives' names are not changed.
Seems "profile_symbols" & "objects" tables are not updated.

If a (UserPage) Page does not exist it is rendered as normal Text followed by "?" (red),
the problem occurs if a "." (dot) is in the link name

This:
*((UserPagmax.mustermann|Max Mustermann))

is rendered as:
Max Mustermann?.mustermann" class="wiki wikinew">?

Happens on BRANCH-1-9 when Use WikiWords is activated

When I login to my site, I get multiple warning notices printed stating (NOTE: Only when logged in):

Notice: Only variable references should be returned by reference in /***/public_html/lib/adodb/adodb.inc.php on line 2797

(where *** is my directory path)

These errors started when upgrading from 1.8.5 (i think), to 1.9.1 and are still there when upgrading to 1.9.2.

I made sure the /lib/ directory was entirely replaced when upgrading.

PHP version is 4.4.1 MySQL 4.1.13-standard. phpinfo() output here: http://odejava.org/phpinfo.php

There are several places in Tiki code where target="_blank" is used.


"Much to the chagrin of Web designers everywhere, the HTML 4.0 Strict and XHTML 1.0 Strict recommendations of the W3C no longer include the target attribute of the <a> tag. The Transitional versions of the specifications still include it, but by definition, these specs are on the way out.

Whatever your personal feelings on the practice, the most common application for this attribute -- opening a link in a new browser window with target="_blank" -- is still useful on today's Internet. So if the standards say we shouldn't use it, how should we go about creating new-window links, while following the latest Web standards?"
http://www.sitepoint.com/article/standards-compliant-world

Using trunk as of r53746 from 2015-2-3.
When clicking "Reports" and then select "Type: Logs" and the just click preview nothing happens except the hourglass.

Reason is: request to tiki-ajax_services.php responds with internal server error 500.

Detail from Debug Console in Chrome
{CODE()}
Request URL:xxx.xxx.xxx.xxx/tiki-ajax_services.php
Request Method:POST
Status Code:500 Internal Server Error
Form Data:
controller:report
action:preview
value[0][name]:logs
value[0][value]:category
value[1][name]:logs_action
value[1][value]:
value[2][name]:logs_start
value[2][value]:
value[3][name]:logs_end
value[3][value]:
value[4][name]:logs_fields[]
value[4][value]:actionId
value[5][name]:logs_fields[]
value[5][value]:action
value[6][name]:logs_fields[]
value[6][value]:lastModif
value[7][name]:logs_fields[]
value[7][value]:object
value[8][name]:logs_fields[]
value[8][value]:objectType
value[9][name]:logs_fields[]
value[9][value]:user
value[10][name]:logs_fields[]
value[10][value]:ip
value[11][name]:logs_fields[]
value[11][value]:comment
value[12][name]:logs_fields[]
value[12][value]:categId
value[13][name]:logs_fields[]
value[13][value]:client
value[14][name]:logs_grouping
value[14][value]:
value[15][name]:logs_sort
value[15][value]:
value[16][name]:logs_limit
value[16][value]:
type:Logs
{CODE}

Excerpt from apache error.log:
{CODE()}
[Wed Feb 04 00:02:24.195245 2015] [:error] [pid 16574] [client x.x.x.x.:50339] PHP Fatal error: Call to undefined method TikiSheet::setSize() in /var/www/html/tiki/lib/sheet/grid.php on line 1153
{CODE}

CREATE TABLE tiki_articles(

articleId int( 8 ) NOT NULL AUTO_INCREMENT ,
.
.
reads int( 14 ) default NULL ,
.
.
KEY reads( reads ) ,
KEY author( author( 32 ) ) ,
FULLTEXT KEY ft( title, heading, body )
) TYPE = MYISAM AUTO_INCREMENT =1

cause

#1064 - 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 'reads int(14) default NULL,
votes int(8) default NULL,
points int(14) defaul' at line 28

I have the following problem:
- as anonymous i load home page with two panels (modules) on the left and right (right one is logon box)
- I log in (both panels correctly diplayed still)
- I log out and right panel is not longer displayed on home page
I need to refresh page to see it again

I use Display Always for both modules in Look and Feel/general layout.
I use tikipedia theme.

Do u have any ideas why it might happen?

Although the RFC (for example, [http://www.robotstxt.org/wc/norobots-rfc.html]) doesn't explicitly require a leading slash (/) before the page name, I have found that, as of late Oct, 2005, many 'bots, including Googlebots, have started requiring them.

For example, before the change,

Disallow: tiki-pagehistory.php

would prevent well-behaved 'bots from trying to index tiki-pagehistory.php. However, after the change, I had to have:

Disallow: /tiki-pagehistory.php

in robots.txt, or else all my page history would be indexed! I verified this using my server log, and also by doing google searches against my site for phrases that only appeared in page history. I have every reason to believe this is a problem for all other TikiWiki-based sites.

Others have noticed this. There is discussion in the forums at:
* [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=13666&forumId=4|Googlebot ignoring robots.txt] -- includes a __graph of my bandwidth usage before and after__.
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=12342|Adding <meta name="robots" content="noindex,nofollow"> to History pages]
* [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=4&comments_parentId=15004|Yahoo search indexes Print pages instead of Read pages]

BRANCH-1-9 is not working
http://themes.tikiwiki.org/tiki-index.php?page=rssaggregator

HEAD is maybe working.

If Tikiwiki 1.9.4 or 1.9.5 is installed in the wwwroot of a "real" subdomain that resides on its own (win)server (not an alias to a subfolder under the main-domain), then rsslib.php inserts an additional backslash after the domain-name.

Links of rss-feed then look like: ~~#FF0000: sub.domain.com\/tiki... ~~ and RSS feed gets obviously broken.

As a quick-fix for my site I resolved this in the file rsslib.php by deleting the string:
~~#FF0000: ~np~ .dirname( $urlarray["path"] ) ~/np~ ~~
in the variables:
~~#FF0000: $home, $img, $read, $cssStyleSheet, and $xslStyleSheet ~~
in order to get RSS-2.0 to work again.

Unfortunately I'm not any more a coder and don't know php good enough to fix this for everybody and contribute in the CVS (I did no more coding since turbo-pascal under DOS in the mid 90's, but at least still can read a little bit :-)

all the best,
Felix

PS: Thanks everybody here for this great software!!!

RSS feed for Articles in tiki.org produces WSOD. Reproduced here:
https://tiki.org/tiki-articles_rss.php?ver=5

or
https://tiki.org/tiki-articles_rss.php?ver=5&css=y
(as indicated here https://profiles.tiki.org/RSS+Handler which used to be a valid url afair)

or
https://tiki.org/tiki-articles_rss.php?ver=2

However, it works well in themes.t.o:
https://themes.tiki.org/tiki-articles_rss.php?ver=5

I wanted to add that articles rss feed to the Admin UI backend rss module ( loaded from here https://profiles.tiki.org/Unified_Admin_Backend_Default_Dashboard_1 ), but there is no point if it triggers some error 500 or WSOD by any other reason.

Any tip anyone on how to solve? @ohertel maybe?

I setup a demo to debug the rss articles duplication seen at https://tiki.org/Community

During the first 40mn I had the following message: "You do not have permission to view this section". I create a new article, refreshed the external feed (not willing to wait 30mn), refreshed caches even deleted temp/caches/ files.

And I was Admin... :)

Nothing helped and I went to other task.

Back after 40mn+ It displays the articles properly.

# Seems the refresh at once is not working at /tiki-admin_rssmodules.php
# The error message is misleading

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

{syntax type="tiki" editor="plain"}
I've recycled this old bug since whilst the original problem has been 'partually' solved it looks like the problem manifests itself the other way around now - ie oddly wysiwyg pages are OK ie they do not show HTML tags BUT wiki pages edited with the standard wiki editor are now showing HTML tags

For Tiki12 the problem is showing with BOTh type of wiki page?? So ideally whatever is fixed in Tiki15 should be backported to Tiki12 as this will be supported for a long time



===old entry text===

If RSS is switched on for wiki pages then the RSS feed page shows wysiwyg edited pages with html tags

Not sure if this a regression or a bug that has always been there but it is present in 9.x and the latest 12.x branch as well as 13.x and trunk

A show instance in 12.x has been produced which shows this bug

Substantially fixed by r54336 in Tiki14 - but not 100% there yet

Updated from 5.1 to 7.0, now RSS Feeds not working. Also not working with 7.1 RC1.
Chrome browser reports HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request.
No page displaying in firefox. Tested on Blogs and articles, both have same error. PHP-XML is installed (report of this error in community section discussed PHP-XML as being the solution)

This is RSS feed
http://www.bookkeepersireland.com/tikiwiki/tiki-blogs_rss.php?ver=2

Attempting to View the RSS feed of a page that is running 1.9.0 in a subdirectory results in the error:

The XML page cannot be displayed



It seems to me as though TikiWiki has a number of inconsitencies with the way in which it manages paths, which cause some problems for sites running in subdirectories, the newsletter subscribe url for example uses parse_url to get the path (eg /tikiwiki/) then prepends the httpprefix, whereas the RSS module just appends httpprefix, so in other words these modules expect different thing from the httpprefix function the RSS module want http://mydomain.net/tikiwiki/ whereas the newsletter module just wants http://mydomain.net

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



Good:
http://tikiwiki.org/tiki-wiki_rss.php?ver=2
http://tikiwiki.org/tiki-blogs_rss.php?ver=2
http://tikiwiki.org/tiki-articles_rss.php?ver=2
http://tikiwiki.org/tiki-image_galleries_rss.php?ver=2
http://tikiwiki.org/tiki-file_galleries_rss.php?ver=2
http://tikiwiki.org/tiki-forums_rss.php?ver=2
http://tikiwiki.org/tiki-directories_rss.php?ver=2
maps RSS feeds are OK

Using 1.9.cvs

RSS of an individual tracker, such as [http://www.moviments.net/valldelcorb/tiki-tracker_rss.php?trackerId=2] , produces

^
" Tiki RSS Feed Error Message: Permission denied to access this section"^ (translated from another laguage)

I'm doing that even as site user admin.

What's wrong?

The tick in admin > rss is on for all lines (including individual trackers)

I have the latest files for RSS, and the RSS feed is malformed. I fails to load properly in Firefox, and loads in other readers (e.g. Yahoo) but without formatting.

RSS Validator says one error is that there is an extra line before the first <xml... line, which is causing it to be parsed as HTML and not as XML for RSS. See here for an example; http://www.casesofinterest.com/tiki/tiki-wiki_rss.1.43.2.1.php?ver=2


I have spent a lot of time tracing the calls and I can't figure out why it works fine for blogs, but not for wikis as the code is similar. I hope someone who knows more than I can fix this.

rss icons are not properly displayed when switching language on tiki.org.

Go to http://tiki.org/tiki-index.php check at the bottom (above contributors) you'll see the RSS icons. Change language, let say french, it show now a broken image.

{syntax type="tiki" editor="plain"}
It seems that if links are in the <description> tag of an RSS2 xml. With Firefox (or equiv) see http://scourgeweb.org/svnlogs/log2-rss.xml for an example of how it should render.

It does not render correctly in the RSS user module. The link URLS are broken and don't include the <a href="domain.tld/path"> only the link description of the path is displayed.

The RSS feeds seem to have no permission checking. The feeds should only include information that is available to Anonymous.

Clicking "Save" icon in toolbar doesn't work.

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)