Re: [PHP] intl extension on os x
- Original Message > From: Tom Worster > To: PHP General List > Sent: Sunday, September 27, 2009 5:34:45 PM > Subject: [PHP] intl extension on os x > > does anyone know how to install intl on os x 10.5? > > it seems a libicu binary is included in os x but not with headers. fink has > a package for installing the headers. maybe that would allow pecl to install > the intl extension. > > has anyone done this successfully? or know any other way to get intl running > on 10.5? > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php When Apple made the big change of OS a few years back, they switch to *BSD based OS, with the GUI from NeXT, which Apple bought. You should be able to compile most linux/unix codes on Mac though. Have you looked at Apple's developer's resources/documentation? Regards, Tommy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] intl extension on os x
does anyone know how to install intl on os x 10.5? it seems a libicu binary is included in os x but not with headers. fink has a package for installing the headers. maybe that would allow pecl to install the intl extension. has anyone done this successfully? or know any other way to get intl running on 10.5? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Web Site Directory Layout
On 26-Sep-09, at 2:38 AM, Ashley Sheridan wrote: I tend to usually go with the following, using what fits with the project: index.php styles/ images/ scripts/ includes/ --- Add files/ for any download-able files. Then for multi-lingual projects, I'll add a content/[language]/ structure, to put my content php files in, while leaving the structural php files on the root. User preferences and cookies form the path to grab the content, but this way you get similar (and shorter) URLs. George Langley Multimedia Developer www.georgelangley.ca
[PHP] Issue of upgrading from to 5.x
Here's a little problem I'm just discovering.
The issue has been brought to my attention by a couple of my clients when
their mail() replies were suddenly turning up with zero variable content.
I have several html/php contact/subscribe forms which return a mail reply to
the web site owner. These have recently been turning up with none of the
variables being picked up from the html form. The mail() library is still
sending the reply correctly. All the material is hosted on commercial ISP web
servers. A couple of them have clearly upgraded to PHP 5.x recently.
When a user fills out the form and presses the submit button the process page
picks up the variables from the input and mails the output back to the site
owner. Recently some of these replies have started to show up with the
variables not being picked up. On looking through the official PHP
documentation it would seem to be an issue of the change in the use of
globals being turned off by default in 5.x onwards. I found an example of a
function in the documentation to include that simulates globals being turned
on but this does not seem to be working as expected.
While this is a very simple (and possibly only a bit irritating) problem the
nightmare scenario for me is that I have a great many files (read several Ks)
that rely on the same functionality, as the access to several MySql
databases. I have very quickly tested a couple of these database constructs
on one of the hosting sites where the mail() forms have failed and the
database constructs do not work either. I really would prefer not to have to
spend the whole of the next year re-writing all these files especially as
this work is all voluntary.
Now if these very simple html form / php processing structures are now going
to fail by not retrieving the variables what are we supposed to do to create
web site contact forms or data entry pages for database access. I have tried
constructing the forms as hybrid php/html and included the function noted
above and this did not work either. In fact on one of the servers running the
upgrade even logging on to the database construct froze at the first
processing page. I think that either this
header("Location: adminhome.php");
exit(); failed to trigger or the "session_register();" failed.raised
Any suggestions advice would be most welcome.
I have included an example snippet of code from one of the mailback forms that
has been working correctly for several years.
A snippet of example code
The Form:
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
On-line Membership form
Join the Campaign
ON-LINE ANNUAL SUBSCRIPTION FORM
Contact Details
Name
Address
Suburb
City/Postcode
Phone
..
-ENDS---
The processing done in -
---ENDS
All the best
Chris
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: turning off a E_STRICT or fix for a bad coding habit
Hi Viraj, well from the viewpoint of the PHP developers, it depends if u allow to extend a class before it is been declared. If it is allowed that way, then yes you are right none of the sniped should create an error. If u study the bug report, u will see that the class is extended before it is declared. If u have to declare a calss before u can extend it and it is set as a rule, then yes the interpreter should fire an error. I think in your code must be something similar to this, extention before declaration. I'm not shure but if PHP goes towards variable declaration feature ( PHP 6 ? ), the result would be that extention of a class before declaration will be prohibited. Right now it seems to me that the interpreter is allowing extention before declaration, however takes the first overwriting method as its declaration and of course that would fire the error you have. I personally have no such problems, as since ever I try to program in the way strict languages like JAVA require and found it as best practice. That means e.g. declaration strict before extention/use of functions and classes. I also avoid even NOTICE messages. One last thing, an entry in the PHP buglist doesn't mean it is a bug. It would be helpfull to see the complete code firing this error, but I assume its a bit large to sniip here. ralph_def...@yahoo.de "viraj" wrote in message news:74721f460909270203s723480d3u361ca9a18da43...@mail.gmail.com... > just upgraded to php 5.2.10-2.2 on debian > > now i get this error > > [2048] Declaration of form::bindData() should be compatible with that > of db::bindData() > > i use __autoload to load these classes.. found this bug report > http://bugs.php.net/bug.php?id=46851, i thought it's this new E_STRICT > bit and tried to turn it off, but didn't help. > > this code was working perfect before.. even with this error.. it > works. any idea about a workaround? or some reading suggestions! > > many thanks > > ~viraj -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] turning off a E_STRICT or fix for a bad coding habit
just upgraded to php 5.2.10-2.2 on debian now i get this error [2048] Declaration of form::bindData() should be compatible with that of db::bindData() i use __autoload to load these classes.. found this bug report http://bugs.php.net/bug.php?id=46851, i thought it's this new E_STRICT bit and tried to turn it off, but didn't help. this code was working perfect before.. even with this error.. it works. any idea about a workaround? or some reading suggestions! many thanks ~viraj -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
