I am attempting to embed a HTML registration form as a content page. When submitted, this form opens up a new window to a Paypal shopping cart. Unfortunately, although I the page works perfectly when served as a straight HTML page, it changes behavior when put in as a XOOPS page in either TinyContent or WF-Sections. Instead of showing the proper paypal page, the pop-up window shows a XOOPS submission and then error. Any ideas on why this happens?

Here is the javascript code I'm using:



If you'd like to take a look at the problem in action, here the WF-Section implementation: Failing Page

Here is a working version of the page, using TinyContent and an IFRAME to access the original page:
Work-around Page

Thanks in advance!

PS-it is safe to click the "Add to Cart" and "View Cart" buttons and open the shopping cart pop-up. Just don't go through the Paypal checkout unless you plan on donating money...

Hello pstrasma

Your "failing page" cant be seen by unregistered users, perhaps you could change permissions in groups. I have a little hashed "framebrowser" module for download on my site, I find it useful for some wrapping some scripts or files in XOOPS without any internal hacking. I use it for Zina media streamer etc

regards

Ah, good call on those permissions. I'll open that up for the time being.

And thanks for the Framebrowser reference. It is helpful to see how others have tackled this problem. One still wonders what XOOPS is doing to mess with the target window...

You appear to have two body tags, it looks like the head tags etc are unstripped.

Paste the following code into a text editor, and save it as an HTML file (no head and body tags)

Upload it into the HTML folder in wfsections and create your page from there through wfsections using the external HTML facility. This way no extra lines or code or table cells are inadvertantly added. (This may also work using wysiwyg, you could try it)

Assuming you have the wfsections that does not give "empty" errrors when you do it this way. (I have a version on my site for download which has this fixed) If you have the version with that problem just add a line of text in the wysiwyg and save, it should work. (It wont add the line of text)

Code:

You can register for 2004 Reunion events online using PayPal or by calling
the IMSA Fund office at (630) 907-5040. Please note that no onsite registrations will be available.
The deadline to register is May 31, 2003!.  Register before March 31, 2003 for a 10% discount on all events.

Class Reunions			Price	Quantity
Class of 1989 Reunion			$65
	Meal: Meat Vegetarian	Guest Name:
Class of 1994 Reunion			$50
	Meal: Meat Vegetarian	Guest Name:
Class of 1999 Reunion			$35
	Meal: Meat Vegetarian	Guest Name:
General IMSA Activities			Price	Quantity
Alumni Day Faculty Lunch			$10
Submit Registration through PayPal

You should be able to change the page permissions back now.

I could have logged in I suppose? I am going senile I think..:)

regards

Thought I'd tried that approach, but you never know...

This time around with the copy/pasted code, the behavior improved somewhat. Basically what happens now is that the script opens the new window and very briefly displays the Paypal cart as desired. Then it switches back to a XOOPS site submission, redisplaying the form again in the small window. If I use the browser back in the pop-up window, it nicely goes back to the shoppping cart.

The change in behavior might also have something to do with the auto-login hack I applied before going back to this wf-sections issue.

So any ideas on this more isolated problem of the second page request occuring in the module-based page vs. the stand-alone page?

Thanks in advance!

Solved the problem! Live PayPal cart now embedded in WF-Sections here.

Solution was to change the OpenWin function from an OnClick in the submit button tag to an OnSubmit in the form tag. I also deleted the time delay -- can't even recall why that was needed originally. Current working code follows: