php-general Digest 25 Jun 2009 10:03:17 -0000 Issue 6194
Topics (messages 294543 through 294569):
Re: CSV file
294543 by: Richard Heyes
294545 by: Eddie Drapkin
294554 by: Jonathan Tapicer
294568 by: Richard Heyes
Re: I've some doubts if I should go with 5.2 or go already with 5.3 (for
a course)
294544 by: Michael A. Peters
294546 by: Daniel Brown
294548 by: Robert Cummings
294549 by: Michael A. Peters
294557 by: Paul M Foster
Re: idiot proofing
294547 by: Shawn McKenzie
294552 by: Bastien Koert
294553 by: Shawn McKenzie
294555 by: Bastien Koert
294556 by: Michael A. Peters
294561 by: Asher Snyder
294562 by: Asher Snyder
How to sort a two-D ARRAY
294550 by: salmarayan
294551 by: salmarayan
Re: Progressbar
294558 by: Paul M Foster
294567 by: Colin Guthrie
294569 by: Michael A. Peters
Unable to load dynamic php_oci8.dll
294559 by: Raj
294560 by: Kun Niu
294563 by: Raj
PHP doesn't use php.ini
294564 by: Tir
294566 by: Tir
PHP doesn't see php.ini
294565 by: Tir
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi,
> To do the line count first, you have to read the whole file, how would
> you do it?
Something like this:
$fp = fopen('/tmp/foo', 'r');
$count = 0;
while (!feof($fp)) {
fgets($fp);
++$count;
}
--
Richard Heyes
HTML5 graphing: RGraph (www.rgraph.net - updated 20th June)
PHP mail: RMail (www.phpguru.org/rmail)
PHP datagrid: RGrid (www.phpguru.org/rgrid)
PHP Template: RTemplate (www.phpguru.org/rtemplate)
PHP SMTP: http://www.phpguru.org/smtp
--- End Message ---
--- Begin Message ---
or $arr = file('foo.csv'); $count = count($arr);
On Wed, Jun 24, 2009 at 5:19 PM, Richard Heyes<rich...@php.net> wrote:
> Hi,
>
>> To do the line count first, you have to read the whole file, how would
>> you do it?
>
> Something like this:
>
> $fp = fopen('/tmp/foo', 'r');
> $count = 0;
>
> while (!feof($fp)) {
> fgets($fp);
> ++$count;
> }
>
> --
> Richard Heyes
> HTML5 graphing: RGraph (www.rgraph.net - updated 20th June)
> PHP mail: RMail (www.phpguru.org/rmail)
> PHP datagrid: RGrid (www.phpguru.org/rgrid)
> PHP Template: RTemplate (www.phpguru.org/rtemplate)
> PHP SMTP: http://www.phpguru.org/smtp
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Well, you are reading the whole file there (and throwing the data you
read not assigning the fgets result to anything), and then to store it
in the database you need to read it again, so you read the file twice.
It will probably better to store the data you read the first time in
an array and then store it in the database, that way you read it only
once.
Anyway, doing it by file size is better.
On Wed, Jun 24, 2009 at 6:19 PM, Richard Heyes<rich...@php.net> wrote:
> Hi,
>
>> To do the line count first, you have to read the whole file, how would
>> you do it?
>
> Something like this:
>
> $fp = fopen('/tmp/foo', 'r');
> $count = 0;
>
> while (!feof($fp)) {
> fgets($fp);
> ++$count;
> }
>
> --
> Richard Heyes
> HTML5 graphing: RGraph (www.rgraph.net - updated 20th June)
> PHP mail: RMail (www.phpguru.org/rmail)
> PHP datagrid: RGrid (www.phpguru.org/rgrid)
> PHP Template: RTemplate (www.phpguru.org/rtemplate)
> PHP SMTP: http://www.phpguru.org/smtp
>
--- End Message ---
--- Begin Message ---
Hi,
> Well, you are reading the whole file there (and throwing the data you
> read not assigning the fgets result to anything), and then to store it
> in the database you need to read it again, so you read the file twice.
> It will probably better to store the data you read the first time in
> an array and then store it in the database, that way you read it only
> once.
No, it's not. If the file is large then you could end up reading megs
into memory. If physical memory is low then the pagefile will come
into play and you'll get a lot of disk accesses. Reading 1 line at a
time is far more efficient and with larger files will be faster.
--
Richard Heyes
HTML5 graphing: RGraph (www.rgraph.net - updated 20th June)
PHP mail: RMail (www.phpguru.org/rmail)
PHP datagrid: RGrid (www.phpguru.org/rgrid)
PHP Template: RTemplate (www.phpguru.org/rtemplate)
PHP SMTP: http://www.phpguru.org/smtp
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
* snip *
No. It is not.
The web root should be read only.
Please cite references as to why it should be read only. Please explain
why the feature exists if it should not be so.
The feature exists because the web server runs as a standard user, and
standard users have permission to directories they have write permission to.
In a properly administered web server, the apache user only has read
permission to the contents of the web root.
I could make the same argument that making use of a webserver opens
you up to any vulnerability in the webserver that may provide access
to the entire filesystem. The intended purpose of the webserver is
not to allow such access when configured properly, and so it is an
exceptional circumstance when such security is compromised.
These compromises do happen, which is why the web root should be read
only to the web server and any data the web server has write access to
should be validated before it is used.
And the operating system?
Operating system doesn't matter.
The web server should not have write permission to directories/files
within the web root.
It isn't hard to do.
It's hard to create a helpful application when fort knox is your
delivery location. I'm not saying there's a problem with Fort Knoxes in
the world, but this isn't necessary for everyone. if it were we wouldn't
have banks, we wouldn't have credit unions, we'd all be going to Fort
Knox to make our deposits and withdrawals. One size does NOT fit all.
I'm sick and tired of owned boxes spamming me.
It's been so bad at time I though my spam filters were crap, and I
looked at the large number of messages they did catch.
I'm tired of XSS attacks. I run with scripting disabled for most sites,
which makes the web a pain in the arse because most web pages out there
are done by clueless hacks who expect me to allow them to send arbitrary
code to be executed on my machine.
Very often these XSS attacks are the result of compromised boxes.
Yes, people need to run secure web servers. Yes, application developers
need to take security into consideration before uploading their project
for public consumption.
Kind of scenario that happens all the time:
Jane, a non technical person, has a soft spot for the Desert Tortoise.
She buys a cheap web account and sets up a blog on it. She gives an
account to her friend betty.
Betty's webmail account is compromised by an XSS attack (happens all the
time, even has happened to gmail). Now the attacker has access to
Betty's mail including her password. He logs on to Betty's account and
modifies a blog, adding an image that isn't an image, and either
successfully now has an XSS attack on Jane's blog, or possibly have even
rooted the server Jane's account is with through a local exploit he was
able to get the apache server to run because he was able to upload a
perl or php script inside the web root.
Just as an example, I was looking for a simplistic blog to add to my
website. The install script didn't even work because it used system
and exec calls which many servers (including mine) do not allow.
This is a problem with your setup. I make use of exec() calls often
enough when within a Linux environment. If this is a known parameter of
the application, then it is not incorrect to use exec(). It is common to
build upon existing shell binaries.
Vast majority of stuff can be done with pure php via php modules and
extensions. Allowing exec() or system() is extremely dangerous.
Yes, I do allow it for my squirrelmail install, but fixing that is on my
todo list.
A specific instance of a poorly designed application does not stand as
the model for all applications. There are countless examples of bad
programming and exploits at pretty much every level of a system. These
do not suggest we should not use computers.
No, but it does suggest we need to think about security, such as not
having web server writeable files in the web root and not having the web
server write files it then parses as php (extremely common practice for
app configuration files) - especially when it is cake to use a database
or flat file (IE xml) for configuration, allowing parsing of the values
read to make sure they are sane and avoiding addition of declarations
you don't want.
So with some hand waving and fluttering of your eyes you've eliminated
(or at least completely ignored) all the Windows machines in the world.
No. I haven't.
For years, the LaTeX community had a package manager for Windows
installs that was in fact superior to any TeX package management on any
UN*X environment I ever saw.
Now with TeXLive tlmgr there is finally good TeX package management for
every OS.
There are far more php users than TeX users, there is no good reason why
such a package manager does not already exist for php in the Windows
environment. It would be an excellent addition to the WAMP stack.
The Windows PHP community not getting their act together is not an
excuse for sloppy insecure default installs, especially since there is
nothing about Windows that prevents a proper install.
If Jane from the example above can't read and follow simple instructions
to install a blog on her Desert Tortoise conservation site, she either
needs to read a book or hire someone to can. By making things "easy" for
her, you are not doing her a service, you are doing her a dis-service
because her install is now vulnerable, and she probably doesn't even
comprehend why.
Her site may end up being blocked by browsers for having identified
malware, she won't even understand why, and will just wipe everything
and start over with the same insecure setup that got her into trouble in
the first place.
--- End Message ---
--- Begin Message ---
On Wed, Jun 24, 2009 at 17:19, Michael A. Peters<mpet...@mac.com> wrote:
>
> Jane, a non technical person [...]
>
> Betty's webmail account is compromised [...]
Bottom line: hax0r5 hate g1rls.
--
</Daniel P. Brown>
daniel.br...@parasane.net || danbr...@php.net
http://www.parasane.net/ || http://www.pilotpig.net/
50% Off All Shared Hosting Plans at PilotPig: Use Coupon DOW10000
--- End Message ---
--- Begin Message ---
Michael A. Peters wrote:
Robert Cummings wrote:
* snip *
No. It is not.
The web root should be read only.
Please cite references as to why it should be read only. Please explain
why the feature exists if it should not be so.
The feature exists because the web server runs as a standard user, and
standard users have permission to directories they have write permission to.
In a properly administered web server, the apache user only has read
permission to the contents of the web root.
I could make the same argument that making use of a webserver opens
you up to any vulnerability in the webserver that may provide access
to the entire filesystem. The intended purpose of the webserver is
not to allow such access when configured properly, and so it is an
exceptional circumstance when such security is compromised.
These compromises do happen, which is why the web root should be read
only to the web server and any data the web server has write access to
should be validated before it is used.
And the operating system?
Operating system doesn't matter.
The web server should not have write permission to directories/files
within the web root.
It isn't hard to do.
It's hard to create a helpful application when fort knox is your
delivery location. I'm not saying there's a problem with Fort Knoxes in
the world, but this isn't necessary for everyone. if it were we wouldn't
have banks, we wouldn't have credit unions, we'd all be going to Fort
Knox to make our deposits and withdrawals. One size does NOT fit all.
I'm sick and tired of owned boxes spamming me.
It's been so bad at time I though my spam filters were crap, and I
looked at the large number of messages they did catch.
I'm tired of XSS attacks. I run with scripting disabled for most sites,
which makes the web a pain in the arse because most web pages out there
are done by clueless hacks who expect me to allow them to send arbitrary
code to be executed on my machine.
Very often these XSS attacks are the result of compromised boxes.
Yes, people need to run secure web servers. Yes, application developers
need to take security into consideration before uploading their project
for public consumption.
Kind of scenario that happens all the time:
Jane, a non technical person, has a soft spot for the Desert Tortoise.
She buys a cheap web account and sets up a blog on it. She gives an
account to her friend betty.
Betty's webmail account is compromised by an XSS attack (happens all the
time, even has happened to gmail). Now the attacker has access to
Betty's mail including her password. He logs on to Betty's account and
modifies a blog, adding an image that isn't an image, and either
successfully now has an XSS attack on Jane's blog, or possibly have even
rooted the server Jane's account is with through a local exploit he was
able to get the apache server to run because he was able to upload a
perl or php script inside the web root.
Just as an example, I was looking for a simplistic blog to add to my
website. The install script didn't even work because it used system
and exec calls which many servers (including mine) do not allow.
This is a problem with your setup. I make use of exec() calls often
enough when within a Linux environment. If this is a known parameter of
the application, then it is not incorrect to use exec(). It is common to
build upon existing shell binaries.
Vast majority of stuff can be done with pure php via php modules and
extensions. Allowing exec() or system() is extremely dangerous.
Yes, I do allow it for my squirrelmail install, but fixing that is on my
todo list.
A specific instance of a poorly designed application does not stand as
the model for all applications. There are countless examples of bad
programming and exploits at pretty much every level of a system. These
do not suggest we should not use computers.
No, but it does suggest we need to think about security, such as not
having web server writeable files in the web root and not having the web
server write files it then parses as php (extremely common practice for
app configuration files) - especially when it is cake to use a database
or flat file (IE xml) for configuration, allowing parsing of the values
read to make sure they are sane and avoiding addition of declarations
you don't want.
So with some hand waving and fluttering of your eyes you've eliminated
(or at least completely ignored) all the Windows machines in the world.
No. I haven't.
For years, the LaTeX community had a package manager for Windows
installs that was in fact superior to any TeX package management on any
UN*X environment I ever saw.
Now with TeXLive tlmgr there is finally good TeX package management for
every OS.
There are far more php users than TeX users, there is no good reason why
such a package manager does not already exist for php in the Windows
environment. It would be an excellent addition to the WAMP stack.
The Windows PHP community not getting their act together is not an
excuse for sloppy insecure default installs, especially since there is
nothing about Windows that prevents a proper install.
If Jane from the example above can't read and follow simple instructions
to install a blog on her Desert Tortoise conservation site, she either
needs to read a book or hire someone to can. By making things "easy" for
her, you are not doing her a service, you are doing her a dis-service
because her install is now vulnerable, and she probably doesn't even
comprehend why.
Her site may end up being blocked by browsers for having identified
malware, she won't even understand why, and will just wipe everything
and start over with the same insecure setup that got her into trouble in
the first place.
I respectfully disagree with your position. Everything you have
described about Jane is also true of an operating system. There are
compromised machines all over the world just because installing an
operating system is so easy. No amount of packaging is going to solve
the problem created by bad software and idiots. Yet we still sell
operating systems to anyone who wants to buy one and set it up. It's the
software that needs to become more secure and robust. This may or may
not mean moving the configuration/module management system out of the
document root. Preferably we would see the flexibility of management
remain as is, with the entire software stack becoming more robust to
prevent such compromises.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
Robert Cummings wrote:
I respectfully disagree with your position. Everything you have
described about Jane is also true of an operating system. There are
compromised machines all over the world just because installing an
operating system is so easy. No amount of packaging is going to solve
the problem created by bad software and idiots.
But php coders writing code that follows basic policy rules does reduce
the problem. Such policies include not writing your app so the install
instructions tell the user to chmod 777 directories and files within the
web root.
Since the OP is teaching a class, that's an important concept student
need to understand.
Yes, there will always be mis-behaving apps. There will also be well
written applications that are vulnerable simply because they use a
vulnerable module or class. Creating a secure development policy and
implementing it greatly reduces your well written application from being
an attack vector when those issues exist, and they will always exist.
Similarly, web developers (php and other) need to start following and
implementing the CSP recommendation at Mozilla.org. In a perfect world
where we could guarantee our web apps were not vulnerable to XSS
injection, a web app would never have to send headers telling the client
what is allowed and from where, but as we don't live in a perfect world,
it is the right thing to do - even though it makes coding a lot more
tedious.
--- End Message ---
--- Begin Message ---
On Wed, Jun 24, 2009 at 05:26:11PM -0400, Daniel Brown wrote:
> On Wed, Jun 24, 2009 at 17:19, Michael A. Peters<mpet...@mac.com> wrote:
> >
> > Jane, a non technical person [...]
> >
> > Betty's webmail account is compromised [...]
>
> Bottom line: hax0r5 hate g1rls.
Or hax0r5 hate grrls.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
PJ wrote:
> I have a bit of a situation.
> I have set up addBooks, editBooks and deleteBooks pages. Before
> complicating my life & mixing them up in one file, I am running tests.
> I'd like to make them idiot proof, up to a point.
> When the page is submitted and the code is parsed, the form inputs
> remain on the screen along with the submit buttons.
> I'm not sure of what is the normal way of closing/hiding/wiping the
> screen output before showing the result output of the operation.
> I do not want a user to resubmit the input which is still in the input
> $strings.
> I am wondering if I should be using some code to clear the inputs like
> unsetting??? sessions or a break or am I doing something wrong with the
> flow of the code?
> I'd like to leave the pages with only the output of success (or failure)
> and links to do another add/edit/delete operation.
> Thanks for any suggestions.
>
I've never tried it, but you can possibly submit to an intermediate page
that stuffs the post vars into a session, echos "please wait" and then
redirects to the page that does the processing. The processing page
gets the sessions vars and does its business.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On Wed, Jun 24, 2009 at 5:30 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
> PJ wrote:
>> I have a bit of a situation.
>> I have set up addBooks, editBooks and deleteBooks pages. Before
>> complicating my life & mixing them up in one file, I am running tests.
>> I'd like to make them idiot proof, up to a point.
>> When the page is submitted and the code is parsed, the form inputs
>> remain on the screen along with the submit buttons.
>> I'm not sure of what is the normal way of closing/hiding/wiping the
>> screen output before showing the result output of the operation.
>> I do not want a user to resubmit the input which is still in the input
>> $strings.
>> I am wondering if I should be using some code to clear the inputs like
>> unsetting??? sessions or a break or am I doing something wrong with the
>> flow of the code?
>> I'd like to leave the pages with only the output of success (or failure)
>> and links to do another add/edit/delete operation.
>> Thanks for any suggestions.
>>
>
> I've never tried it, but you can possibly submit to an intermediate page
> that stuffs the post vars into a session, echos "please wait" and then
> redirects to the page that does the processing. The processing page
> gets the sessions vars and does its business.
>
> --
> Thanks!
> -Shawn
> http://www.spidean.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
What about placing the contents in different divs and showing hiding
those divs on submit? Then using AJAX to update the server / database
with the requested operation?
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Bastien Koert wrote:
> On Wed, Jun 24, 2009 at 5:30 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
>> PJ wrote:
>>> I have a bit of a situation.
>>> I have set up addBooks, editBooks and deleteBooks pages. Before
>>> complicating my life & mixing them up in one file, I am running tests.
>>> I'd like to make them idiot proof, up to a point.
>>> When the page is submitted and the code is parsed, the form inputs
>>> remain on the screen along with the submit buttons.
>>> I'm not sure of what is the normal way of closing/hiding/wiping the
>>> screen output before showing the result output of the operation.
>>> I do not want a user to resubmit the input which is still in the input
>>> $strings.
>>> I am wondering if I should be using some code to clear the inputs like
>>> unsetting??? sessions or a break or am I doing something wrong with the
>>> flow of the code?
>>> I'd like to leave the pages with only the output of success (or failure)
>>> and links to do another add/edit/delete operation.
>>> Thanks for any suggestions.
>>>
>> I've never tried it, but you can possibly submit to an intermediate page
>> that stuffs the post vars into a session, echos "please wait" and then
>> redirects to the page that does the processing. The processing page
>> gets the sessions vars and does its business.
>>
>> --
>> Thanks!
>> -Shawn
>> http://www.spidean.com
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> What about placing the contents in different divs and showing hiding
> those divs on submit? Then using AJAX to update the server / database
> with the requested operation?
>
That's a good one, however I'm assuming you haven't been following PJ's
posts :-) Once he tries AJAX, I feel for the js.general and
ajax.general folks!
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On Wed, Jun 24, 2009 at 8:24 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
> Bastien Koert wrote:
>> On Wed, Jun 24, 2009 at 5:30 PM, Shawn McKenzie<nos...@mckenzies.net> wrote:
>>> PJ wrote:
>>>> I have a bit of a situation.
>>>> I have set up addBooks, editBooks and deleteBooks pages. Before
>>>> complicating my life & mixing them up in one file, I am running tests.
>>>> I'd like to make them idiot proof, up to a point.
>>>> When the page is submitted and the code is parsed, the form inputs
>>>> remain on the screen along with the submit buttons.
>>>> I'm not sure of what is the normal way of closing/hiding/wiping the
>>>> screen output before showing the result output of the operation.
>>>> I do not want a user to resubmit the input which is still in the input
>>>> $strings.
>>>> I am wondering if I should be using some code to clear the inputs like
>>>> unsetting??? sessions or a break or am I doing something wrong with the
>>>> flow of the code?
>>>> I'd like to leave the pages with only the output of success (or failure)
>>>> and links to do another add/edit/delete operation.
>>>> Thanks for any suggestions.
>>>>
>>> I've never tried it, but you can possibly submit to an intermediate page
>>> that stuffs the post vars into a session, echos "please wait" and then
>>> redirects to the page that does the processing. The processing page
>>> gets the sessions vars and does its business.
>>>
>>> --
>>> Thanks!
>>> -Shawn
>>> http://www.spidean.com
>>>
>>> --
>>> PHP General Mailing List (http://www.php.net/)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> What about placing the contents in different divs and showing hiding
>> those divs on submit? Then using AJAX to update the server / database
>> with the requested operation?
>>
> That's a good one, however I'm assuming you haven't been following PJ's
> posts :-) Once he tries AJAX, I feel for the js.general and
> ajax.general folks!
>
> --
> Thanks!
> -Shawn
> http://www.spidean.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Well, I have followed PJ's posts and agree that this [AJAX] is
something that he's not ready for yet.
@PJ, the whole submit / process/ redraw the form only takes a few
seconds and the simplest thing is to just place a spinning 'buy' gif
image in the center of the page to let people know something is
working
--
Bastien
Cat, the other other white meat
--- End Message ---
--- Begin Message ---
Bastien Koert wrote:
That's a good one, however I'm assuming you haven't been following PJ's
posts :-) Once he tries AJAX, I feel for the js.general and
ajax.general folks!
Well, I have followed PJ's posts and agree that this [AJAX] is
something that he's not ready for yet.
Not to mention, when your site depends upon ajax, it doesn't work for
those who disable scripting, so a solution that doesn't involve js
really should be developed anyway.
--- End Message ---
--- Begin Message ---
He can even use http://www.ajaxload.info/ to create his own loading circle
to just embed the code. He can then image's visibility to the css property
display:none and on the form submit he can do a JavaScript
"document.getElementById(id).style.visibility = 'visible';" , assuming he
gave the object an id and make it visible.
While this post might feel too instructional the fact that you joked PJ
wasn't ready for AJAX made want to put in a bit more clarity. If this isn't
clear enough, please let me know and I'll paste the appropriate markup and
js.
-----Original Message-----
From: Michael A. Peters [mailto:mpet...@mac.com]
Sent: Wednesday, June 24, 2009 10:36 PM
To: Bastien Koert
Cc: Shawn McKenzie; php-gene...@lists.php.net
Subject: Re: [PHP] Re: idiot proofing
Bastien Koert wrote:
>>>
>> That's a good one, however I'm assuming you haven't been following PJ's
>> posts :-) Once he tries AJAX, I feel for the js.general and
>> ajax.general folks!
>>
>
> Well, I have followed PJ's posts and agree that this [AJAX] is
> something that he's not ready for yet.
Not to mention, when your site depends upon ajax, it doesn't work for
those who disable scripting, so a solution that doesn't involve js
really should be developed anyway.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
[EDITED FOR MISTAKES AND TYPOS]
He can even use http://www.ajaxload.info/ to create his own loading circle
to hide on the page. He can hide the image's visibility by using the css
property display:none and on the form submit he can do a JavaScript
"document.getElementById(id).style.display = '';" , assuming he gave the
object an id and make it visible.
While this post might feel too instructional the fact that you joked PJ
wasn't ready for AJAX made want to put in a bit more clarity. If this isn't
clear enough, please let me know and I'll paste the appropriate markup and
js.
-----Original Message-----
From: Michael A. Peters [mailto:mpet...@mac.com]
Sent: Wednesday, June 24, 2009 10:36 PM
To: Bastien Koert
Cc: Shawn McKenzie; php-gene...@lists.php.net
Subject: Re: [PHP] Re: idiot proofing
Bastien Koert wrote:
>>>
>> That's a good one, however I'm assuming you haven't been following PJ's
>> posts :-) Once he tries AJAX, I feel for the js.general and
>> ajax.general folks!
>>
>
> Well, I have followed PJ's posts and agree that this [AJAX] is
> something that he's not ready for yet.
Not to mention, when your site depends upon ajax, it doesn't work for
those who disable scripting, so a solution that doesn't involve js
really should be developed anyway.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Can Anyone tell me how to sort two D Array
for example like this one based on the gain
Array ( [0] => Array ( [company_name] =>X [gain] => 0.2 ) [1] => Array (
[company_name] => y[gain] => 0.34 )[2]1] => Array ( [company_name] =>z[gain]
=> 2 ) )
Thanks in advance
--
View this message in context:
http://www.nabble.com/How-to-sort-a-two-D-ARRAY-tp24193925p24193925.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
Can Anyone tell me how to sort two D Array in Descending Order
for example like this one based on the gain
Array ( [0] => Array ( [company_name] =>X [gain] => 0.2 ) [1] => Array (
[company_name] => y[gain] => 0.34 )[2]1] => Array ( [company_name] =>z[gain]
=> 2 ) )
Thanks in advance
--
View this message in context:
http://www.nabble.com/How-to-sort-a-two-D-ARRAY-tp24193925p24193925.html
Sent from the PHP - General mailing list archive at Nabble.com.
--- End Message ---
--- Begin Message ---
On Wed, Jun 24, 2009 at 10:24:21AM -0400, tedd wrote:
> At 7:55 AM +0200 6/24/09, Teun Lassche wrote:
>> I'm making an upload script with PHP, is there a way I can show a
>> progressbar while uploading?
>>
>> --
>> Teun Lassche
>
> It's not a progress bar, but it's a heck of a lot simpler:
>
> http://webbytedd.com/bb/wait/
>
> The biggest problem in uploading a file is figuring out how large it
> is. You can't find that out in php and Javascript is limited in what
> information it can access. I found the problem more trouble than it
> was worth to fix. Besides, what does the user need to see while an
> operation is underway?
I like the last one (#39). Perfect for a "progress bar". ;-}
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
'Twas brillig, and tedd at 24/06/09 15:24 did gyre and gimble:
The biggest problem in uploading a file is figuring out how large it is.
You can't find that out in php
Well you can find it out with the uploadprogress or APC PECL extensions.
If you use Zend Framework then it has a progress bar for file upload
built in.
http://www.framework.zend.com/manual/en/zend.file.html#zend.file.transfer.introduction.uploadprogress
HTHs
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
--- End Message ---
--- Begin Message ---
Colin Guthrie wrote:
'Twas brillig, and tedd at 24/06/09 15:24 did gyre and gimble:
The biggest problem in uploading a file is figuring out how large it
is. You can't find that out in php
Well you can find it out with the uploadprogress or APC PECL extensions.
http://www.clfsrpm.net/upprogress/index.php
example of form and all related files, with soure, demonstrating how
uploadprogress works to make a progress bar.
My bar is kind of low tech but it works.
--- End Message ---
--- Begin Message ---
Hi,
I get the following error when i start the Apache Server.
PHP Startup: Unable to load dynamic library
'F:\\Apps\\PHP\\ext\\php_oci8.dll' - The specified procedure could not
be found.\r\n in Unknown on line 0
I dont see there is any issue with the dir as well as the ini file.
everything is in place.
oracle version in 9.2
windows XP
PHP 5.2.10
Kindly let me know, what needs to be checked.
Thank you
Raj
--- End Message ---
--- Begin Message ---
http://forums.oracle.com/forums/thread.jspa?threadID=412805
Will this be of help?
2009/6/25 Raj <rameshs...@gmail.com>
> Hi,
>
> I get the following error when i start the Apache Server.
>
> PHP Startup: Unable to load dynamic library
> 'F:\\Apps\\PHP\\ext\\php_oci8.dll' - The specified procedure could not
> be found.\r\n in Unknown on line 0
>
> I dont see there is any issue with the dir as well as the ini file.
> everything is in place.
>
> oracle version in 9.2
> windows XP
> PHP 5.2.10
>
> Kindly let me know, what needs to be checked.
>
> Thank you
>
> Raj
>
--
牛坤
MSN:haoniu...@hotmail.com <msn%3ahaoniu...@hotmail.com>
--- End Message ---
--- Begin Message ---
i tired this earlier, it is not working.
On Thu, Jun 25, 2009 at 9:54 AM, Kun Niu <haoniu...@gmail.com> wrote:
> http://forums.oracle.com/forums/thread.jspa?threadID=412805
> Will this be of help?
>
> 2009/6/25 Raj <rameshs...@gmail.com>
>
> Hi,
>>
>> I get the following error when i start the Apache Server.
>>
>> PHP Startup: Unable to load dynamic library
>> 'F:\\Apps\\PHP\\ext\\php_oci8.dll' - The specified procedure could not
>> be found.\r\n in Unknown on line 0
>>
>> I dont see there is any issue with the dir as well as the ini file.
>> everything is in place.
>>
>> oracle version in 9.2
>> windows XP
>> PHP 5.2.10
>>
>> Kindly let me know, what needs to be checked.
>>
>> Thank you
>>
>> Raj
>>
>
>
>
> --
> 牛坤
> MSN:haoniu...@hotmail.com <msn%3ahaoniu...@hotmail.com>
>
--
Thank you
Ramesh S Raj
--- End Message ---
--- Begin Message ---
When i installed PHP, I had written to my httpd.conf PHPIniDir "c:/php". But
phpinfo() returns "C:\WINDOWS" in "Configuration File (php.ini) Path" row
and right path to my php.ini in "Loaded Configuration File". It looks like
php.ini really isn't used. I think so because when i try to enable MySQL it
doesn't work ("extension=php_mysql.dll", "extension=php_mysqli.dll" and
"extension=php_pdo_mysql.dll" is uncommented, "extension_dir" is correct,
libmysql.dll is copied to C:\WINDOWS\system32). I've tried to write to
php.ini an abracadabra. But I havent received an error as i expected. I've
tried to rename php.ini. phpinfo() has returned "(none)" in "Loaded
Configuration File" row instead of "c:\php\php.ini" as that was before. But
PHP still worked. It worked without php.ini. It seems very strange. I've
searched another php.ini on my system. There is no another one. What's
wrong? Why doesn't PHP use php.ini file?
--- End Message ---
--- Begin Message ---
Sorry for double posting
--- End Message ---
--- Begin Message ---
When i installed PHP, I had written to my httpd.conf PHPIniDir "c:/php". But
phpinfo() returns "C:\WINDOWS" in "Configuration File (php.ini) Path" row
and right path to my php.ini in "Loaded Configuration File". It looks like
php.ini really isn't used. I think so because when i try to enable MySQL
extension it doesn't work ("extension=php_mysql.dll",
"extension=php_mysqli.dll" and "extension=php_pdo_mysql.dll" is uncommented,
"extension_dir" is correct, libmysql.dll is copied to C:\WINDOWS\system32).
I've tried to write to php.ini an abracadabra. But I haven't received an
error as i expected. I've tried to rename php.ini. phpinfo() has returned
"(none)" in "Loaded Configuration File" row instead of "c:\php\php.ini" as
that was before. But PHP still worked. It worked without php.ini. It seems
very strange. I've searched another php.ini on my system. There is no
another one. What's wrong? Why doesn't PHP use php.ini file?
--- End Message ---
