Ok, I confess I'm a designer and know little about backend coding. I have a site with a frontend form created with HTML in WordPress. On submission the form action="/cgi-bin/test.cgi" method="POST"
Test.cgi receives form text and radio option inputs, calculates the values of the user-selected radio options, and displays the results in a table with plain text paragraphs above and below the table.
The browser loads //domain/test.cgi and the minimally formatted content is spread across the entire width of the browser.
Ideally, I would like to display the test.cgi result within a WordPress page so it is consistent with the rest of the site, but I can't figure out how to do this.
Goals:
1 - Create an HTML form with radio answer options for several questions, and have those sent to cgi script - Succes
2 - Create cgi script to calculate values of selected options and display results in a table explaing text content above and below the table (for the user to read), so the user can see them in their browser - Success
3 - Display the script results on a WP page in an iframe (or some other way) for a better visual experience - Fail
Is there a way to do this?
I tried a couple of things:
I thought I might be able to display the results in an iframe so I created a WP page with an iframe
<iframe src="/cgi-bin/test.cgi" width="300" height="450"></iframe>
I tried sending the form (when submitted by the user) to this iframe WP page after submission. I thought that when it loads it might run test.cgi. Didn't work. It may have run the script, but I don't think the form inputs were passed on to test.cgi because it came back with the error used when users don't fill in their email. But, it was in the iframe.
Then I tried to change the test.cgi script so it would send to the WP page in the browser. Basically this:
#!/usr/bin/perl
use strict;
print "Location: /iframe-page-name\n\n";
script stuff here
#end of script
That resulted in server errors.
Related
I have an HTML form which a user may have filled in or partially filled in. I want to snapshot that state and render it as a PDF document. I've been using wkhtmltopdf.
I've tried this from both the client side and the server side, and the rendered result is always the original form, never the filled-in one.
I notice if I reload the filled-in form page I get back the filled-in form, but if I cut and paste the form's URL into a new window, I get the initial, non-filled-in form.
So I've convinced myself that, if I could use CGI::Session properly, I could successfully open a session identical to the filled-in session. I tried using CGI::Session::Plugin::Redirect with no joy. I think the key is that window.open() has to use the SID of the filled-in form window.
I don't have a lot of experience with CGI session management, so this has been a four-day quest to nowhere. Any advice is appreciated, even if it's to abandon this approach and go back to the more common post->render a new form in a new window, and generate the PDF from that. I'd like to avoid all of that if I can.
Say you have the following HTML document on your web server:
/var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<form action="/process.cgi">
<input type="text" name="foo">
</form>
</body>
</html>
When you navigate to http://hostname/index.html in your browser, the webserver returns this document and the browser displays it.
When you fill in the text field in your browser, the document on the webserver doesn't change. So anybody who navigates to http://hostname/index.html will get the original, unmodified form. This is why you can't simply copy and paste the URL into another browser tab and get the filled-in form.
Most browsers use caching by default. When you fill in some fields in a form, the browser caches what you entered. When you reload the page, the webserver sends the exact same document as before* (i.e. the unmodified form), but the browser uses the cached data to fill in the form fields the way you had them. If you override the cache when you reload the page (Ctrl+F5 in Firefox), the form fields will not be filled in. Note that neither the URL nor the document on the server have changed. This is why you can't copy and paste the URL into another browser tab after reloading the page and get the filled-in form.
wkhtmltopdf takes a URL, renders the corresponding page, and generates a PDF based on what is rendered. Based on the explanation above, it should now be clear why wkhtmltopdf always generates an image of the unmodified form.
The solution
If filling in form fields doesn't change anything on the webserver, what does it change? It changes the DOM, a structure describing the document in your browser that you can access using JavaScript.
One approach would be to use a client-side JavaScript PDF generator like jsPDF; since it runs on the client, it has access to the DOM that the user is interacting with, so it can "see" the values the user enters into the form fields.
* Actually, the webserver will typically send a 304 Unmodified response to save bandwidth, but form caching works the same either way.
The explanation from ThisSuitIsBlackNot is accurate about why your design is failing. Typing characters into form fields in a browser changes only your screen and the data in the memory allocated to the browser.
I suggest a different solution. The WWW::Mechanize::Firefox module is a variant of WWW::Mechanize that uses a real browser application to retrieve and render web pages. It is mostly chosen when a site requires JavaScript support, but it is useful here because it has a content_as_png method which returns a PNG image of the current page. Hopefully that is enough for you to build a PDF file with the required content
I've got an A/B Test set up in Adobe Test-and-Target. The idea is that 50% of the time, visitors to a certain page should be redirected to a different page instead. It is working correctly, in that half of users are sent to the new page.
However, sometimes the entire original page is loaded before the redirect happens. I put the mbox in the head tag of the page, which I thought would ensure the redirect happened before any HTML was displayed to the user, but that's not happening.
How can I create a seamless result for the user, where the redirected users only see the new page loading, and never see the original page?
For our site, the <script src="http://maur.imageg.net/js/mbox.js" ></script>is at the very end of the head tag and works fine.
Your mbox.js should be as close to the top as possible and then your inline mbox should be defined preferably right after the tag. This way the request is made before the content starts to render, and the redirect kicks in before the guest even sees the page.
Avoid using anything post DOM related for example jQuery's:
document.ready( function{});
If you paste your code you're using for the A/B - we be able to review & respond accordingly.
However pure Javascript and pure CSS should execute seamlessly.
You can use CSS first to not show anything
<style>
body {display:none!important}
</style>
Then use JavaScript to redirect the page to new page.
I am using jeditable and had it working very weird.
after editing the editable field and submits it instead of printing the new content it displays the entire document window in the textbox(placeholder of editable content).
question: from the example where the author used save.php. what was the content of save.php?
is it necessary to send the result on a php file?? can't an HTML file work?
I believe within the comments box at the bottom of the author's main page - somebody has kindly provided a version of the save.php file for people to use and modify as needed.
The save.php file is used to actually save the values of the editable field/s. Without it, nothing would happen to the data and it would reset to the default text if the page is refreshed.
Options instead of a php file could be:
Saving the text/select changes to a Cookie
Using another server side methos such as asp, jsp, rails or .NET to process the saving of the changes.
an html page is a static page with no processing facility per say to communicate with the website server, so no.. html is not suitable for such a need.
Saving script must return the string you want to display on page after editing. You are now returning full html page.
Source of for all demofiles can be found from GitHub.
I'm trying to add the facebook 'Like' button to my CiviCRM civiMail footer template.
When I paste the downloaded code into the footer code the CiviCRM editor flags up the following error
"Illegal characters in input (potential scripting attack)"
(I have pasted the code into my HTML pages and added to my Wordpress pages and it works fine in both but wont work in CiviMail)
Anyone know how to do this?
You can't embed script code into HTML emails. At least you can't and expect it to run. The best you can do is embed some kind of fake like button that is a simple image and hyperlink to your fan page or the url that you want people to like which will open in their browser and then they could like it from there.
I have a form which submits to an iframe, This works fine if you are on a page with the iframe.
I want to be able to have the form on any page and when submit is pressed load a page and send the submit to the iframe
e.g.
On page "article.php" and press submit
Open page "results.php" and
Send post data from form clicked in "article.php" to iframe "DataHere" on "results.php"
Thanks in advance
You could try detecting if the frame exists when the form is submitted and if it does not, reload the whole page and generate the iFrame.
If you need a hand checkout http://www.java-scripts.net/javascripts/Check-Frames-Page-Script.phtml
If you are able to comfortably sanitize your initial POST data to avoid XSS, you could create an intermediate page for your iframe destination that does your POST for you:
On page article.php with <form action="results.php">, press submit.
results.php validates that the input isn't XSS, and renders with a <iframe src="negotiator.php?my=form&data=here"></iframe>
negotiator.php takes the query string arguments (and runs the same sanitizing as results.php) and POSTs them to your intended url.
Your results will load in the iframe.
It's pretty important that you make sure your input isn't insane. If your form requires arbitrary text, punctuation, and special characters, this is not safe for you.