PHP5.3 has been a long time coming, but some of the internal changes ARE causing problems for third party packages, and so deployment will probably be somewhat delayed in the field. I've seen a few linux distributions pushing it out as a normal update, but then getting requests to get back to PHP5.2. It should be treated more like a major version change rather than the minor one it's numbering would imply, but we have had this before with PHP - how many people got stung with PHP5.1? It's the 'odd version number' problem over again ;) Many of these changes should have been saved to go with PHP6 and clean unicode implementation, but it looks like that is going to be delayed even further.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Matthys
I'm using PHP v5.3.2 without issue with PGV v4.2.3+ (svn). What problems are you having? You posted on a thread that was more than a YEAR old - and all changes to the code to have it compatible with PHPv5.3 were included in releases since that time.-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I'm having the same problem after having updated the base OS (openSuSE to v12.1 from 11.3) which has updated PHP to v5.3.4

trying to update dates anywhere on PGV brings up the following error:

ERROR 2: preg_replace(): Compilation failed: POSIX collating elements are not supported at offset 3
0 Error occurred on in function preg_replace
1 called from line 241 of file functions_date.php in function default_edit_to_gedcom_date
2 called from line 2244 of file functions_edit.php in function check_input_date
3 called from line 2215 of file functions_edit.php in function handle_updates
4 called from line 1489 of file edit_interface.php
Warning: preg_replace(): Compilation failed: POSIX collating elements are not supported at offset 3 in /srv/www/htdocs/family/includes/functions/functions_date.php on line 241

error_reporting is set to E_ALL & ~E_DEPRECATED & ~E_NOTICE

any help much appreciated

Peter

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Peter
PHPv5.3.4 is almost ancient now. If you just updated, you should have more current versions. The most recent stable release is v5.3.10 (just released, but several important fixes) and v5.4 will be out shortly considering they are on RCv6.

I can't speak to OpenBase, but I have no issues with the current SVN code and PHPv5.3.9 on my MacOS-X Snow Leopard (10.6.8) and Apache-2+. I would suggest you may be unable to use the OS you describe and you may need to move to webtrees as I don't believe anyone here will be able to code a fix (if truly needed) for your problem.

What version of PGV are you using? If not v4.3 (SVN), then try that first since that is the version you should be using. There were many fixes for PHPv5.3 in the code from older versions.
-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

I agree that this might be a PHP bug, specific that implementation of PHP.

The code appears to transform full-stops in the text to full-stops enclosed by paired square brackets. I have no idea what the code is actually trying to do here.

From what I can gather, the POSIX elements that aren't supported would have the appearance of some string enclosed by a pair of full-stops which are then enclosed by paired square brackets. In other words, you need a pair of full-stops inside a set of square brackets for that string to be POSIX element. A single full-stop inside a set of square brackes is not a POSIX element.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Just installed PGV v4.2.4 under PHP 5.3.10 and mySQL 5.0.9. and got, apart from errors when trying to generate some reports (deprecated function calls), a most annoying problem. Individual full names appear in PGV and in the DB without a blank between the (last) given name and the surname. Same occurs under PHP v5.2.17. The ANSI coded GEDCOM file generated by Heredis 10 looks OK. Manually correcting in the mySQL DB is of no use.
Any hint ?
Yves

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Yves
PLEASE -
1) do NOT resurrect ancient threads.
2) do NOT use open discussion for HELP. Use the help forum for help.

PGV 4.3 (svn) works fine with PHP 5.3.10. If you review the requirements, you'll see the minimum MySql ishttp://wiki.webtrees.net/System_requirements
MySQL 5.0.13 or later. Note that webtrees can share a single database with other applications, by choosing a unique table prefix during configuration. If the number of databases is not restricted, you can set up a database purely for use by webtrees and create a separate user and password for only your genealogy.

You will not be able to use 5.0.9 with any PGV installation reliably.-Stephen

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details