|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general Digest 26 Apr 2006 05:50:46 -0000 Issue 4093
php-general-digest-help
lists.php.net
Date: Wed Apr 26 2006 - 00:50:46 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 26 Apr 2006 05:50:46 -0000 Issue 4093
Topics (messages 234715 through 234768):
Re: Using Header() to pass information...
234715 by: Stut
234719 by: Robert Cummings
234729 by: Richard Lynch
234734 by: Stut
234745 by: Richard Lynch
Re: Serveral forms in a page.
234716 by: Stut
234740 by: Richard Lynch
Upload Progress Meter - what's the latest?
234717 by: D. Dante Lorenso
234732 by: Richard Lynch
234746 by: Jochem Maas
234748 by: D. Dante Lorenso
234753 by: Richard Lynch
234754 by: Richard Lynch
234755 by: Richard Lynch
234758 by: Jay Blanchard
234760 by: D. Dante Lorenso
234762 by: D. Dante Lorenso
Re: phpmailer problem with spam score
234718 by: Stut
234720 by: Manuel Lemos
234738 by: Richard Lynch
234739 by: Richard Lynch
234763 by: Jochem Maas
234764 by: Sameer N Ingole
mccabes complexity parser
234721 by: Mark Steudel
Forms Validation library
234722 by: Murtaza Chang
234726 by: Manuel Lemos
234736 by: Jens Kleikamp
Re: Permission problem
234723 by: tedd
234733 by: Richard Lynch
Upload Progress Bar (PHP/AJAX?)
234724 by: Rahul S. Johari
Install GD2 Library - $ Reward
234725 by: Aleksander Davidsen
234727 by: Jochem Maas
Re: Reusable Singleton pattern using PHP5
234728 by: Jochem Maas
Using linkDisplayFields of FormBuilder
234730 by: Tom
234731 by: Jochem Maas
234747 by: Richard Lynch
234750 by: Tom
234752 by: Jochem Maas
Re: New image already cached. (SOLVED)
234735 by: Richard Lynch
Amazon WSDL
234737 by: John Meyer
234741 by: Richard Collyer
234742 by: Richard Lynch
234743 by: Jochem Maas
234744 by: Jochem Maas
234759 by: John Meyer
Re: cURL & cookies
234749 by: Richard Lynch
Re: [W O T] mccabes complexity parser
234751 by: Jochem Maas
need help to put input text value into url
234756 by: Patrick Aljord
234757 by: Ing. Edwin Cruz
PHP/LDAP Setup Problem
234761 by: Crone, James
Removing special chars
234765 by: Gerry Danen
234766 by: Gerry D
234767 by: Ligaya Turmelle
Protecting index.php
234768 by: P. Guethlein
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Richard Lynch wrote:
> If you are doing your sanitization/filtering/validation correctly, you
> shouldn't even be READING $_POST after the first 3 lines of your PHP
> code anyway. (Okay, maybe first 10 lines.)
The same goes for $_GET data also.
> The longer you use header("Location: ...") the more you realize how
> it's just not a substitute for a well-structured web application.
>
> Just my 2 cents.
As long as we're throwing foreign money into the ring, I'd just like to
say that I make a point of redirecting to another page after a post
request, otherwise you get unsightly errors in the browser when the user
tries to use the back/forward buttons. Other than in that situation I
make sure I do includes rather than redirects.
-Stut
attached mail follows:
On Tue, 2006-04-25 at 13:47, Stut wrote:
> Richard Lynch wrote:
> > If you are doing your sanitization/filtering/validation correctly, you
> > shouldn't even be READING $_POST after the first 3 lines of your PHP
> > code anyway. (Okay, maybe first 10 lines.)
>
> The same goes for $_GET data also.
>
> > The longer you use header("Location: ...") the more you realize how
> > it's just not a substitute for a well-structured web application.
> >
> > Just my 2 cents.
>
> As long as we're throwing foreign money into the ring, I'd just like to
> say that I make a point of redirecting to another page after a post
> request, otherwise you get unsightly errors in the browser when the user
> tries to use the back/forward buttons. Other than in that situation I
> make sure I do includes rather than redirects.
Agreed. My form engine submits to the same page and uses the validation
engine to check the fields, if any fails, it stays where it is and the
fields will be marked and error messages about validation presented.
When the user submits clean data, the form performs a redirect to the
URL specified to the form engine as the action... if the action URL
happens to be the same page, then it skips the redirect entirely.
In my applications though, literal includes are rare within the code
itself and almost exclusively only used to extend other classes since
the framework performs the includes according to module/component
descriptions. Almost everything is decoupled from everything else.
Cheers,
Rob.
--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
attached mail follows:
On Tue, April 25, 2006 12:47 pm, Stut wrote:
> As long as we're throwing foreign money into the ring, I'd just like
> to
> say that I make a point of redirecting to another page after a post
> request, otherwise you get unsightly errors in the browser when the
> user
> tries to use the back/forward buttons. Other than in that situation I
> make sure I do includes rather than redirects.
There are viable alternatives to breaking the back button...
Not to mention that it's sometimes VERY useful to be able to use a
browser that lets one re-submit a form with altered data with the back
button, rather than going through the process from the beginning.
Though that is application-specific.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 12:47 pm, Stut wrote:
>> As long as we're throwing foreign money into the ring, I'd just like
>> to
>> say that I make a point of redirecting to another page after a post
>> request, otherwise you get unsightly errors in the browser when the
>> user
>> tries to use the back/forward buttons. Other than in that situation I
>> make sure I do includes rather than redirects.
>
> There are viable alternatives to breaking the back button...
>
> Not to mention that it's sometimes VERY useful to be able to use a
> browser that lets one re-submit a form with altered data with the back
> button, rather than going through the process from the beginning.
> Though that is application-specific.
Indeed, but that's not the issue. Consider these sequences...
1) User fills in form and submits it
2) Form action script processes the form and simply outputs the page
Then either...
3a) User hits back... form gets shown, hopefully (dependant on
browser/cache settings) with the data the user had entered previously on
it - No bad stuff here
or...
3b) User clicks on a normal link, goes to another page then hits back...
user sees an evil-looking and unexpected question asking whether to
resubmit the form values. Most users I know will hit OK because they
don't understand it. This is bad, form gets submitted again. In the case
where they hit cancel instead they end up with an error message and have
effectively left your site... also very bad.
Better...
1) User fills in form and submits it
2) Form action script processes the form and redirects to the next page
As before, either...
3a) User hits back... same thing as before happens, form is displayed
hopefully with previously entered data
or...
3b) User clicks on a normal link, then hits back... since the post page
never ended up in the browser history this action has the same effect as
in 3a, showing the form hopefully with previously entered data. If the
user then submits the form again that's their choice, but in theory at
least it's a better informed choice than the previous scenario.
In my most humble opinion, any post handler that doesn't do a redirect
after processing the form is bad. Hope that made sense.
-Stut
attached mail follows:
On Tue, April 25, 2006 4:47 pm, Stut wrote:
> 3b) User clicks on a normal link, goes to another page then hits
> back...
> user sees an evil-looking and unexpected question asking whether to
> resubmit the form values. Most users I know will hit OK because they
> don't understand it. This is bad, form gets submitted again.
It's only "bad" if your application is silly enough to accept that
duplicate information twice in a row, and it shouldn't have accepted
it...
> In the
> case
> where they hit cancel instead they end up with an error message and
> have
> effectively left your site... also very bad.
Aroo?
How does cancel effectively "leave my site"?
They're still ON my site.
> In my most humble opinion, any post handler that doesn't do a redirect
> after processing the form is bad. Hope that made sense.
In my opinion, since the user CAN manage with fast-clicking, to
"catch" the processing script before the redirect, and because they
can STILL manage to re-submit the form, without the NORMAL browser
behaviour they have come to expect, you're just BREAKING browser
functionality, without actually solving the problem 100%...
Guess we'll just have to agree to disagree, hunh?
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
William Stokes wrote:
> Mulkku?
'Cause insulting us is the way to convince this list to answer your
irrelevant questions? Seriously tho, if I may, go join an
HTML/Javascript list for these questions and try to stick with PHP on
this one.
-Stut
attached mail follows:
On Tue, April 25, 2006 3:46 am, William Stokes wrote:
> I have several forms in a page which is ok otherwise but the reset
> buttons
> doesn't clear anything that is queried from DB and printed to the text
> fields. Any idea how to create Reset buttons that clear the fields
> even when
> the data is not from user input? Or do I have to create reset buttons
> that
> are actually submit buttons and play with variables after that or
> something
> like that? Javascript is the way I don't want to go...
If you rule out JavaScript (the correct solution, imho) then you
pretty much have correctly identified the only other option I know of:
"are actually submit buttons and play with variables after that or"
This will be dog-slow as it requires going back and forth from browser
to web-server.
To keep this on-topic, I presume that IF you could get the users to
install the PHPScript plug-in that Wez Furlong wrote, you could then
write client-side PHP to do what you want... Though I have no idea
how stable that is, if anybody anywhere has actually installed it, nor
if it actually provides the functionality I presumed it does.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
All,
I'm trying to figure out which direction the PHP community is going when
it comes to an upload progress meter. I've just recently discovered the
ease of installing packages using PECL and see that this package is defined:
http://pecl.php.net/package/postparser
Yet, there does not appear to be any code which I can install for this
module. Meanwhile, I find this project here:
http://pdoru.from.ro/ (upload-progress-meter-v4.1)
I have install this patch and built an RPM to aid in mass deployment on
our servers and it works well enough with a few minor unresolved bugs.
I'm trying to avoid custom patches in PHP as I work on migrating toward
clean PHP 5.1.2 and eliminate BC dependencies. Does anyone know
anything about the upload progress meter development and can point me in
a better direction?
Dante
attached mail follows:
On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote:
> I'm trying to figure out which direction the PHP community is going
> when
> it comes to an upload progress meter.
Since that meter would necessarily be CLIENT side, the PHP community
is pretty much ignoring it, since PHP runs on the SERVER.
Anything you see with "PHP" "upload progress meter" together has to be
some kind of hack whose under-pinning is NOT PHP at all, but is
JavaScript or similar client-side technology.
Why don't you ask the guys who write BROWSERS why *they* don't provide
a nice API/interface to display progress, or, better yet, why the
browser itself doesn't just do it once and for all for everybody?
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote:
>
>>I'm trying to figure out which direction the PHP community is going
>>when
>>it comes to an upload progress meter.
>
>
> Since that meter would necessarily be CLIENT side, the PHP community
> is pretty much ignoring it, since PHP runs on the SERVER.
>
> Anything you see with "PHP" "upload progress meter" together has to be
> some kind of hack whose under-pinning is NOT PHP at all, but is
> JavaScript or similar client-side technology.
>
> Why don't you ask the guys who write BROWSERS why *they* don't provide
> a nice API/interface to display progress, or, better yet, why the
> browser itself doesn't just do it once and for all for everybody?
let's consider that 99% of all clients would want a 'nice' looking
progress bar (in the same way they often asking me to do something
about the std form fields, which they consider ugly).
i.e. it would just be moving the problem somewhere else in practical
terms, in so far as we'd probably still have to figure out hacks to make
the bl**dy thing look nice (in the eyes of the guy/girl paying the bill ;-)
and for the record there are other languages that support a progress bar
idiom ... php being the pragmatic thing that it is should imho entertain this
idea more seriously (waiting for browsers to implement it or ignoring the
continually recurring request for such functionality) .... that said
Richard has a very strong argument.
>
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote:
>
>> I'm trying to figure out which direction the PHP community is going
>>
> when it comes to an upload progress meter.Since that meter would necessarily be CLIENT side, the PHP community
> is pretty much ignoring it, since PHP runs on the SERVER.
>
Everything PHP returns from a server is "client side", so your argument
seems to indicate that we need to write all of our HTML using JavaScript
also. No, the fact is that a client-side GUI does NOT exist, so we need
to build it ourselves using the tools we have. I do not have source
control access to Mozilla, IE, Safari, and Opera, but I can control my
own PHP source.
PHP receives uploads from clients and that client may not even be a web
browser in all cases. From the server side, I need to be able to monitor
* who is currently uploading files,
* which files are being uploaded,
* how big are the files being uploaded,
* how much time has passed since upload began, and
* what percentage of those files is completed
I do not need to return this data to a client at all times. Sometimes I
just want to use the data system administration, analysis, and
tracking. The most popular need would be for returning the information
to the client, however, as you suggest.
Right now, PHP stops executing code from the time an upload begins until
the time it is completed. In other languages like PERL as CGI, you can
read STDIN directly in order to slurp in large POST data like file
attachments. In such a case as that, solving this problem is trivial.
Since PHP locks a programmer out of the loop during parsing and
importing POST and GET variables, we need PHP code to break into that
loop and return callback functions or update internal data structures
directly.
Part of the problem in addition to collection of the data is being able
to share it with other PHP instances. Remember that PHP runs in Apache
in most cases and does not have shared memory between PHP instances.
Therefore, writing the upload data to an external data storage is
necessary. That external storage could be Sqlite, PostgreSQL, MySQL,
files, or even Memcache. I would love to see a memcache-like solution.
But more importantly, I would like to see a solution which is adopted by
the community rather than miserably hacked together then not supported
and abandoned.
> Anything you see with "PHP" "upload progress meter" together has to be
> some kind of hack whose under-pinning is NOT PHP at all, but is
> JavaScript or similar client-side technology.
>
Not true. The graphical display is HTML, DHTML, JavaScript, etc...but
the means of monitoring the progress from the server side MUST be done
with PHP. The code that I have seen so far requires hooks into PHP
which execute callback functions periodically in order to update the
progress of uploaded files as PHP processes input.
> Why don't you ask the guys who write BROWSERS why *they* don't provide
> a nice API/interface to display progress, or, better yet, why the
> browser itself doesn't just do it once and for all for everybody?
>
That is a good idea, and I will recommend it for future solutions. For
short term, that is not the focus of this email.
Dante
attached mail follows:
On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote:
> Richard Lynch wrote:
>> On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote:
>> Anything you see with "PHP" "upload progress meter" together has to
>> be
>> some kind of hack whose under-pinning is NOT PHP at all, but is
>> JavaScript or similar client-side technology.
>>
>
> Not true. The graphical display is HTML, DHTML, JavaScript, etc...but
> the means of monitoring the progress from the server side MUST be done
> with PHP.
I'm sorry. Your original post sounded (to me) like you wanted a
progress meter on the browser (client-side) for the user to see their
files uploaded.
AFAIK, all the tools you referenced were written with that purpose in
mind.
Presumably even the worst browsers have some concept of how large the
file is, and how many bytes have been sent to the server.
So you certainly DO NOT need server-side information to implement a
client-side progress meter of the progress of a file upload!
> The code that I have seen so far requires hooks into PHP
> which execute callback functions periodically in order to update the
> progress of uploaded files as PHP processes input.
Yes, which is a silly place to try and "fix" this for client-side
progress meters, as you then generate traffic back-and-forth from the
client to measure the number of bytes received, instead of the browser
just measuring bytes sent.
> browser in all cases. From the server side, I need to be able to
> monitor
>
> * who is currently uploading files,
> * which files are being uploaded,
> * how big are the files being uploaded,
> * how much time has passed since upload began, and
> * what percentage of those files is completed
>
> I do not need to return this data to a client at all times. Sometimes
> I
> just want to use the data system administration, analysis, and
> tracking. The most popular need would be for returning the
> information
> to the client, however, as you suggest.
In this case, a "meter" isn't going to cut it...
You'd need a battery of meters, for all running processes, or at least
all the ones currently in file upload state.
You'd also need tie-ins to your login/authentication to determin "who
is uploading files" as the only answer inherent to PHP is "the User
set in httpd.conf"
Which files are being uploaded would presumably display both the
original name as sent by the browser, which is not something one can
trust for anything useful, and the /tmp name.
How big they are relies on the browser sending the correct
Content-length: for the upload. I don't know how often they get it
right, but I'm betting that are some pretty common errors in this area
that PHP corrects for already. So your meters would not be accurate
in some (hopefully few) cases.
While I can see where this might be a useful tool to have server-side,
I can suggest several possible ways to implement some portions of it
without hacking PHP source.
First, it's a pretty safe bet that PHP uses a common prefix on the
files being uploaded. So you could write a tool to watch /tmp for
files and get a list of the /tmp names being uploaded.
That would at least tell you how many files are currently in upload
status.
Using filectime and filemtime would tell you the timing info -- Though
Windows will suck (as usual) as it only tracks to the nearest minute
or something...
For tying the filenames back to the users who are logged in, you'd
have to have an onClick() on the submit button which would send some
kind of information (filename, filesize, user) to a PHP script that
would log the upload about to begin in a database. The onClick would
then return false so that the normal form submission process would
kick in.
You would then have to use heuristics about the file timing to "guess"
which files were most likely which -- though you could probably get
pretty accurate about that part, especially if you are willing to code
it so that completed uploads tie back in and eliminate incorrect
guesses.
You're not going to get the level of accuracy you'd have with hacked
PHP source, but you can get enough accuracy for statistical analysis.
It won't be so hot for tracking who's uploading what in real-time, due
to the guessing part -- but after the upload finishes your information
will be as accurate as it can be with hacked source.
Another option is to provide patch to PHP which gives a special INPUT
parameter to a FORM that can be used to provide a callback file to
load, and a callback function within that file to call, and then
modify the file upload routine to load and call that function.
It seems genuinely useful enough to this naive reader, and should not
cause an undue burden for those who don't use it. Check with PHP-Dev
to see if such a patch is likely to be accepted before putting in TOO
much time on it.
HTH
>> Why don't you ask the guys who write BROWSERS why *they* don't
>> provide
>> a nice API/interface to display progress, or, better yet, why the
>> browser itself doesn't just do it once and for all for everybody?
>>
> That is a good idea, and I will recommend it for future solutions. For
> short term, that is not the focus of this email.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote:
> Everything PHP returns from a server is "client side", so your
Oh yeah. I forgot to say...
The above presumption is patently false.
:-)
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
On Tue, April 25, 2006 5:27 pm, Jochem Maas wrote:
> Richard Lynch wrote:
>> On Tue, April 25, 2006 12:18 pm, D. Dante Lorenso wrote:
>> Why don't you ask the guys who write BROWSERS why *they* don't
>> provide
>> a nice API/interface to display progress, or, better yet, why the
>> browser itself doesn't just do it once and for all for everybody?
>
> let's consider that 99% of all clients would want a 'nice' looking
> progress bar (in the same way they often asking me to do something
> about the std form fields, which they consider ugly).
>
> i.e. it would just be moving the problem somewhere else in practical
> terms, in so far as we'd probably still have to figure out hacks to
> make
> the bl**dy thing look nice (in the eyes of the guy/girl paying the
> bill ;-)
Well, yes, if the browser doesn't provide "hooks" for the look n feel
of the darn thing, we're not solving anything.
I still don't think a progress meter for browsers is something that
belongs in PHP in any way, shape, or form.
Please note my other much longer post on useful server-side
statistical info about file uploads, however.
There *IS* a progress meter on some browsers down in the status bar,
or in other places, which, apparently, the average user is too
clueless to notice consciously.
Though I have noted that semi-experienced users "know" it is there
subconsciously if you ask them the right questions about how far along
the upload is.
Very weird animal, those users... :-)
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
[snip]
...a pretty good discussion...
[/snip]
I have used output buffering to flush stuff (like lengthy data) to the
client before the end of the script so that those pesky users could see
something was happening (because they couldn't be bothered to watch the
browser's progress meter) and at one time thought that you might be able
to do something like a progress meter with that.
Since the http process is stateless it would be hard to provide a truly
accurate progress meter. There are too many factors at play. Using PHP
in an Ajax environment might move it a little closer and is an
interesting thought and depends upon the reliability of the asynchronous
request.
There is the old stand-by...send an animated gif to the browser with no
real timing involved.
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 5:28 pm, D. Dante Lorenso wrote:
>
>> Everything PHP returns from a server is "client side", so your
>>
> Oh yeah. I forgot to say...
> The above presumption is patently false.
>
Let me clarify: Assuming client/server architecture, if PHP is on the
server side then something else needs to be on the client side to
interpret the output of the PHP server. That output is what PHP returns
and it is interpreted and rendered on the client side by definition.
Alternatively: If it is not meant for the client to receive, it is not
(should not) be output by PHP.
Dante
attached mail follows:
Richard Lynch wrote:
>>> Anything you see with "PHP" "upload progress meter" together has to
>>> be some kind of hack whose under-pinning is NOT PHP at all, but is
>>> JavaScript or similar client-side technology.
>> Not true. The graphical display is HTML, DHTML, JavaScript, etc...but
>> the means of monitoring the progress from the server side MUST be done
>> with PHP.
>>
>
> I'm sorry. Your original post sounded (to me) like you wanted a
> progress meter on the browser (client-side) for the user to see their
> files uploaded.
>
Yes, I want that also. Really, I want the feature to exist in the PHP
language regardless of how I intend to use it. That's the beauty of a
programming language vs a program. I want the tools to be able to build
what I want however I might want it at the time.
> Presumably even the worst browsers have some concept of how large the
> file is, and how many bytes have been sent to the server.
> So you certainly DO NOT need server-side information to implement a
> client-side progress meter of the progress of a file upload!
>
Agreed. I SHOULD not NEED this feature. Other server-side languages
exist, so I technically don't NEED PHP either. I don't really want to
debate whether this feature should exist or not, but it seems to me that
the replies I've gotten from this list so far suggest that internals of
PHP development are seriously opposed to such a feature? I am more
interested in which project extensions are leading in momentum to solve
the problem I am trying to solve and not blaming other projects
(browsers) for not building the feature first.
>> The code that I have seen so far requires hooks into PHP
>> which execute callback functions periodically in order to update the
>> progress of uploaded files as PHP processes input.
>>
>
> Yes, which is a silly place to try and "fix" this for client-side
> progress meters, as you then generate traffic back-and-forth from the
> client to measure the number of bytes received, instead of the browser
> just measuring bytes sent.
>
The back-and-forth you refer to is termed 'polling'. With a protocol
like HTTP, polling is really the only option unless I implement a socket
server which is capable of sending events. This is something I may be
building into the project also, but aside from HOW I move the
server-side collect data back to a web client, that is independent of
needing to collect the information on the server side in a format which
can be accessed and read easily.
>> browser in all cases. From the server side, I need to be able to
>> monitor
>>
>> * who is currently uploading files,
>> * which files are being uploaded,
>> * how big are the files being uploaded,
>> * how much time has passed since upload began, and
>> * what percentage of those files is completed
>>
>> I do not need to return this data to a client at all times. Sometimes
>> I
>> just want to use the data system administration, analysis, and
>> tracking. The most popular need would be for returning the
>> information
>> to the client, however, as you suggest.
>>
>
> You'd need a battery of meters, for all running processes, or at least
> all the ones currently in file upload state.
>
I would like to have a list of all file uploads in progress, yes. A
semi-frequently updated snapshot of the information I defined would be
sufficient. If a callback function is invoked periodically it would be
equivalent to firing an event and would allow a php program to log the
data to a common data repository which could be ready by another process
on the system.
> You'd also need tie-ins to your login/authentication to determin "who
> is uploading files" as the only answer inherent to PHP is "the User
> set in httpd.conf"
>
Right. Under the callback method example, I would have access to
$_SESSION which would already contain enough information about the
logged in account for my purposes. This is trivial.
> How big they are relies on the browser sending the correct
> Content-length: for the upload. I don't know how often they get it
> right, but I'm betting that are some pretty common errors in this area
> that PHP corrects for already. So your meters would not be accurate
> in some (hopefully few) cases.
>
The POST method sets the Content-length, right. So, PHP must trust that
the browsers are not lying. For security purposes we don't need to
worry about whether this number is wrong because it is only for
display. Processing uploaded files does not occur until the file
completes uploading.
> While I can see where this might be a useful tool to have server-side,
> I can suggest several possible ways to implement some portions of it
> without hacking PHP source.
>
> First, ... you could write a tool to watch /tmp for
> files and get a list of the /tmp names being uploaded.
>
Yes, this is simple.
> Using filectime and filemtime would tell you the timing info -- Though
> Windows will suck (as usual) as it only tracks to the nearest minute
> or something...
>
Yes. Using Linux. This will work.
> For tying the filenames back to the users who are logged in, you'd
> have to have an onClick() on the submit button which would send some
> kind of information (filename, filesize, user) to a PHP script that
> would log the upload about to begin in a database. The onClick would
> then return false so that the normal form submission process would
> kick in.
>
This will not work. And this is exactly WHY an extention/patch is
needed. Between the time PHP choses a /tmp file name and the time the
upload is completed, there is not execution of PHP code. Therefor, we
don't know the /tmp name assigned to an upload until AFTER the upload is
completed and then it's too late.
> You're not going to get ... accuracy ...
> It won't be so hot for tracking who's uploading what in real-time,
>
It should be. Using the patch, I already have this working. I now want
a cleaner, supported solution which doesn't involve a custom patch which
will not be supported in the future. Although the patch I am using
works, it was build for PHP 5.0.3 RC1 and since I am using 5.1.2 you can
understand my concerns that it will fail to continue working when the
switch is made to PHP 5.2 or PHP 6.0.
> Another option is to provide patch to PHP which gives a special INPUT
> parameter to a FORM that can be used to provide a callback file to
> load, and a callback function within that file to call, and then
> modify the file upload routine to load and call that function.
>
Passing this from the client form is insecure and can not be trusted.
Declaring callback functions needs to remain a server-side declaration
either through code or an INI setting, etc.
> It seems genuinely useful enough to this naive reader, and should not
> cause an undue burden for those who don't use it. Check with PHP-Dev
> to see if such a patch is likely to be accepted before putting in TOO
> much time on it.
>
My original email was searching for advice on which project has momentum
and what the current state of any discussions about the issue were.
Does anybody have information on the PEAR package which appears to be vapor?
http://pecl.php.net/package/postparser
I see the name Curt Zirzow, but no contact information for that "author".
Is there not a package which has been adopted by the community or does
every developer share Richard's opinion that this feature doesn't belong
in PHP?
Dante
attached mail follows:
Merlin wrote:
> X-Spam: high
> X-Spam-score: 4.2
> X-Spam-hits: BAYES_50, EXTRA_MPART_TYPE, FORGED_RCVD_HELO, HTML_MESSAGE,
> HTML_TAG_BALANCE_BODY, MIME_HTML_MOSTLY, SARE_OBFU_PART_ING
>
> Is there something I can do about this?
These headers are coming from SpamAssassin. I suggest you look at their
docs for definitions of what the X-Spam-hits mean.
From my fairly limited memory I can tell you (subject to being very
wrong) that...
BAYES_50: Bayesian tests give it a 50% chance of being spam
FORGED_RCVD_HELO: Your server did not correctly identify itself when it
connected to the destination SMTP server
HTML_MESSAGE: Message contains HTML
HTML_TAG_BALANCE_BODY: HTML is not syntactically correct
MIME_HTML_MOSTLY: The message is MIME, but there is no plain text version
As I said I haven't actually looked these up, but I suggest you do. The
things you need to do to prevent your messages getting high scores from
spam filters are fairly simple, but they need to be researched to get it
right.
Hope that helps.
-Stut
attached mail follows:
Hello,
on 04/25/2006 06:43 AM Merlin said the following:
> Hi there,
>
> I am operating page where user receive a message which they do
> have to confirm. The message does have about 5 links inside to give the
> user administration to his postings.
>
> Now recently I discovered that the message does not go through to
> everybody since the spam score is 4.2! This is of course not what I want
> as some users are not able to confirm their postings without this e-mail.
>
> I am using the newest phpmailer class available and this is what the
> header tells me:
>
> X-Spam: high
> X-Spam-score: 4.2
> X-Spam-hits: BAYES_50, EXTRA_MPART_TYPE, FORGED_RCVD_HELO, HTML_MESSAGE,
> HTML_TAG_BALANCE_BODY, MIME_HTML_MOSTLY, SARE_OBFU_PART_ING
>
> Is there something I can do about this?
I don't know about phpmailer because I do not use it. I use this other
MIME message composing and sending class that has evolved over the years
to avoid passing the wrong sympthoms to spam filters.
http://www.phpclasses.org/mimemessage
I also recommend to review your HTML to assure it is validated .
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
attached mail follows:
On Tue, April 25, 2006 4:43 am, Merlin wrote:
> I am operating page where user receive a message which they do
> have to confirm. The message does have about 5 links inside to give
> the user
> administration to his postings.
This has NOTHING to do with PHP...
> Now recently I discovered that the message does not go through to
> everybody
> since the spam score is 4.2! This is of course not what I want as some
> users are
> not able to confirm their postings without this e-mail.
Maybe that's what the users want though. It's their Inbox, after all :-)
> I am using the newest phpmailer class available and this is what the
> header
> tells me:
You should probably reference the "phpmailer class" since that could
describe about 100 different software packages out there...
> X-Spam: high
> X-Spam-score: 4.2
> X-Spam-hits:
BAYES_50 the actual text of your message looks like spam. Fix it.
EXTRA_MPART_TYPE This probably means your HTML enhanced (cough, cough)
mail is mal-formed.
FORGED_RCVD_HELO The mailer is forging the email badly and getting
caught. This may not be fixable, but you'll have to research it and
experiment.
HTML_MESSAGE You are sending HTML enhanced (cough, cough) email.
That's your FIRST problem. All it needs is ONE link on a separate
line.
HTML_TAG_BALANCE_BODY, You've got more tags than content. Again, HTML
enhanced (cough, cough) email is your problem.
MIME_HTML_MOSTLY, Need I say it again?
SARE_OBFU_PART_ING Got no idea.
> Is there something I can do about this?
Stop sending HTML enhanced email.
Tell users to "whitelist" your domain if they are having trouble
getting your email.
Google for the keywords in X-Spam-Hits instead of asking the PHP
mailing list why a software package which has NOTHING to do with PHP
is behaving the way it is.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
On Tue, April 25, 2006 7:19 am, Merlin wrote:
> Paul Scott schrieb:
>> On Tue, 2006-04-25 at 11:47 +0200, Barry wrote:
> Does anybody know how phpmailer sents its messages out by default? I
> believe it
> does this via the php function mail. But there can also be a smtp
> server
> specified. Do I have to set up such a server, or is it running by
> default on
> suse servers? If I issue a "top" command I do see smtp processes.
> What would be the advantage?
This has even LESS to do with PHP than your original question!
Perhaps you should contact whomever wrote and supports phpmailer?
If you ARE using PHP mail() function, then you may want to look into
using the new optional 5th argument: http://php.net/mail
You'll maybe have to patch phpmailer to use it, or get the author to
patch it.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 7:19 am, Merlin wrote:
>
>>Paul Scott schrieb:
>>
>>>On Tue, 2006-04-25 at 11:47 +0200, Barry wrote:
>>
>>Does anybody know how phpmailer sents its messages out by default? I
>>believe it
>>does this via the php function mail. But there can also be a smtp
>>server
>>specified. Do I have to set up such a server, or is it running by
>>default on
>>suse servers? If I issue a "top" command I do see smtp processes.
>>What would be the advantage?
>
>
> This has even LESS to do with PHP than your original question!
since when does that matter here :-P
>
> Perhaps you should contact whomever wrote and supports phpmailer?
I'm pretty sure he read this list - and given the fact that
nearly everyone has used it I think it fair game for generals...
besides the basic mechanism/interface (forgetting the nitty gritty details of
mail headers etc that phpmailer takes care of underwater) is very simple.
phpmailer is a lovely little [collection of] classes - no outside
dependencies - does what it says on the tin, no fuss; I like it :-)
>
> If you ARE using PHP mail() function, then you may want to look into
> using the new optional 5th argument: http://php.net/mail
>
> You'll maybe have to patch phpmailer to use it, or get the author to
> patch it.
it supports mail() - it's the default send mechanism
>
attached mail follows:
Stut wrote:
> Merlin wrote:
>> X-Spam: high
>> X-Spam-score: 4.2
>> X-Spam-hits: BAYES_50, EXTRA_MPART_TYPE, FORGED_RCVD_HELO, HTML_MESSAGE,
>> HTML_TAG_BALANCE_BODY, MIME_HTML_MOSTLY, SARE_OBFU_PART_ING
>>
>> Is there something I can do about this?
>
> [snip]
As of Spamassassin version 3.1.X it is
>
> BAYES_50: Bayesian tests give it a 50% chance of being spam
Bayesian spam probability is 40 to 60% and score is 0.0001 which is very
low to consider in your case.
>
> FORGED_RCVD_HELO: Your server did not correctly identify itself when
> it connected to the destination SMTP server
score is 0.13
> HTML_MESSAGE: Message contains HTML
score is 0.0001, again to low to consider.
> HTML_TAG_BALANCE_BODY: HTML is not syntactically correct
> MIME_HTML_MOSTLY: The message is MIME, but there is no plain text version
look for this one. score ranging from 0.6 to 2.3.
EXTRA_MPART_TYPE: Header has extraneous Content-type:...type=
score ranging from 0.73 to 1.09.
SARE_OBFU_PART_ING: This rule seem to be custom..
What Stut said is correct but I would suggest you try out your mail with
default spam scores set by Spamassassin. Mail server administrators can
specify whatever scores they want for any tests. So you can't possibly
maintain ham status of your mail on every server (running spamassassin)
your mail sent to.
All this considering your mail really isn't spam.. :-).
--
Sameer N. Ingole
Blog: http://weblogic.noroot.org/
---
Better to light one candle than to curse the darkness.
attached mail follows:
I was wondering if anyone knew of a program that I could run my scripts
through and it would return mccabes complexity metric on it ...
Thanks, Mark
attached mail follows:
Hi I just wanted to know if there's a generalised library available for
Forms validation in php?
--
Murtaza Chang
attached mail follows:
Hello,
on 04/25/2006 04:38 PM Murtaza Chang said the following:
> Hi I just wanted to know if there's a generalised library available for
> Forms validation in php?
http://www.phpclasses.org/formsgeneration
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
attached mail follows:
Murtaza Chang wrote:
> Hi I just wanted to know if there's a generalised library available for
> Forms validation in php?
> --
> Murtaza Chang
>
http://pear.php.net/package/HTML_QuickForm
http://ez.no/doc/components/view/latest/(file)/introduction_UserInput.html
attached mail follows:
>[snip]
>In any event, I can't back-up, download, copy, change permissions, or
>do anything with the chmod 600 group. Any suggestions as to what I
>can do with these files?
>[/snip]
At 11:30 AM -0500 4/25/06, Jay Blanchard wrote:
>After uploading have PHP CHMOD them properly
and
At 12:41 PM -0400 4/25/06, Robert Cummings wrote:
>And for your existing files create a script to load in your browser that
>traverses the files and CHMOD's them.
I hate it when you guys do that -- I don't want to think.
I added a chmod to my edit.php and changed the permissions as the
images were viewed -- duh! -- it couldn't be simpler.
For being the bright guy I think I am, I'm pretty dim sometimes.
Thanks.
tedd
PS: Hey, and no wisecracks about "what do you mean -- sometimes?" :-)
--
--------------------------------------------------------------------------------
http://sperling.com
attached mail follows:
On Tue, April 25, 2006 11:16 am, tedd wrote:
> A while back I was persuaded by this illustrious group into thinking
> that placing images in a file system was superior to placing them in
> mySQL -- after all, what could go wrong with a file system solution,
> right?
>
> So I did.
>
> Now, I have a small problem. Unfortunately, most of the images I've
> uploaded have permissions set at chmod 600 (rx- --- ---). Interesting
> enough, considering that all the images were all uploaded with the
> same script, not all of the images have the same permission problem
> -- that's odd.
>
> In any event, I can't back-up, download, copy, change permissions, or
> do anything with the chmod 600 group. Any suggestions as to what I
> can do with these files?
You may not be able to do anything with those files logged in as
'tedd' (or whatever) but the PHP script you wrote ran as a specific
user (probably 'www' or 'nobody') and THAT user can do whatever it
wants to the files, because that user 'owns' them.
So you can write a PHP admin script to copy or change permissions on
the existing files. You'll have to surf to it for the same user to be
running that script as uploaded the files.
You could also ALTER your upload script for future uploads to change
the http://php.net/umask before you upload files, and
http://php.net/chmod the files after they are uploaded, to provide
access to the 'w'orld or a 'g'roup if your webhost (or you) can put
the PHP user and 'tedd' in the same group.
As far as some of the files being different, those are probably files
you uploaded "by hand" during testing, or your script had, at some
point, calls to umask and or chmod in it, that you altered, or only
called under certain circumstances.
It's also possible that you changed the permissions on the containing
directory at some point, which change "trickled down" to the new files
created within that directory after that point in time.
Once you understand how/why the Unix permissions are what they are,
it's pretty trivial to figure out how to get the files to do what you
want.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Ave,
I wrote a File Manager application for my company which allows the
management & our clients to upload files & share files. The application has
been running fine since a while now, but lately I thought about adding a
Progress Bar for the file upload form.
I searched a bit to find that PHP is not capable of producing an Upload
Progress Bar, and I was looking into the AJAX & PHP progress bar which seems
to be pretty popular. I run my Apache Web Server on a Mac OS X. Although I
downloaded & configured AJAX, and also upload progress meter extension...
Nothing worked... And I found out that PHP has to be patched, recompiled,
reconfigured & reinstalled on a unix level (configure, make), which I really
donıt want to do at this stage as Iım not an expert in that.
I was just wondering if there is an alternate... Any other way to produce a
progress bar.
If someone is experienced with the AJAX/PHP Upload progress bar, and would
like to contribute suggestions, Iım open to that as well.
Thanks,
Rahul S. Johari
Coordinator, Internet & Administration
Informed Marketing Services Inc.
500 Federal Street, Suite 201
Troy NY 12180
Tel: (518) 687-6700 x154
Fax: (518) 687-6799
Email: rahulinformed-sources.com
http://www.informed-sources.com
attached mail follows:
Hi,
I have trouble with installing GD2 library correctly,
someone want to take a look at it and maybe fix it?
It`s a symbolic reward of 10$ to the one who solves the problem and make it
work correctly :)
Please send me an E-Mail at AleksanderNettsenteret.com asap.
Thanks in advance,
Aleksander Davidsen
attached mail follows:
Aleksander Davidsen wrote:
> Hi,
>
> I have trouble with installing GD2 library correctly,
> someone want to take a look at it and maybe fix it?
start by supplying details on your OS, php build and everything
related.
>
> It`s a symbolic reward of 10$ to the one who solves the problem and make it
> work correctly :)
if we help you then stick the money in a charity or something.
I doubt anyone here needs 10 bucks - if they do they can always
sell the computer they are reading this on :-)
attached mail follows:
Stut wrote:
> Jochem Maas wrote:
>
>> Simas Toleikis wrote:
>>
>>> thing :-/ Though i wonder if there are any other hacks using some sort
>>> of classkit/other class manipulation functions?
>>
>>
>> probably runkit (or is it classkit - can't remember which of those
>> is more actively developed) might give a way out - but I would recommend
>> it for production code.
>
>
> I'm thinking you meant to put a 'not' somewhere in there, as in "but I
> would *not* recommend it for production code".
er, yes - good catch Stut!
>
> -Stut
>
attached mail follows:
Hello all,
I've successfully generated my DataObjects for my database and have a
set of objects that extend these generated classes so that my logic is
separate from the generated code (so that any slight schema changes
won't overwrite my code).
My question concerns using FormBuilder to change the displayfield for a
linked dataobject. For example, I have table1 and table2. table1 is
extended by table1extended class. I create a do from this extended
class and pass that to formbuilder. table1 has a link to table2, but
I'd like to make table2 use a different field when being displayed by
the form generated for table1 *without having to place the
fb_linkDisplayField variable into the generated do for table2*. I'd
prefer to keep that out of the do. Putting it in the extendedtable2
class is alright, but how do I make formbuilder see that class instead
of the base do that is generated? Even better, I'd like to be able to
effect the way table2 is displayed in a form(s) generated from table1
from the page that is creating that form. (Page one with a form
displays table2's name field, while page two with a form displays one of
table2's other fields).
This may fall more into how to structure my application. I want to
separate the generated do code from my 'business logic' and separate the
form/display details from the business logic.
Any help/advice is greatly appreciated.
Thanks,
Tom
attached mail follows:
Tom wrote:
> Hello all,
>
..bla..
> This may fall more into how to structure my application. I want to
> separate the generated do code from my 'business logic' and separate the
> form/display details from the business logic.
your asking something about a specific code/tools (that I for one
have not heard of before) - you might want to ask the people that wrote
FormBuilder et al.
>
> Any help/advice is greatly appreciated.
>
> Thanks,
> Tom
>
attached mail follows:
On Tue, April 25, 2006 4:26 pm, Tom wrote:
> I've successfully generated my DataObjects for my database and have a
> ...
> My question concerns using FormBuilder to change the displayfield for
Of the 3000+ people on this list devoted to *GENERAL* PHP Topics,
let's be generous and assume about 300 of them actually USE
FormBuilder and DataObjects.
Of them, maybe 30 have enough experience to actually have SOME CLUE
what you are asking and why.
Of that, maybe 1 is going to manage to read the message in time to do
you any good.
That is why you probably should have first asked this question in a
forum devoted to FormBuilder and/or DataObjects, whatever those are,
where ALL the readers actually care about FormBuilder and
DataObjects...
YMMV
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
I've mailed this list per the instructions on the pear.php.net site. I
first thought to email the lead maintainer (Justin Patrin) for the
DB_DataObject_FormBuilder package
(http://pear.php.net/package/DB_DataObject_FormBuilder)
but the email form page gave these instructions:
"Do not send email to this developer if you are in need of support for
any of his/her package(s), instead we recommend emailing
pear-generallists.php.net where you are more likely to get answer.
You can subscribe to the pear-general mailinglist from the Support -
Mailinglist page."
That's what I've done. Also, searching the list archive turned up some
questions from users and answers from the package's lead maintainer
(http://beeblex.com/lists/index.php/php.pear.general/20823?s=formbuilder+%3Aphp.pear.general),
so I thought this was appropriate, on top of respecting the explicit
instructions of the site, Justin Patrin's inbox and the idea that
submitting to the mailinglist will allow others to see
questions/solutions and contribute/benefit.
Other than contacting the developer directly (which, again, seems to be
discouraged), and search engines, (google didn't turn up anything
specific to this concern), does anyone have other specific resources
regarding FormBuilder?
Tom
Richard Lynch wrote:
> On Tue, April 25, 2006 4:26 pm, Tom wrote:
>> I've successfully generated my DataObjects for my database and have a
>> ...
>> My question concerns using FormBuilder to change the displayfield for
>
> Of the 3000+ people on this list devoted to *GENERAL* PHP Topics,
> let's be generous and assume about 300 of them actually USE
> FormBuilder and DataObjects.
>
> Of them, maybe 30 have enough experience to actually have SOME CLUE
> what you are asking and why.
>
> Of that, maybe 1 is going to manage to read the message in time to do
> you any good.
>
> That is why you probably should have first asked this question in a
> forum devoted to FormBuilder and/or DataObjects, whatever those are,
> where ALL the readers actually care about FormBuilder and
> DataObjects...
>
> YMMV
>
attached mail follows:
Thomas Supercinski wrote:
> Jochem,
> I've mailed this list per the instructions on the pear.php.net site. I
> first thought to email the lead maintainer for the
> DB_DataObject_FormBuilder package
> (http://pear.php.net/package/DB_DataObject_FormBuilder)
you should have given that link in the first place, it helps to
put your question in context. your obviously didn't start php'ing
yesterday if your using DB_DataObject_FormBuilder :-) maybe someone
here uses it also and can give some tips - I can't claim to have
ever used it so I can't be of any assistance on this matter, I guess
it's wait and see if anyone else can.
>
> but the email form page gave these instructions:
>
> "Do not send email to this developer if you are in need of support for
> any of his/her package(s), instead we recommend emailing
> pear-generallists.php.net where you are more likely to get answer.
pear-generallists.php.net != php-generallists.php.net
(then again may it does, in which case my apologies)
attached mail follows:
On Tue, April 25, 2006 8:56 am, tedd wrote:
> At 9:56 PM -0500 4/23/06, Richard Lynch wrote:
>>On Sun, April 23, 2006 5:25 pm, tedd wrote:
>>> <img src="images/the_image.png?id=<?php rand(); ?>">
>>>
>>> Neither the image tag nor the file cares if there is a random
>>> number
>>> attached to the file's url. But, by doing this, most (perhaps all)
>>> browsers think the image name is unique.
>>>
>>> Doe anyone see any problems with this?
>>
>>Oh, all the browsers will KNOW it's a unique URL...
>>
>>But some of them won't believe it's a valid image. :-(
>>
>>Alas, I do not recall which browser would mess this up -- And it's
>>probably so old MOST webmasters won't care...
>
> I ran a test through BrowserCam and surprisingly the ONLY browser
> that failed to recognize the url as a valid image was Netscape 4.78
> for W2K. But, that browser is ancient. So, it works!
You may want to try it with a PDF and an FDF and a Ming SWF.
The reason why I advocate the URL-embedded parameters is that I'm
using the SAME code over and over for images and for PDF and for FDF
and for SWF (Ming) and...
If you want to maintain a different code-base for all the different
browser-bugs for all the different rich media (IE, not HTML output)
you're all set.
If you want to maintain ONE code-base that works for all rich media,
and simplify your life immensely...
I've been burned by too many browser oddities over the years to use
GET parameters for anything other than HTML.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Hey, is it possible to use the Amazon WSDL within PHP?
attached mail follows:
John Meyer wrote:
> Hey, is it possible to use the Amazon WSDL within PHP?
>
Lookie what the first google entry for "Amazon WSDL php" was:
http://www.onlamp.com/pub/a/php/2003/07/03/php_amazon_soap.html
Richard
attached mail follows:
On Tue, April 25, 2006 4:56 pm, John Meyer wrote:
> Hey, is it possible to use the Amazon WSDL within PHP?
http://php.net/soap should do it.
If you're stuck with PHP 4, then Google nuSoap, I guess.
But php 5 SOAP is about a zillion times better, imho.
You type less, it just works, it's way faster, it's much cleaner...
YMMV NAIAA
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Richard Collyer wrote:
> John Meyer wrote:
>
>> Hey, is it possible to use the Amazon WSDL within PHP?
>>
>
> Lookie what the first google entry for "Amazon WSDL php" was:
>
> http://www.onlamp.com/pub/a/php/2003/07/03/php_amazon_soap.html
why use their WDSL when 98% of the their webservices users
connect using their much simpler REST interface? I read not long ago
that only their very largest 'partners' (Ebay was mentioned) actually
use the WDSL inteface.
WDSL == OVRKLL ? ;-)
> Richard
>
attached mail follows:
Richard Lynch wrote:
> On Tue, April 25, 2006 4:56 pm, John Meyer wrote:
>
>>Hey, is it possible to use the Amazon WSDL within PHP?
>
>
> http://php.net/soap should do it.
>
> If you're stuck with PHP 4, then Google nuSoap, I guess.
>
> But php 5 SOAP is about a zillion times better, imho.
>
> You type less, it just works, it's way faster, it's much cleaner...
did Richard just endorse php5? did hell freeze over? ;->
>
> YMMV NAIAA
>
attached mail follows:
Richard Collyer wrote:
> John Meyer wrote:
>> Hey, is it possible to use the Amazon WSDL within PHP?
>>
>
> Lookie what the first google entry for "Amazon WSDL php" was:
>
> http://www.onlamp.com/pub/a/php/2003/07/03/php_amazon_soap.html
>
> Richard
Nice, now I need to navigate the bloody Amazon web services. Is it just
me, or does it look like, just by browsing Amazon itself, you have to
use Alexis to do web queries. Specifically, I'm trying to find out how
to query using an ISDN.
attached mail follows:
On Tue, April 25, 2006 11:50 am, Eric Butera wrote:
> On 4/25/06, Richard Lynch <ceol-i-e.com> wrote:Oh, and here's the
> REAL
> problem:
>
>>
>> If you use CURLOPT_HEADER, 1, then, like, for some reason beyond my
>> ken, the COOKIEJAR/COOOKIEFILE stuff just plain doesn't get done.
> On an application I was forced to write, the goal was to create an
> interface
> to another system on another server. I used cURL to grab the pages.
> Their
> system sent three cookies and used tons of redirects to set their
> session
> and validate logins. So basically I ended up with something like
> this:
>
> define('_COOKIEJAR', '/tmp/cjar_'. session_id());
> define('_COOKIEFILE', _COOKIEJAR);
>
> curl_setopt($curl, CURLOPT_COOKIEJAR, _COOKIEJAR);
> curl_setopt($curl, CURLOPT_COOKIEFILE, _COOKIEJAR);
> curl_setopt($curl, CURLOPT_HEADER, TRUE);
> curl_setopt($curl, CURLOPT_FOLLOWLOCATION, TRUE);
> My point is that I have headers turned on and the cookie jar files get
> wrote
> to /tmp. So am I misunderstanding that you said it is one or the
> other?
>
> Let me know if I'm wrong, thanks!
Sounds to me like we have different versions of cURL and yours is
better. :-)
Mine phpinfo() curl section has:
libcurl/7.15.3 OpenSSL/0.9.7d zlib/1.2.1
which would seem to be the most current version...
Or, perhaps, the order in which you set the options matters? Ick.
For me, at least, the Cookie jar did not work until I took out the
CURLOPT_HEADER, and it DID work after I changed that, and only that.
--
Like Music?
http://l-i-e.com/artists.htm
attached mail follows:
Mark Steudel wrote:
> I was wondering if anyone knew of a program that I could run my scripts
> through and it would return mccabes complexity metric on it ...
not that I know of (actually didn't know the term until I read your post :-)
but I bet Windows Vista scores well above 50 ;-)
>
> Thanks, Mark
>
attached mail follows:
I have a form like this:
<form action="search.php" method="post" target="_self">
<input type="text" name="search_text" cols="20" rows="10"></input>
<input type="submit" name="submit_search" value="search" />
</form>
while this is working fine, I would like the url of search.php to be
something like search.php?q="value+of+search_text"
eg, if I enter "php rules" in my text box, the url should be
http://myfakepage.com/search.php?q="php+rules"
any idea how to do that?
thanx in advance
Pat
attached mail follows:
Only chage method="post" for method="get"
Regards!
-----Mensaje original-----
De: Patrick Aljord [mailto:patcitogmail.com]
Enviado el: Martes, 25 de Abril de 2006 06:19 p.m.
Para: php-generallists.php.net
Asunto: [PHP] need help to put input text value into url
I have a form like this:
<form action="search.php" method="post" target="_self">
<input type="text" name="search_text" cols="20" rows="10"></input> <input
type="submit" name="submit_search" value="search" /> </form>
while this is working fine, I would like the url of search.php to be
something like search.php?q="value+of+search_text"
eg, if I enter "php rules" in my text box, the url should be
http://myfakepage.com/search.php?q="php+rules"
any idea how to do that?
thanx in advance
Pat
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
I need to add LDAP support to my install of PHP. I had my sysadmin
download OpenLDAP and install the libraries. Our current build of PHP
is complex and I'd prefer not to have to rebuild just to add LDAP. I've
been told to use the dl() function to load the LDAP library when needed
in PHP. Whenever I dl("libldap.so") PHP returns the following error:
PHP Warning: dl(): Invalid library (maybe not a PHP library)
'libldap.so' in .....
What am I doing wrong? Thanks in advance.
Jim
attached mail follows:
I would like to replace all chars in a string that are not a-z or 0-9
with a space. I can use a series of str_replace functions, but there
has to be a faster way.
I know there is a solution but my chemo-brain is slowing me down today. Sorry...
Any suggestions?
TIA
Gerry
attached mail follows:
I would like to replace all chars in a string that are not a-z or 0-9
with a space. I can use a series of str_replace functions, but there
has to be a faster way.
I know there is a solution but my chemo-brain is slowing me down today. Sorry...
Any suggestions?
TIA
Gerry
attached mail follows:
Gerry Danen wrote:
> I would like to replace all chars in a string that are not a-z or 0-9
> with a space. I can use a series of str_replace functions, but there
> has to be a faster way.
>
> I know there is a solution but my chemo-brain is slowing me down today. Sorry...
>
> Any suggestions?
>
> TIA
>
> Gerry
>
Not sure which would be easier or faster - but str_replace can take an
array (black list approach) , or use preg_replace so you can do a white
list approach.
--
life is a game... so have fun.
attached mail follows:
Initial index.php file:
<?php
if(isset($_GET['d'])){setcookie('disp',$_GET['d'],time()+(60*60*24*60));$_COOKIE['disp']=$_GET['d'];}
include_once('writemenus.php');
if(!isset($_GET['href'])) $include = 'startpage.htm';
else {
$include = $_GET['href']; $include = "$include.php";
if($include=='index.php')$include = 'startpage.htm';
}
include_once($include);
include_once('footer.htm');
?>
=============================
Hackers seem to be able to call a remote script by appending the URL
to the href= command line . ( $include )
What buttons do I need to push to stop this? Does PHP have a setting
to allow only local calls? or do I have to do it in the index.php file ? or ??
Advice welcome!
-Pete
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]