Category: All / Undefined

Hello all!

I have a Tiki instance, installed with regular Apache and -+.htaccess+- and I tried to put the Ngnix as a reverse proxy for that.

The Nginx was setup to accept just https connections. The scheme is forwarded by using the header -+X-Forwarded-Proto+-, which is suggested by nginx documentation. While Tiki does not recognize that, Tiki pages will use the regular -+http+- when rendering action on any form, like auth form for example. When user POST to http://, the proxy will redirect http to https and the POST request will be lost.

I suggest Tiki recognize -+X-Forwarded-*+- and also -+Forwarded+-, as we can find on https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/.

Cheers,

All TikiWiki pages don't load with the mentioned plugin activated. All I did was an update from 3.0 to 3.1... Afterwards, TW didn't work any longer. When I deactivate the plugin, everything's okay.

I believe this has to do with a specific TW feature, but I can't make out which one...

I'll try to find out more about this problem, and will all I can find out to this bug report.

This site dev.tikiwiki.org works fine however...

To reproduce the problem, go here: http://list.vic-fontaine.com

Please feel to reproduce the mistake in our system: http://www.feldtech.com/tiki.

Here a descrition of two such errors:
The location of a specific article is http://www.feldtech.com/tiki/tiki-read_article.php?articleId=9
but the link generated for visitors is: http://www.feldtech.com/tiki/article9


A certain gallery is to be found at http://www.feldtech.com/tiki/tiki-browse_gallery.php?galleryId=5
but tiki produces the following dead link: http://www.feldtech.com/tiki/gallery5

I am using tikiwik 1.9.7 on RHEL 3 with apache 2.0.54 and PHP Version 5.0.5. I have apache listening on port 80 and 443 (https). WHen I bring up the login page (https://myservername.domain.org/tikiwiki/) and then login, tikiwiki kicks back to the http version... (http://myservername.domain.org/tikiwiki/tiki-index.php)............
This should not happen...it is a bug.

does any body know ways to resolve it???

I was researching a way to become more involved in Tiki that was not beyond my skill level. So Tiki Tester I feel would be a good way for me to give back to the community.
As I was digging into the Tikitester page, I found the links to the tiki test pages no longer are valid, please see:

https://dev.tiki.org/Instructions%20for%20Tiki%20Testers

And click on links to Tiki Test pages.
Thank you for taking a look at this, any further guidance would be appreciated.

While translating, I came across Tiki User Credits. Sometimes they seem to be called "User Level Credits", but not consistently.

This feature is by and large rather undocumented... What precisely are they? Are they some token "currency", because you can use it in CART, are they some system of points (sometimes "User Level Credits" are mentioned), which users can gain through Wiki activity? Then I don't understand "(level credits always 0)" also "Use User Credit". Use them - for what?

Then there are "plans"? Is this some system of automatically gaining points that are to be expended on - which - activity? They seem to be able expire...

And as I wrote in the related bug report, you can create new types of credits, but cannot alter or delete them... Text like "Is Static Level Credit" are a mystery to me :-)

Is there some documentation that I did not find (nor did Google...) ?
Thanks

This was reported on ((tw:ReleaseProcess19rc1)). More info may be needed to resolve.

"Tiki uses too many cookies; problems arise when one exceeds the browser's limit on number of cookies per domain."

{syntax type="tiki" editor="plain"}
Folks,

To someone who's trying to figure out how to report website issues, the whole Tiki project is quite actively hostile toward people who aren't developers thoroughly integrated in to your gitlab.

First, there's errors all over the tiki websites - somebody's done something like upgraded the website, and left things in broken states all over (attached images). Who's maintaining the tikis that run these sites?

Second, everything else around here is hostile toward people who are trying to provide some feedback that doesn't fit in to each sub-sites narrow definition of what *you* want to have communicated. For example - your feedback form apparently isn't for support or feedback about the websites or whatever. In the forums, you're missing a general support forum for things like website work/feedback - when looking in to the documentation forum (some projects consider the website part of the documentation on the whole), it actively states "Post in this forum ONLY topics related to the "Documentation" pages (doc.tw.o)".

Your chat link simply goes to a login page (gitter) that, if you don't have, presumably, a matrix account somewhere, goes nowhere (or actively encourages people to use big-yankee-tech accounts, but god forbid we'd like to just login under a guest account to reach anybody on the project). There's no account creation process, etc. This is hostile to people.

The mailing lists and forums are essentially dead or dying - nobody's helping people out with their problems on the users mailing list.

The website has got brokenness all over the place (why the two find boxes on the documentation site near the top?), and broken links in the footer.

This project seems to simply be developers having some fun with their code, but beyond that, it really appears to not be at all friendly to people who'd like to try and make use of the software.

So here's a bug report that can't be filed in any appropriate category, since there's no category to file bugs against the website(s). If I sound frustrated, it's because I've spent a bunch of time going around to each of your possible support/feedback paths trying to figure out where it might be useful to report this kind of feedback, and I've wound up concluding "nowhere". That's not cool. Are you trying to build any sort of community here? If you are, or if there is a community outside of the developers pushing commits, then maybe there should be a bunch of re-org and simplification of parts of the websites to direct people to the right places, and make the process __easy__ so it's not a huge time suck to do this sort of thing.

This could have been an email, had one been listed.

Please have a look at the attached images of the website brokenness. Beyond the red error boxes and the non-functioning consultants lists, it should be noted that the Event box at the top of so many pages doesn't stay away when clicked. It keeps showing up on every page you go to.

{img fileId="3148" thumb="box"}

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

This occured during ReleaseProcess192
Check and fix, if real - perhaps dependant on ./setup.sh

tiki-print_pages.php should allow to set the parameter tikiversion at printing time, if Plugin Versions is being used. Example: doc.tw.o of twforsmarties: print documentation for veersion 1.9.x, 2.x or 3.x.
http://doc.tikiwiki.org/tiki-print_pages.php

http://twbasics.keycontent.org/tiki-print_pages.php

Right now, if I want to print the full structure of the documentation, I can't chose version (so that the default is shown)


marclaporte: and the same idea should apply to language. Show me doc in my language, if there is none, fall back to available language.

tiki-register.php has a few flows:
- the string "Passwords match" is not translated even if added to translations
- the string "Passwords don't match" is not translated even if added to translations
- the input fields (username, email, code, etc) are not aligned to the left, this is not nice

tiki-login.php:
- the string "Log in as..." is not translated even if added to translations

Tiki.org is not being update properly since a few days.
Last update from SVN (18.2svn): Monday 07 May 2018 - REV 66281

It should be updated on a regular basis every 24h (as I remember).

it may be bigbluebutton's fault, but i have experienced
the following strangeness when using the plugin:

the microphone can not be turned on in the flash interface ...
therefore no sound at all after setting up the 0.7 VM using salt.

description of process:

download, unzip 0.7 VM
create virtual machine using bbb disk image, start vm, wait for
package updates, login, new password

first bbb-conf --set-ip SOMEHOST works perfectly, i can log in the
Demo Meeting with multiple users, microphone and sharing works all
fine

then i add the salt via sudo bbb-conf --salt SALT and restart with
sudo bbb-conf --clean

i can still access http://somehost , but can not log in to any
meetings anymore due to salt , thats ok, cause its secure like this

now i add the salt to my tikiwiki 5.0 via admin->features

then i create a wikipage with the plugin: {bigbluebutton name=My
Conference Room}

i am able to connect to the conference, even with multiple users,
webcam sharing works, but the microphone can not be shared. clicking
on the flash microphone icon does not give any sound, nor any
confirmation dialog to allow access to the webcam/mic devices

now as I do not have too much experience regarding BBB, i would kindly
ask for your help to get the microphone sharing working

TikiWiki is causing Apache to crash with the following error in the Apache logs:

[Thu Feb 22 23:26:53 2007] [notice] Parent: child process exited with status 3221225477 -- Restarting.
[Thu Feb 22 23:26:56 2007] [notice] Apache/2.2.3 (Win32) mod_ssl/2.2.3 OpenSSL/0.9.8d PHP/5.2.0 mod_perl/2.0.3-dev Perl/v5.8.8 configured -- resuming normal operations
[Thu Feb 22 23:26:56 2007] [notice] Server built: Nov 15 2006 21:34:51
[Thu Feb 22 23:26:56 2007] [notice] Parent: Created child process 2668
[Thu Feb 22 23:26:58 2007] [notice] ModSecurity for Apache 2.0.4 configured
[Thu Feb 22 23:27:00 2007] [notice] Child 2668: Child process is running
[Thu Feb 22 23:27:00 2007] [notice] Child 2668: Acquired the start mutex.
[Thu Feb 22 23:27:00 2007] [notice] Child 2668: Starting 250 worker threads.
[Thu Feb 22 23:27:00 2007] [notice] Child 2668: Starting thread to listen on port 443.
[Thu Feb 22 23:27:00 2007] [notice] Child 2668: Starting thread to listen on port 80.


And this is the Windows Event viewer:

Faulting application httpd.exe, version 2.2.3.0, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x000106c3.


This is running on a brand new installation of Windows XP Pro with the latest Web-Developer Server Suite WAMP distribution giving Apache 2.2.3, PHP 5.2.0/4.4.4 and MySQL 5.0.27. I have also tried it with the latest version of Apache and PHP and get exactly the same error!

Cheers Mike

In 1.8.5, the mailin feature doesn't work properly. It may work for some combination of mail systems, but not for others. And it does not properly handle multiple mailed-in messages when a page load is attempted.

Specifically, some combination of mail client and mail server caused the email address extraction to leave a newline on the end, which should be trimmed.

Also, in determining the type of message, a case-sensitive string comparison is done against "text/html", which won't match for upper or mixed-case.

Finally, there's a bug (probably a minor design flaw) in the way the histlib object is created in lib/tikilib.php, such that if the code is executed twice in the same session, it will fail the second time because the $histlib object isn't created.

Last but not least, after parsing the message, if there are no parts found, the loop that attempts to process them assumes that $output->parts exists, which it may not.

TikiWiki Powered Sites listed [http://info.tikiwiki.org/tiki-browse_gallery.php?galleryId=1|here] contains many websites which are moved away from Tiki, for example [http://wiki.kde.org|KDE Wiki]. A total clean up of invalid websites is required for the listing.

The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever

I did report this bug days ago. I edited to close it, selecting as closed many of the fields to do so in the [tracker5] but I forgot to set as "closed" the first and traditional drop down:

http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2856

After I saved, I can't edit my bug tracker any more, not even to set as closed that bug report.
To me, too many fields are related to closing the bug, only one should be chosen for that. And if more than one, much better to place all of them close ones to the others.
---
UPDATE: Outdated, so closing.

In my installation, on some internal links that are represented in an absolute way, there is a backslash between the domain name and the first slash.

Eg when I try to login on http://mydomain.com/index.php, I get redirected to http://mydomain.com\/tiki-login.php, which the server cannot render.

Clean install of:
MS Windows Server 2003 SE SP2 on x86
Apache 2.2.10
MySQL 5.1.30
PHP 5.2.8
TikiWiki 2.2

Tiki resides directly in the DocumentRoot C:\tiki (as it is a dedicated server).

In tiki-setup.php, there is a line

{img src=images/code.png}%%% {CODE()} $tikiroot = dirname($_SERVER['PHP_SELF']); {CODE}

In the documentation of [http://www.php.net/dirname |((dirname))], they state that since PHP 4.3.0, dirname returns unexpected values. The example implies that on Windows dirname('/x') returns '\'.

Therefore, if you install Tiki in the DocumentRoot, _SERVER['PHP_SELF'] will be '/filename.php' and $tikiroot will be '\'.

How about a true staging capability for TikiWiki?

That would include that all content can be scheduled. In essence, whether we are talking a wiki page, an article, etc, everything would have an validity interval attached. __INSIDE__ that interval, edits can be made and versions are kept, but each of the entities (like a wiki page) would have siblings that are valid for a specific timeframe.

I know that would mean some work, but it would make using Tiki for business websites so much more convenient.

trunk broken in next*.tiki.org sites due to Zend issue (zf1 to zf2?)

Error type:
{CODE()}
Fatal error: Class 'Zend\Config\Ini' not found in /var/local/doc.tiki.org/www/db/tiki-db.php on line 97
{CODE}

Using latest trunk: r57094

To reproduce, try to visit
https://nextdev.tiki.org
or
https://nextdoc.tiki.org

etc

Line 58 of tiki-objectpermissions.php has the variable $perm written with a double $ sign twice.

if (!($tiki_p_admin_objects == 'y' || (isset($$perm) && $$perm == 'y') || (isset($special_perm) && $special_perm == 'y'))) {

should read
if (!($tiki_p_admin_objects == 'y' || (isset($perm) && $perm == 'y') || (isset($special_perm) && $special_perm == 'y'))) {

Still newbie here, not confident enough to commit changes.

I am unable to access info.tikiwiki.org or themes.tikiwiki.org with IE7. (FF and Opera work fine.) I get the following error:
{CODE()}
Warning: session_start() [function.session-start]: open(/tmp/sess_4bf95c633abfec1c2db078c6c7e6cf23, O_RDWR) failed: Permission denied (13) in /home/themetw/public_html/tiki-setup_base.php on line 279

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/themetw/public_html/tiki-setup_base.php:279) in /home/themetw/public_html/tiki-setup_base.php on line 279
header already sent
{CODE}

After svn switching from trunk to 6.x, my wiki has internal server errors on certain pages, especially if I'm logged in.

I maintain my svn on a windows machine, and I zip up my image, ftp it to my linux server, unpack it, run admin upgrades, and clear the cache. After all that I can browse the site as anonymous, but not as an admin or editor.

I am considering switching back to trunk, as the bugs there are less serious.