Category: All / Undefined

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

I do not know if this problem was already posted, but a search for php 5.3 only got me a blank page.

Ok the problem is the following:
We have an older test area with openSUSE 11.1 running and no problems so far. We back this server up to another server with the same OS and never had problems. Both running PHP 5.2.x and MySQL 5.0.x.

As we set up a server on an old pc for testing purposes with the latest openSUSE 11.2 and PHP 5.3 and MySQL 5.1.x and tried to copy the tiki on this machine all the special characters (Umlaute like &auml, &ouml or ü) wouldn't be displayed properly but like they are stored in the database like Ãœ (I hope it wouldn't be displayed as an Ü here but rather as it would be stored in the database).

This happened on several installations on different machines and on different virtual machines - it all works without problems in the old environment but has problems under the new.

I also hope that Ü will be displayed not as HTML Code but as the real character as i cannot type in the ue through this vncviewer.

It was tested with the 3.x release. And i guess we once tried it too with the 4.x release with the same problem.

As solution we downgraded to an older PHP Version. Also it is possible to write a small php script to replace all Ãœ to Üor ue and the same with the other special characters. But therefore you need to know all special characters with all the corresponding (I guess it would be) utf8 codes.

As discussed at the TikiFest (?), we need more granularity here, for people that want AJAX for some features, but not for others.

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

This is a new formulation of 3029 problem after near 200 hours of test and debug.

!The problem is now precise and near solution :
I can't affirm that I wrote debug because the execution stop on another problem.
The time spend is not only on TikiWiki, a had to solved installation problems and find a bug into easyphp and addresses resolution on the server.
The problem began with 4.1 and php 5.3.0 and I upgrade to 4.2 and 5.3.2 to be sure of the problem and the available solution.

!Span of the problem :
# Definition of main classes TikiDb and TikiDb_Pdo and PDO->function execution
# Progs : tiki-db-pdo.php, tikisession-pdo.php and naturally pdo.php, tikiDb.php
# PDO extension and behavior of objects and classes

!Description
note : Because I found the nature of the problem, I don't start from the nature of the crash but the analysis, but I produce a selected track made with xdebug var_dump)

# In tiki-db-pdo.php:40 we create the Pdo object
<$dbTiki = new PDO("$db_tiki:$db_hoststring;dbname=$dbs_tiki", $user_tiki, $pass_tiki); >

# just later In tiki-db-pdo.php:49 we set the singleton of TikiDb_Pdo into TikiDb abstract class with scope operator
<TikiDb::set( new TikiDb_Pdo( $dbTiki ) ); >

# further we call In tikisession-pdo.php:28 we can find the session read
< $sth = TikiDb::get()->prepare($qry); >
This instruction generates the fatal error :
__ Fatal error: Call to undefined method TikiDb_Pdo::prepare() in D:\Trebly\Teawik-ld8-422a\lib\tikisession-pdo.php on line 28__

!Explanation and solution implemented
The reason is simple and explained by the error comment :
we try to run the prepare function which is a PDO function on a TikiDb_Pdo object which has no reason to inherit of these Pdo function even <TikiDb::get()->db->prepare> could have a meaning.

Then the solution is in what is made in ZEND lib (not yet used), create an interface to PDO into Class TikiDb_Pdo.
This functions and it is written.

! A major question
One important question is why and how the same instructions seems to be available and functions well on Linux (I have a site which runs normally with 4.1, not yet upgraded to 4.2, a to-do)

I believe that the actual solution that I have developed for 4.2 on Windows with PDO (compiled) extension, should be extended to the normal version.

As I have said before I can't confirm completely that the solution is correctly tested and free of bug because, the program have a FATAL ERROR PDOException: SQLSTATE[HY093] later on the prefs restoration I create another report for this.

Note :
the execute statement written execute() without parameter generates each time a warning message when xdebug is activated with STRICT option (default in 5.3.2) for errors handling in php, and necessarily makes the code lightly slower. I developed an enhanced error template according to the error handler which displays much more informations about the context and, into these, the parameter (title) of execute statement. This make an enhancement to find much more quickly the errors.

This tracker item could not be found

This tracker item could not be found

We can't use rating yet (hopefully soon), so at the moment it is just the priority user chooses. From 1-low to 9-high is very subjective and people tend to rate things higher, than they 'objectively' are. I just stumbled across this classification from Bram Molenaar and think that it is a good guideline for rating Items. As long as we use the Priority field, it would be easy to implement, later for Ratings we would have to add something like a legend or so..

--- copied from VIM reference manual TODO List ---
Priority classification:
9 next point release
8 next release
7 as soon as possible
6 soon
5 should be included
4 nice to have
3 consider including
2 maybe not
1 probably not
- unclassified
--- end of copy ---

The down arrow / right arrow to indicate dropdown/flyout child list items are missing. I don't know if this problem began in Tiki 13 or branch 14. These arrows aren't images but are made with JavaScript and CSS. Page of author, for examples and docs: https://github.com/joeldbirch/superfish

My setup: MacOSX 10.13.6, MAMP Pro using PHP 5.6.33 using trunk or 18.x.

{CODE()}Macintosh-2:trunk Bernard$ php doc/devtools/svnup.php

Parse error: syntax error, unexpected ':', expecting ';' or '{' in /Users/xxx/Documents/xxx/www/htdocs/trunk/lib/tikiaccesslib.php on line 1238

Call Stack:
0.0024 350864 1. {main}() /Users/xxx/Documents/xxx/www/htdocs/trunk/doc/devtools/svnup.php:0
0.1037 509512 2. require_once('/Users/xxx/Documents/xxx/www/htdocs/trunk/tiki-setup_base.php') /Users/xxx/Documents/xxx/www/htdocs/trunk/doc/devtools/svnup.php:47
0.8336 11607456 3. TikiLib::lib() /Users/xxx/Documents/xxx/www/htdocs/trunk/tiki-setup_base.php:249
0.8337 11607632 4. Symfony\Component\DependencyInjection\ContainerBuilder->get() /Users/xxx/Documents/xxx/www/htdocs/trunk/lib/tikilib.php:68
0.8337 11607632 5. Symfony\Component\DependencyInjection\ContainerBuilder->doGet() /Users/xxx/Documents/xxx/www/htdocs/trunk/vendor_bundled/vendor/symfony/dependency-injection/ContainerBuilder.php:587
0.8337 11608024 6. Symfony\Component\DependencyInjection\ContainerBuilder->createService() /Users/xxx/Documents/xxx/www/htdocs/trunk/vendor_bundled/vendor/symfony/dependency-injection/ContainerBuilder.php:633
{CODE}

It was working 3 weeks ago and it is still working on 18.x.

Note: When I try with PHP 7.2.7 svnup.php throw : mysql server not started (on trunk and 18x)

A lot of people install with FTP.

They do not have shell access and do not run setup.sh

Up to 1.9.11, templates_c was part of the .zip

However, for some reason, in 2.x and 3.x, --you need to manually create this directory.-- Oups, no, installer created. Nonetheless, the directory is back in 3.0

This should be restored to previous behavior.


1- It should have an index.php to prevent directory browsing
2- ((TRIM)) cleaner should not delete this index.php
3- clear caches in tiki-admin_system.php?do=templates_c should not delete this index.php

This tracker item could not be found

this is just a test

Suggested message if PHP5 is not detected:

^
__TikiWiki 3.0 requires PHP 5.x__

Your currently detected PHP version is: (versionnumber)

Please contact your web host to request an upgrade. If there is no way you can have PHP 5.x, please use Tiki 2.x instead. Some features in Tiki 2.x, such as profiles and TikiTests require PHP5, but all the other hundreds of features work perfectly with PHP 4.1+

For more information:
http://www.gophp5.org/
http://tikiwiki.org/
^



(9:59:42 AM) marclaporte: turning on TikiTests crashed by site :
(9:59:42 AM) marclaporte: Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /home/profiles/public_html/tiki_tests/tikitestslib.php on line 59
(9:59:53 AM) marclaporte: I suspect because I don't have php5
(10:00:01 AM) marclaporte: http://profiles.tikiwiki.org/

This tracker item could not be found

This tracker item could not be found

This tracker item could not be found

This tracker item could not be found

{syntax type="tiki" editor="plain"}
This is how look the cookie requirement on Tiki.o

{img fileId="3086"}

There is room for improvement as this is the first thing someone discovering Tiki will see and have to do. ;-)

Subject says it all.

Some great men(women) said great things - and I can't enter their name in addition to their quote!! ;(

Give credit, where credit's due! And I take that very seriously!

A weird bug which was showing in tiki 4.x (calendar), and nowadays, I've seen something similar using 5.x alpha at dev.tw.o:

The user is redirected to a blank page with just an email address shown, even if the user didn't click anywhere.

To reproduce:
http://dev.tikiwiki.org/tiki-view_tracker.php?trackerId=5&status=o&sort_mode=f_41_desc&filterfield=54&&filtervalue[54]=xavi&&&&filtervalue[56]=Accepted&&offset=30

Pass the mouse over the item saying "2 errors editing articles in tiki 3.3 ".
With no click (just passing the mouse over, using Firefox 3.6.2), you are shown a blank page with just "email@domain.org" on top.

That item corresponds to:
http://dev.tikiwiki.org/bug2893


This is something which is also happening to a calendar in a tiki 4.x site, when the event body has some email address, it seems.

HTH

Maybe some of you will think of this as a "marketinhg" thing, but let's face it : for most users on the Web "wiki" is synonym with "MediaWiki-powered sites that look like wikipedia".

What I propose is to create the theme and tools to facilitate migration of mediawiki powered sites to tikiwiki the (very) easy way : fill a form during install that points to the Mediawiki database, and extract all the info to automagically populate the Tiki. I'm willing to participate, but I do not feel I have the required knowledge at this moment to be able to do something useful in the coding part : I know little to no PHP or MySQL stuff, I even wasn't able to install Tiki properly here (shame on me).

To whoever it may concern,

I'm trying to integrate my awesome Tiki (v 5.3) with Bigbluebutton,
the problem is, I couldn't spot any bigbluebutton icon on the list of features despite the setup for the integration is theoretically correct according to available resources.

The custom screenshot can be viewed here:
{IMG(src="http://dev.tiki.org/show_image.php?id=118")}{IMG}
or [http://dev.tiki.org/show_image.php?id=118|here]

Thank you in advance

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

I have yet redacted quite the same text three month ago, about 4.1, 4.2... Because i could never start these versions, try to find bugs... submit but no answers.

My original text has been lost because of the bugs of the bugs reports management (author not stored - corrected, no capability to sort the items by date, no capability to sort anyway and search) nevertheless, too much to do elsewhere...

__Lest's go to the problem, which is a major one :__

!!The fact :
If any fields which is stored into sessions->data contains an " ' ", it is impossible to restart TIKI (always automatically and by evidence crashes if TIKI tries to restore these session.

!!The reason :
The text is stored with is " ' " and included "simply" into the query which resets the prefs.
By evidence this simple quote " ' " creates a query error and a crash of tiki (often APACHE).
this " ' " is interpreted as the end of the query, and the remaining a non-sense.

!!!Example :
With 5.0 if you are just installing with an upgrade of database, into the session query you will find the third data_text-block
$plugstring = <<<PLUGINTEXT
...
alt:
required: false
name: Alternate text
description: Alternate text that displays image doesn't load.
...

the " ' " of "doesn't" crashes the first run.

!!!The same happens when you have a header page with a title containing a simple quote " ' "

!!Solution :

!!!technical point of view
I have just found a lonely solution :

* the first, simple : any sessions->data content must be pre-translated with doubled simple quotes (which is the SQL syntax).
* any read of sessions->data doubled simple quotes must be set back to a unique one.

This possible solution offers too the capability to find fields with quotes by any query, if the data sent into queries are pre-translated (if not it is a crash).

A back translation after reading is not need only in some cases (the prefs restoration for example), for a search query the results will come back with their simple quotes...

!!!Who acts ?
It is very simple.
There are not many place where the problem occurs;
But I I have lost so much time because of the bug of 4.x and now 5.0RC and 5.0 Stable that I could not make the work I had programmed to do.
In my opinion it should be better that people who have written the SQL requests, make the change.

If they are not ready, I can submit patches (tikisession particularly)

Bye

trebly

{syntax type="tiki" editor="plain"}
Tiki and Pear::Auth (LDAP) authentication doesn't work together in
version 3.0. A tiki local user can't log in anymore if the Pear::Auth
method is set, except admin.

Printing pages is sometimes a real mess.
So, http://www.printwhatyoulike.com brings the opportunity to select parts of the page to print etc.