[Pmwiki-users] passing variables between php programs
Crisses
crisses
Sun May 16 05:11:08 CDT 2004
> Pmwiki isn't designed to take data from other scripts, at least not
> natively. I'm not sure if you can pass it GET variables on an edit page
> for content, proably not. You will need to find where in Pmwiki the
> edit
> page is rendered and make it look for a specific GET variable if that
> variable exists then just propagate the edit form with that variable
> instead.
This is the relevant HTML:
<form action='http://www.kinhost.org/wiki/Main/AllRecentChanges'
method='post'>
<input type='hidden' name='pagename' value='Main.AllRecentChanges' />
<input type='hidden' name='action' value='edit' />
<textarea name='text' rows='25' cols='60'
onkeydown='if (event.keyCode == 27) event.returnValue=false;'
>
So a variable called "text" is sent by POST to PmWiki. It's verified
by a Javascript, but if I submit via another program I'd be bypassing
that client-side technology. Also sent is the "pagename" variable with
the name of the page, and the "action" variable with the value "edit"
I've been looking at cURL [which has a PHP binding] and at PEAR's HTTP
libraries -- cURL definitely has the capacity to send a POST, and I've
been learning why it's different than GET. PEAR is way over my head
right now, I think.
> Sorry php.net is a good reference for those already familiar with
> programming languages and php. If your just learning php this type of
> modification to Pmwiki will probably be a difficult task, you will need
> to read the code to find out where to make your modifications.
I know PHP but it has a long list of libraries and similar
(class-action LOL) add-ons.
The problem was in my knowledge of how POST works. Post is an entirely
separate HTTP "request" packet from a request for a HTML page. With
only basic PHP functionality I'd have to jump through a lot of header()
statements to send a POST request correctly (I think)...and if you've
looked at the Functions list on php.net, it's rather long. I poked at
about 8 different function lists looking for what I wanted, but didn't
find it because it's a little buried -- it's under cURL.
http://www.php.net/manual/en/ref.curl.php and that's again not a great
place to *learn*.
> There probably several very nicely written introduction to php books on
> the market that will help you learn. Or you may consider having someone
> else make these modifications for you.
I've got 2 PHP books. I've read them cover-to-cover. I have a few
references but they only briefly mention the functions in some of the
libraries. The Peachpit books don't include this information, or I
wouldn't have to pour over the web for it. I've already learned PHP --
I haven't learned all the functionality provided by the extensions to
PHP. I'm not an expert at PHP, but I'm rather functional with it.
I've never dealt with HTTP requests before, that's all. I've been
programming since 1985 with Basic on a commodore 64, moved to Pascal,
Fortran, dBaseIII+, dabbled in Perl and now I'm doing PHP.
Unfortunately procedural language makes a lot more sense to me than
object-oriented programming which is why PEAR kinda loses me (and it's
poorly documented that I can tell). I don't understand why my asking
for help in one area is interpreted as me not knowing PHP and needing
some nice books.
> To add <br /> to the end of every line of a file you can simply use:
>
> str_replace("\n","<br />",$data);
Thanks, but that's already in the program. and I'm using
preg_replace() and $implode ($array, "<br />\n"); so my html doesn't
come out looking like a gorilla wrote it.
That is not the code I was asking for help with.
>> I want to know how to pass that array to PmWiki. I don't think it
>
> To pass a variable, array, or any kind of data via a GET variable you
> can simple serialize it then compress and encode that and pass the
> resulting string via GET then in the other script you will decode,
> decompress then unserialize the variable.
This is great advice, but will require Patrick to re-write PmWiki to
accept the variable via GET and I don't want to do that. However, it
might be a great way for me to pass text around if I make any other
stand-alone modules that are not interfacing with Patrick's program.
>> should be via GET; it's possibly going to get too big. I need to know
>> how to send a POST to another url without using a hidden field on a
>> form with a button that necessitates user interaction. I also want to
>
> I don't believe a url length has a maximum length, it is possible if
> your uploading HUGE files. The other option is to send the data via
> POST, but post requires the browser to submit the data via a form, this
> could be done automatically with javascript but it would make an
> intermediate page load up, a "loading" page.
I thankfully found it, and you are incorrect:
http://zend.com/zend/tut/tutorial-thome3.php
http://www.phpfreaks.com/tutorials/49/1.php
http://curl.haxx.se/libcurl/php/examples/?ex=customrequest.php
It does require that you put php's curl library into it. It comes
already on OS X and it's as easy as pie using dselect in Debian, but
I'm not sure how hard that might be for anyone else.
>> incur the lowest amount of PmWiki being rewritten. I'm not sure I
> need
>
> Pmwiki probably isn't designed to take data via GET and POST to display
> in the edit page form. So this would require a modification, not very
> extensive, just a few lines.
No modifications needed. Of *course* it gets data from the client via
GET --or-- POST because there's no other way browsers send
data,[addendum: there is session data and cookies, but those also can
be poked at, looked at, and hacked] which means *any* webpage can be
hacked (in the Google or Ebay "Hacks" kinda way) using the cURL
libraries if you're diligent enough and willing to put your passwords
into [or pass them to] the program you're making. If someone is using
Java, that might change this case. Javascript is only used in PmWiki
to authenticate information before it is passed. PmWiki doesn't
actually know whether or not the javascript ran when it receives POST
data. PmWiki is not sitting and waiting on the server for the data to
come back. It get the data when the page is hit.
> I'm not sure if your wanting this to be done by yourself or if you want
> someone else to do it for you? I'm writing my responses in format
> presuming that you have at least some experience with php.
I just wanted an example of a POST if it were a simple one-liner (which
it isn't quite that simple, apparently) or for someone to go "Oh, you
need to either look at the cURL library or look at the PEAR project's
HTTP_REQUEST features or their CLIENT somethingorother features."
>> I don't think base64 is going to help (I assume that's for purposes of
>> data compression?). Are you implying the only way to pass variables
>> from PHP->PHP is via GET? Or is it just the easiest way? You never
>> actually said POST is not possible. What if the text field is so
> large
>> it's too large for GET even after being encoded in base64? And what
>> library do I find that command (to encode a string in base64) in?
>
> base64_encode doesn't compress, in fact if you encode something via
> base64 it usually grows slightly in size. To compress it you would use
> gzcompress() before you encoded it. Encoding just makes sure the string
> contains only legal characters that can be in a url.
Ah. Well, that's not helpful because I'm not going to ask Patrick to
rewrite PmWiki to accept base64 data.
> It is possible a huge file compressed this way and passed via a GET
> variable could cause problems. In that case you will need to use POST
> and some sort of JavaScript to auto submit the post data to the second
> script.
Again; this is incorrect.
> There is also php sessions that can be used to hold data. This doesn't
> require any GET and POST variables to pass data from page to page. All
> it does is sets a cookie on the user's machine and that cookie is read
> on each page view and then php looks up the cookie data and then auto
> loads up a master array that is the same from page to page.
That's true: session data and cookies are passed as well as GET and
POST. But if PmWiki isn't looking for 'text' via session or cookie, it
won't find the data there, so this point is moot unless I'm looking to
add and author name, password/id, etc. to the "session"
> $_SESSION variable is available once you enable sessions on a page.
> This
> variable works like any other; you can set things in it and read from
> it, only this variable becomes available to php script on the site.
> This
> is a feature few utilize in php. I'm not sure on its reliability and if
> the user doesn't have cookies enabled I'm not sure it will function.
I believe that PmWiki starts both a session and reluctantly plants a
cookie. My passwords expire when I close my browser, but my "author
name" is there every time I use the site. That implies that PmWiki
does both.
>> I already have one: Antiword. I appreciate it though.
>
> Is this a command line program? I merely suggested some programs that
> looked pretty powerful and was command line and unix compatible.
Yes :) I compiled it on my OS X box, and I used dselect to put it on
my debian server. My OS X box is used for development/testing [because
my iBook can go everywhere with me :) ] and my debian server [a G3
beige running BootX -> Debian] is live on the net.
>> Again: are you saying it's not possible? Or is it so hard it's not
>> worthwhile?
> No php can easily execute command line programs and read in files. This
> isn't' a very hard task.
I meant POST, not reading in lines and changing them. My program works
already. It works great. I just want the output in the wiki. and I
don't want to be cut/pasting from a browser window into another browser
window for the rest of my days as a recruiter. Even if I had to use a
form, pressing one button is easier than cut/pasting. However, that
shouldn't be necessary. This should work seamlessly once I figure out
exactly what PmWiki *needs* to have passed to it.
Thanks for your time and trouble.
Crisses
More information about the pmwiki-users
mailing list