Category: 6.x

We have links to external pages using file:// because the pages are internal to our system. This type of link worked in version 3.0 and now doesn't. The links work within a browser so we know it isn't an address error. This type of link uses the protocol (other) within the WYSIWIG editor.

The calendar in TW6.7 does not render correctly in IE8. It shows two months worth of dates instead of the expected single month when in month view. Week view and day view render correctly in IE8, though.

Also, amazingly, the same install of TW6.7 shows the dates of the month of March when viewed with IE8 and April (the current month) when viewed in IE9 and other major standards compliant browsers.

Problem:
Some changes in Tiki code (especially the parser) between versions cause slight changes of behavior. Devs have no comprehensive way to test the result of a change on a large data set.

We have a large data set with all *.tiki.org sites.

Similar to ((tw:Pre-Dogfood servers)), we could have a script which checks the HTML output for all wiki pages for a given version, and compare this to another version.

And thus, we can check if this is a desired behavior.

The HTML entities change in Tiki9 would be a great 1st test of this. It would have been nice to have it for UTF-8 changes in Tiki5 as well...

This should be done as part of the script for ((tw:Pre-Dogfood servers)) so we have daily reports on issues. (and we know that it's the same data)

In IE7 and IE9, when we add an event to a calendar the month calendar gadget does not open up. It only shows ...

This started after upgrading to version 6.6. We are currently using Chrome as a workaround.

Have just upgraded from 4.3 to 6.7 and find Plugin Showpages is no longer producing output.

Looked at [http://doc.tiki.org/PluginShowpages] for inspiration and notice that the examples there do not seem to be functioning.

Suspect plugin Listpages now has --equivalent-- similar functionality. --but we have at least one other broken plugin (WantedPages), so want to ask if there is a wider issue here, please?--

Was using ~np~{SHOWPAGES(find=>FAQ_ display=>desc) /}~/np~ but I don't see how to simply display the page description with ListPages.

--Also is there an easy way to find all the pages within our wiki where ShowPages has been used so I can change them to Listpages??--

Thanks,

Martin

Updated 08May12. The issue with WantedPages is now felt to be a separate issue and I'll open a new ticket for that.

Have also now found new to v6 Mass Search & Replace tool within Wiki Admin which is great.

{syntax type="tiki" editor="plain"}
When Gzip output is enabled under Admin | Spped & Performance, it is not possible to send out newsletters greater than 100 in number, if at all. When attempting to send newsletters, it shows a 'Cannot load page' message in the frame where the log of email addresses normally appears.

Since upgrading from v4.3 to v6.7 the WantedPages plugin is no longer functioning for us.

The documentation for WantedPages at [http://doc.tiki.org/PluginWantedPages] has a note "Best Results - for best results, enable the WikiWordsPlugin, I found that if this plugin is not enabled, several desired page links will be recorded in the 'tiki_links' table, but not displayed in the list result of this plugin."

I've tested our site and did see good output from WantedPages when configuration option WikiWords at Admin -> Wiki -> Features was temporarily enabled.

We did not have this option enabled on our v4.3 wiki and Wanted Pages worked. Because our Genealogy One Name Study site [http://thereevesproject.org/data/HomePage_Wiki] contains community contributed transcripts from old wills, deeds etc, enabling WikiWords is not a valid option for us since these old documents often contain CaMelCase words which we want accurately transcribed and we would not want automatically generated wiki links created for those words.

This may also be related to an existing issue [http://dev.tiki.org/item2675] but I don't think its exactly the same.

Shouldn't the ability to produce a full and valid list of Wanted Pages be independent of other wiki features being enabled or disabled?

Thanks in anticipation,

Martin

Depending on the width of a user's browser window, it is possible for a button to wrap to the next line when the user hovers on the button. This makes clicking the button challenging.

We did not see this behaviour with v4.3, only since upgrading to v6.7

In the source of a wiki page (current or prior version) double quote marks appear as a single character "

However, when viewing the same source in version compare mode, those same double quote marks are shown as the html & quot ; (spaces added to prevent any translation)

Look at the source line beginning ~np~__Spouse1:__~/np~ in the attached screen shots.

TRP-Compare-v4-5 used the following url [http://thereevesproject.org/data/tiki-pagehistory.php?page=Heard_Robert_Brookes_2236&history_offset=0&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=5&oldver=4&paginate=on&history_pagesize=25&source=5]

TRP-Compare-v4-0 came from [http://thereevesproject.org/data/tiki-pagehistory.php?page=Heard_Robert_Brookes_2236&history_offset=0&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=4&paginate=on&history_pagesize=25&source=0]

Sorry, but these pages will not be accessible as our site isn't available at that level of permission to non members, but I thought I should include them to point at the problematic screens.

NB All the changes to this page now being viewed were made several months ago using v4.3

Perhaps related to existing item HTML line break tags displayed in page source histories [http://dev.tiki.org/item3883], which are evident if the source of other than the current version is displayed and compared.

But note the line break tags are not displayed in the source comparison part of the screen where the & quot is found.

These inconsistencies are confusing, but not show stoppers in our upgrade to 6.7

Martin

Update--

This issue is obviously wider than the instance I've described above. We now have an example of & quot ; (without the spaces) appearing on a rendered page - look at child 5 Elizabeth on page [http://thereevesproject.org/data/tiki-index.php?page=Reeves_William_3054] which is publicly visible. The source of that page clearly shows double quote marks not html as follows ...
{CODE()}__Probable children of William Reeves and Anne Terrill__:
#((Reeves_Sylvia_3219|Sylvia Reeves)), b. 1792, m. Allan Burton before 1810
#((Reeves_Jennie_3218|Jennie Reeves)), b. c1794, m. Rev. Hardin Burton on 6 Dec 1815
#((Reeves_John_3282|John Reeves)), b. c1796
#((Reeves_Obedience_3217|Obedience Reeves)), b. c1796, m. William Buchanan Burton on 25 Oct 1814
#((Reeves_Elizabeth_3287|Elizabeth "Betsy" Reeves)), b. c1801, m. John Barton on 16 Apr 1822 in Grayson VA
#((Reeves_Anne_3299|Anne Reeves)), b. c1803, m. Terrell Cox
#((Reeves_Terrill_3283|Terrell Reeves)), b. c1807
#((Reeves_Lenoir_3284|Lenoir Reeves)), b. 1808
#((Reeves_Albert_3302|Albert Reeves)), b. c1813
#((Reeves_Gaston_3286|Gaston Reeves)), b. c1814
#((Reeves_William_3285|William Reeves)), b. c1818
#((Reeves_Timothy_3303|Timothy Reeves)), b. 1821
#Unknown Female born after 1820{CODE}

Let me know if this is a discrete issue and whether I should raise a separate ticket for it.

Thx

Martin

{syntax type="tiki" editor="plain"}
I looked if something like this has been reported previously, but didn't find something that completely fits, so I post this and apologize if I missed something.

Since I have already put some detail into a [http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=44097#threadId44102|support request] and at the moment I believe it only concerns two Wikis belonging to the same admin, here is a description:

Steps to reproduce:
1) Take any Tiki installation and move a new directory
2) Create a new DB with a copy of the original DB
3) Upgrade and start it up
4) Log into the old installation as admin
5) Find out you're admin on the new one, too.

It may well be that for some admins this is a wanted behaviour like as a single-sign-on (SSO).

But it is my firm belief that any such behaviour is to be considerd a breach of security unless both admins have expressley activated this as a wanted behaviour. Possibly the problem also exists if two different admins operate two different Tikis on the same hosted volume, that somehow were created from one single predecessor, so maybe this is not as harmless as it might seem to be.

I do not know, but suspect, this could be a cookie issue.

Resolution could be that tiki-installer regenerates all security structures upon installation and/or upgrades, or at least asks the admin whether such should be reset. Also, there should be a button in the administration panel to reset this at any later time. In my opinion TikiWiki should at all times, if not told to behave otherwise, protect its instance against all other possible instances of itself...

At some point confusion may get so high to a user's browser that logging into Wiki B alone will not function, and you have to log into Wiki A to be able to access Wiki B. At the moment I experience this with my new 6.7 LTS and my old 1.9.8.3. sitting in different directories on the same volume, accessing to different MySQL DBs with differing user names and passwords...

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

! GROUP Plugin breaks CODE Plugin

Affects both v6.7 and this site. Worked OK on v4.3

{CODE(caption="1. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}

Now add a ~np~{GROUP(groups=>Registered)}~/np~ include the same code snippet and close out the ~np~{GROUP}~/np~. Start of CODE within GROUP

{GROUP(groups=>Registered)}
{CODE(caption="2. Code inside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}
{GROUP}

End of CODE within GROUP. On v6.7 the code box is displayed and the code snippet is truncated at the start of the Else statement fro a registered user. On this site, the code box is not displayed and the code is truncated at the same point for a registered user.

For an anonymous user, on both versions, there is no code box and the user see ~np~"other content{GROUP}{CODE} "~/np~

Repeating the code snippet again outside of the restricting Group statement works
{CODE(caption="3. Code outside Group" wrap=1)}{GROUP(groups=>Registered|Admins, notgroups=Editors)}some content{ELSE}other content{GROUP}{CODE}.

The code example is lifted from [http://doc.tiki.org/PluginGroup] with a caption statement added.

Happy to help test any patch,

Martin.

{syntax type="tiki" editor="plain"}
To reproduce

# Install a fresh Tiki
# Create some usernames as usual
# Set "Use email as username" feature to yes
# Create more users (this time, username will be the email)
# Create a newsletter
# Subscribe the Registered group to the newsletter
# Send a newsletter

The system will crash and be unable to send the newsletter because some users don't have valid emails. If you error reporting is activated, you will get a message like this:

{CODE()}
System error.

The following error message was returned:

Duplicate entry '3-mcradmin-g' for key 'PRIMARY'
The query was:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES (?,?,?,?,?,?,?)
Values:

3
mcradmin
6b78cc21c16e768dd8fbb6b538c6bf78
y
1339700591
g
n
The built query was likely:

INSERT INTO `tiki_newsletter_subscriptions` (`nlId`,`email`,`code`,`valid`,`subscribed`,`isUser`,`included`) VALUES ('3','mcradmin','6b78cc21c16e768dd8fbb6b538c6bf78','y','1339700591','g','n')
Things to check:

Is your database up and running?
Is your database corrupt? Please see how to repair your database
Are your database credentials accurate? (username, database name, etc in db/local.php)
Did you complete the Tiki Installer?
Please see the documentation for more information.
{CODE}

Apologies, I've some how managed to enter this twice.

Please see [http://dev.tiki.org/item4247]

{syntax type="tiki" editor="plain"}
Forum replies are difficult to read because there is no indentation when using theme TheNews on v6.7 (also affected version 4.3)

Using Firebug with Firefox v12.x established that the style value "padding-left" is set as follows ...
~pp~
#tiki-centre div 2px from thenews.css line 382 which reads #tiki-centre div { padding: 3px 2px; }
Over rides
.sub_comment 20px from layout.css line 1539 which reads .sub-comment { padding-left: 20px; }
~/pp~

We also notice that the vertical alignment could be improved upon.

Following patch has been applied via Admin -> Look & Feel - - Custom CSS and is being successfully used on our v6.7 system.

Regards,

Martin

On version 6.7 and 6.9 TW throws error "No thread indicated" when clicking on page title under certain circumstances.

The page title will be the name of the forum, for example "Discussion Forum" and the url underlying page title is of the form
[http://demo.tiki.org/6x/tiki-view_forum_thread.php?topics_offset=1&amp;forumId=1&amp;comments_parentId=1].

To recreate the error execute the following sequence of actions

Forum -> List Forums

Pick any forum which is present, for example "Discussion Forum".

At this stage the url underpinning the page title "Discussion Forum" is [demo.tiki.org/6x/tiki-view_forum.php?forumId=1]

Click on any topic within the Forum, for example "Test Topic" and the page loads correctly showing url [http://demo.tiki.org/6x/tiki-view_forum_thread.php?comments_parentId=1&topics_sort_mode=lastPost_desc&forumId=1].

At this stage the url underpinning the page title has changed to [http://demo.tiki.org/6x/tiki-view_forum_thread.php?comments_parentId=1&amp;topics_sort_mode=lastPost_desc&amp;forumId=1] although the title is unchanged reading "Discussion forum".

Click on third item in breadcrumb trail "Test topic" and the page reload as expected.

However the url underpinning the page title is now changed again reading [http://demo.tiki.org/6x/tiki-view_forum_thread.php?topics_offset=1&amp;topics_sort_mode=lastPost_desc&amp;forumId=1&amp;comments_parentId=1].

Now clicking on the page title results in error message page "No thread indicated" where the reasonably expect result would be the list of topics within the Discussion Forum.

The "Go back "button works and clicking on the second item in the breadcrumb "Discussion forum" does correctly return the user to url [http://demo.tiki.org/6x/tiki-view_forum.php?forumId=1].

It would seem this issue has been resolved in v10.0, since the last item of the breadcrumb trail has no underpinning url, so the sequence described here can not occur.

Can anybody suggest an easy fix for this bug in version 6.x, please?

Thanks,

Martin

trying to upgrade a 6.x (was 6.4) site using ''svn up'' gets it only to 6.8, but not 6.9.
Checking on sourceforge I see that the directory for 6.9 is called simply that, not tiki 6.9, as the subversions 6.0 through 6.8 are called. Could this be why svn up isn't upgrading to 6.9? If so, can someone with authority on sourcefourge fix this please.
Also switching to a specific version, e.g.
svn switch https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/tags/6.9/
results in the msg that there is no such directory.
Running tiki-install.php also fails to upgrade the site from 6.8 to 6.9.
So, how best upgrade? (I really don't want to do a fresh parallel install.)

For info: Before doing the svn up, I had done
svn switch --relocate https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/branches/6.x http://svn.sf.net/tikiwiki/code/branches/6.x


I first asked the question in irc, but got no responses.

When tiki-view_blog.php?blogId=x lists many posts, each one using footnotes, the footnotes numbers are false except for the first post.

As each post of the list is parsed, its first footnote number is not 1, but the total number of all the footnotes of the preceding posts of the list.

Versions : 6, 9, 10.
See : [http://demo.tiki.org/10x/blog2|http://demo.tiki.org/10x/blog2]
and [http://demo.tiki.org/9x/tiki-view_blog.php?blogId=6|http://demo.tiki.org/9x/tiki-view_blog.php?blogId=6]

The smarty function that generates a user link (lib/smarty_tiki/modifier.userlink.php) will only return an actual link if the user's user_information preference is set to 'public'. In the case where the user link is to the currently logged-in user, however, there is no reason not to display the link even if that preference is set to 'private' as the user should be able to view their own preferences. This is easy to demonstrate; set your user_information preference to private and then look at your name in login module. The name will not be a link to your user preferences.

{syntax type="tiki" editor="plain"}
Hello.

I just upgraded a Tikiwiki3 to 6.0
I did the database upgrade procedure and converted to utf 8.
The upgraded showed this error:

---
[root@WIKEttl03 it]# php installer/shell.php
Running installer for: db/local.php
Queries executed successfully: 5245
Errors:
===== Error 0 =====
-- perms types that don't appear to relate to features - 'mail notifications', 'menus', 'quicktags', 'tiki'


This command is not supported in the prepared statement protocol yet
---
Tiki Cache was cleared, Browser Caches, too. And Browser restartet.

If I click Look and Feel under tiki-admin.php it's showing the ajax "loadind..." and nothing happens. Entering the URL directly with tiki-admin.php?page=look the look and feel page loads, but with errors in the browser (java script).
Turning off ajax, results in loading look+feel from tiki-admin.php. (but still showing browser errors.) The behavior is the same for IE8, Chrome and Seakmonkey.

The PHP Errors shown on the page:

{CODE(caption="Error messages",wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%C4^C4D^C4DDBC33%%tiki-admin_include_look.tpl.php
Line: 27
Type: Undefined index: user_prefs
PHP (5.1.6) NOTICE (E_NOTICE):
File: lib/prefslib.php
Line: 73
Type: Undefined index: sitetitle
PHP (5.1.6) NOTICE (E_NOTICE):
File: lib/prefslib.php
Line: 73
Type: Undefined index: sitesubtitle
PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%5B^5BD^5BDF701F%%tiki-site_header.tpl.php
Line: 10
Type: Undefined index: filegals_manager
PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%5B^5BD^5BDF701F%%tiki-site_header.tpl.php
Line: 10
Type: Undefined index: print_page
PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%5B^5BD^5BDF701F%%tiki-site_header.tpl.php
Line: 21
Type: Undefined index: filegals_manager
PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%5B^5BD^5BDF701F%%tiki-site_header.tpl.php
Line: 21
Type: Undefined index: print_page
PHP (5.1.6) NOTICE (E_NOTICE):
File: templates_c/en^%%DD^DD2^DD29EF94%%tiki.tpl.php
Line: 84
Type: Undefined index: fullscreen{CODE}

Kind Regards.

It concerns the Passwords match and do not match.
Chealer explained to me that there is a language.js file to be created in the lang/<yourlang> folder (as in ca).
Since my ajax is on, the password check is not run from
tiki-js.js, checkPasswordsMatch
but from
register_ajax.js (please also add a header to this file), check_pass.
The tr function is not defined there, so it would not work.

See also
http://irc.tikiwiki.org/irclogger_log/tikiwiki?date=2010-10-19,Tue

P.S. I rated this 9, because there will be people who want ajax and another language, but do not like to dig js files for such a basic functionality.

I added a jscalendar field to a new tracker. On the item entry page, the calendar is drawn underneath the form.

Using Tiki 6.x (proposals) and Tiki 7 (trunk)

I have a wiki page that belongs to multiple structures.

I have the "open page as structure" option enabled.


If I open the page directly, Tiki does not know which structure to use, so it opens the page __with no__ structure.

This means that the generated TOC is empty. The only way the end-user knows that the page is __supposed__ to be in a structure is by selecting a specific item from the __Structure__ drop list.

But the end-user may not have any understanding of what a "wiki structure" actually is.

There should be a way to set the default structure for a page.

Fatal error when trying to authenticate against an LDAP server on IIS6 Windowns 2003 Server:

Fatal error: Call to undefined method Net_LDAP2_Error::getEntry() in D:\WWWROOT\wiki60\lib\auth\ldap.php on line 257

System environment:
Tiki 6
Windows Server 2008 64bit
Apache x64 2.2.11
PHP x64 5.2.5 (lib/smarty/libs/internals/core.is_secure.php patched to make it work)

LDAP authentication against AD does work once configured properly
BUT
Debugging the configuration was hard because turning on logging caused errors!
When logging is off, all is well. When logging is on and line 346 of lib/auth/ldap.php is commented out, all is well.
It seems that when logging is active, "$filter->asString()" on that line causes an error on our system. The same call is made on line 262 with a simpler filter and works OK.

Perhaps when checking groups, asString is returning too much for the logging system to handle?