I rewrite rules like site.com/product/p1 to site.com/product.php?p=p1 successfully.
Now, I want to the the opposite, convert the query that is received from a form submission site.com/product.php?id=1234&name=test to site.com/product/test/1234 i.e. I don't want the site visitor to see the query parameters.
To make things more clear: on my site I have a form with two text input fields (and a few hidden fields as well); visitors can enter the product id and product name and submit the form. I want the resulting url (after the form submission) to be flat (site.com/product/test/1234) and not include any params.
Of course, I want my script (product.php) to retrieve all the parameters from the form. I guess I could do that in the same fashion that I turn site.com/product/p1 into site.com/product.php?p=p1.
Could anyone help me out?
mod_rewrite will not be flexible enough to do this in general. It's fine when you have one (and only one) query parameter to handle. As you add more, you need to handle every possible combination of query parameters, and have a new rule for each. mod_rewrite is only appropriate if you can no longer serve URLs in the old style, for example if you are upgrading a third-party server you cannot modify, and want to have httpd handle redirecting old bookmarked links to the new locations.
It is best to handle this inside your PHP script itself. The script at the "old" product.php?id=1234&name=test URL should read the GET parameters and return a HTTP 301 response ("Moved Permanently") to the new product/test/1234 URL. This will work if the request goes to product.php, or product.php?name=test, or product.php?id=1234, or product.php?name=test&id=1234. The script determines what to do with missing values, and how to build the replacement URL.
To do the rewrite with just a single query parameter, it will look like the reverse of your successful rewrite rule, e.g.
RewriteCond %{QUERY_STRING} ^p=(.*)$
RewriteRule /product.php /product/%1 [R]
I'm trying to add my email address in Store Email Address, But it is saying "Invalid email address "admin#mydomain"."
Note that my tld is uncommon.
I think that is the reason for the error message.
I can add .com email address easily btw.
Is there any way to add the email?
Thank you.
in validation.js you have
['validate-email', 'Please enter a valid email address. For example johndoe#domain.com.', function (v) {
return Validation.get('IsEmpty').test(v) || /^([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*#([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*\.(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]){2,})$/i.test(v)
}],
You will have to play with this regular expression.
if you look into this expression you will find a . jsut remove every thing excluding ] from . till end and should solve.
I had the same issue, but your suggestions were misleading.
The error message comes up not from this java script, but app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Email/Address.php
The error is generated from lib/Zend/Validate/EmailAddress.php, because it calls hostname verification from Hostname.php in the same directory.
There you can find in row nr. 117 an array called $_validTlds
there put your domain ('works' or in my case 'wien'), take care alphabetical order, and quotes and commas. save and try again,
it will work. Good luck.
What I'm trying to do is format the email address like so Foo Bar <foo#bar.com> so email clients (including web based like gmail) will show the sender as "Foo Bar" and not just "foo" since that is the prefix on the email.
Is this possible in Magento 1.5? If I try to put the formatting in the field itself I get an error message.
That's what the Sender Name field does. This is what my setup looks like and what it looks like in Thunderbird (my webmail client formats it similarly, too):
You may look at code/core/Mage/Core/Model/Email.php for the actual mail implementation. You may notice it uses Zend_Mail. Now, here is the catch:
For security reasons, Zend_Mail filters all header fields to prevent header
injection with newline (\n) characters. Double quotation is changed to single
quotation and angle brackets to square brackets in the name of sender and recipients.
If the marks are in email address, the marks will be removed.
What you can do though is to make a module to rewrite the current class Mage_Core_Model_Email and overwrite the send() function. I covered rewriting classes before in this question's answer. Then, in this new rewritten class, you could PHPmailer, invoke shell mail commands, or whatever PHP library you would happen to know that would allow this behaviour.
Best of luck.
I'm not sure if it can work. In magento inside is a Zend_Validate which does validation of such email addresses. And I dont think so that email like 'Foo Bar ' is valid. But I think the display in customer's email client depend on client, no?
I am looking for the syntax to add node fields to the body of an email. Examples I looked at the documentation, and the format is [content_type:content_type_title].
However, my email arrives with just the string [content_type:content_type_title].
Even better would be a PHP snippet that loads the node and dumps filed title and filed value into the body of the message.
Rules supports the Token module, which should allow you to do something like that.
Use node_load($nid) or db_query to get the node you want, use that in the email function you are creating.
I have a couple search forms, 1 with ~50 fields and the other with ~100. Typically, as the HTML spec says, I do searches using the GET method as no data is changed. I haven't run into this problem yet, but I'm wondering if I will run out of URL space soon?
The limit of Internet Explorer is 2083 characters. Other browsers, have a much higher limit. I'm running Apache, so the limit there is around 4000 characters, which IIS is 16384 characters.
At 100 fields, say average field name length of 10 characters, that's already 5000 characters...amazing on the 100 field form, I haven't had any errors yet. (25% of the fields are multiple selects, so the field length is much longer.)
So, I'm wondering what my options are. (Shortening the forms is not an option.) Here my ideas:
Use POST. I don't like this as much because at the moment users can bookmark their searches and perform them again later--a really dang nice feature.
Have JavaScript loop through the form to determine which fields are different than default, populate another form and submit that one. The user would of course bookmark the shortened version.
Any other ideas?
Also, does anyone know if the length is the encoded length or just plain text?
I'm developing in PHP, but it probably doesn't make a difference.
Edit: I am unable to remove any fields; I am unable to shorten the form. This is what the client has asked for and they often do use a range of fields, in the different categories. I know that it's hard to think of a form that looks nice with this many fields, but the users don't have a problem understanding how it works.
Are your users actually going to be using all 50-100 fields to do their searches? If they're only using a few, why not POST the search to an "in between" page which header()-redirects them to the results page with only the user-changed fields in the URL? The results page would then use the default values for the fields that don't exist in the URL.
To indirectly address your question, if I was faced with a 100-field form to fill in on one page, I'd most likely close my browser, it sounds like a complete usability nightmare.
My answer is, if there's a danger that I'm getting anywhere near that limit for normal usage of the form, I'm probably Doing It Wrong.
In order of preference, I would
Split the form up and use some server-side state retention
Switch to POST, and then generate and redirect to a shorter URL on POST that resolved to the same result
Give up ;)
You mention in a comment that many of the fields "are hidden and can be opened as required".
If you are willing to discard graceful degradation, you could always actually add and remove the fields from the form, rather than just hiding and showing them: the browser won't submit the ones that aren't included in the form.
This is a variant of the "Make and model" forms that online insurance etc. pages use -- select the make, submit back to the server and get the list of models for that manufacturer.
If you don't mind using javascript then you could have it work out the length of the query string and if it is too long then switch to a post. Then have some sort of url mapper to allow them to bookmark these posted searches.
Use post and if the user bookmarks the search, save it in a database and give it a unique token, then redirect to the search page using GET and passing the token as parameter.
TinyURL is a nice example: You give it a very long URL, it saves it to a DB, gives you a unique identifier for that URL and later you can request the long URL using that identifier.
In PHP it would be something along the lines of:
<?php
if (isset($_GET['token']))
{
$token = addslashes($_GET['token']);
$qry = mysql_query("SELECT fields FROM searches WHERE token = '{$token}'");
if ($row = mysql_fetch_assoc($qry))
{
performSearch(unserialize($row['fields']));
exit;
}
showError('Your saved search has been removed because it hasn\'t been used in a while');
exit;
}
$fields = addslashes(serialize($_POST));
$token = sha1($_SERVER['REMOTE_ADDR'].rand());
mysql_query("INSERT INTO searches (token, fields, save_time) Values ('{$token}', '{$fields}', NOW())");
header('Location: ?token='.$token);
exit;
?>
And run a script daily:
<?php
mysql_query('DELETE FROM searches WHERE save_time < DATE_ADD(NOW(), INTERVAL -200 DAY)');
?>
Also, does anyone know if the length
is the encoded length or just plain text?
My guess was for encoded length. I made a simple test: a textarea and a submit button to a simplistic PHP script.
Loaded the page in IE6, pasted some French text in the textarea, 2000 characters. If I hit the submit button, nothing. I had to reduce the length of the text to be able to submit.
In other words, the 2083 character limit is exactly the maximal length of the URL found in the address bar after submitting the GET request.
I would go for the JavaScript solution: on submit, analyze the form, create a secondary form with hidden attributes, and submit that.
Some strategies on shortening the output:
As you point out, you can already skip all values left to default (no field, no value).
If you have a form like the one at Processing forum search you can group all checkbox states in one variable only, eg. using letter encoding.
Use short value attributes (in select for example).
Note: if the search page is actually composed of several independent forms, where users fill only one section or another, you can make several separate forms.
Might not apply to your case and might seems obvious but worth mentioning for the record... ^_^
One could philosophically look at the search submission POST as the creation of a saved search (especially when a search is as complex an object as the one your users are making). In this case, you could accept the post for the creation of a search and then redirect using a GET to fetch the appropriate search results (post/redirect/get).
This would also allow the users to bookmark the search results (GET) to coming back at any time to re-run the search.
Get can have one advantage if your search results can be shared, in case of post request if you send the link to someone, that person won't see any search results