After plenty of searching I managed to come across the certain factors that need to be in place for this to happen and hopefully this might just one day help someone else out.
Then upon submitting your first post value will dissappear. Here is a link to a PHP Bug thread covering the issue - and it’s not PHP specific, its purely IE6. Below is the sample code that will reproduce the error:
<form method="post" action="whatever" enctype="multipart/form-data">
<input type="text" name="field1" value="1">
<input type="text" name="field2" value="2…">
<input type="checkbox" name="field3" value="3">
<input type="submit">
</form>
All I have done to stop it in the meantime is added a ‘fake’ hidden post value at the start so it gets destroyed instead of a value that is actually required.
]]>We have started re-writing it now on the CodeIgniter framework along with giving it the extra dimension of multiple user accounts so you can signup to register a new account as this will be a hosted web application service. Some of the features include the following:
Whilst we don’t have an exact release date, we would hope with in the next 3 months will be the likely release date. If you do want to know more, be certain to visit the site and send us your email address to be updated when more information is available.
]]>One of the common approaches these days is to use a image verification system (usually called Captcha) but this can become very annoying for an end user especially when it is difficult to read. Plus, these forms are usually enquiry/contact forms which are very critical to help generate sales for the client so making them unattractive and difficult to a end user can reduce the number of enquiries sent.
One of the common traits of the scripts out there that are auto spamming all of these forms is that they are done through very simple methods and don’t support features that most broswers do such as Javascript - we can use this to our advantage.
In your form create a hidden input and make its value empty such as the sample code below:
<input type="hidden" name="js_check" id="js_check" value="" />
Now create a javascript file that is loaded on the form page and insert the following code:
document.getElementById('js_check').value = 'pass';
$('input[@name=js_check]').val('pass');
Then all you need to do is where the form is posted to is check that $_POST[’js_check’] is equal to ‘pass’. If it isn’t then send the user back to the form and inform them that they need javascript required to complete the form.
I would usually jump up and down here and say “oh that’s not right to depend on javascript” but honestly speaking the stats show that now 95% of people have it enabled and as long as you redirect them back informing them that they need it enabled they will know why the form was not sent.
For the amount of spam this stops for the minimal implementation time and small amount of users that maybe affected I think it is well worth adding to your forms instead of a Image Verification method.
]]>After a quick search around I found I wasn’t alone with encountering the problem with a thread on Mozillazine discussing the same issue which then lead me to a bug report covering the same problem.
I started to see a few posts in the bug report indicating that when you disable firebug (a FireFox plugin that most web developers have turned on - especially when trying to work out problems like this!) that the issue is no longer there. I gave it a go and sure enough the problem was gone.
FireBug for FireFox 3 is still in beta version and the current version that the problem is happening with 1.2.0b7 was only released a couple of weeks ago.
I went hunting for an earlier beta version and still had the problem in beta 6, but managed to find a beta version that didn’t have this problem - beta 4.
I got it from the following site but the file to look for if wanting another mirror is firebug-1.2.0b4-fx.xpi
http://releases.mozilla.org/pub/mozilla.org/addons/1843/
I did a bit more investigation and came across a way to still use the latest beta version (as I certain there would be a few bug fixes) and not encounter this problem. What you need to do is disable the ‘Net’ panel in firebug and the problem is gone!
Got excited that there was a new beta release (13) on 18th August only to find this same problem persisting. You would think that something as major as this would have been fixed within 5 beta releases! Additionally here is a link to the issue being seen by many others as well still.
I also made a test page so the developers can see exactly what is going on which is located here. Just turn on the console and net panels in firebug and you will see it stop working.
]]>Below is a sample of the code I originally tried
$('.addFieldForm').validate({
event: "keyup",
rules: {
field_name: "required"
},
etc. etc.
It would only end up submiting the first form using the above code. The solution thankfully wasn’t too complex - just took a while to think of the solution! What you need to do is use the ‘jQuery.validator.setDefaults‘ option and set the validation details you are going to use for the forms. Then the big secret on how to attach to each form is below:
$('.addFieldForm').each( function(){
$(this).validate();
});
Nice and simple solution!
]]>Below is how I have it setup at the moment in CodeIgniter and yes its not a controller as such but pretty much acts like one and keeps all application code in the one spot hence the location/setup.
(If you are like me and have application folder set outside of the system folder then remove all instances of ‘system/’ and set the baseDir with one less ‘../’)
1. Extract the ‘smartoptimizer’ folder into ‘system/application/controllers/smartoptimizer’
2. Add the smartoptimizer htaccess details to the bottom of my htaccess details and replace all instances of ‘smartoptimizer/’ with ‘system/application/controllers/smartoptimizer/’
3. Edit ‘system/application/controllers/smartoptimizer/config.php’ and change the following settings as below:
$settings['baseDir'] = '../../../';
$settings['cacheDir'] to '../../cache/';
]]>Showing the duplicate queries in CI is easily achieved with the addition of a Library Extension that extends the standard profiler. If you haven’t already started using this handy debug tool you should switch it on as it’s easy to do - just at the bottom of any controller function/method just insert the following:
$this->output->enable_profiler(TRUE);
It is as simple as opening the following file and saving it as ‘MY_Profiler.php’ in your ‘application/libraries’ folder. Once placed in there any duplicate queries will be shown along with the number of duplications of each query.
Notes
- If you are having any problems trying to get it work please feel free to comment in here
- If you have found any errors please let us know
- Yes, I chose the sexy Magento colour
Below is the function that we developed for this - we got a few ideas for the function from the CSS Colors Class developed by BarelyFitz Designs and we highly recommend this class if you are needing more advanced colour functions such as colour comparing.
Below is a snippet of the code and usuage guide.
function colourBrightness($hex, $percent) {
// Work out if hash given
$hash = '';
if (stristr($hex,'#')) {
$hex = str_replace('#','',$hex);
$hash = '#';
}
/// HEX TO RGB
$rgb = array(hexdec(substr($hex,0,2)), hexdec(substr($hex,2,2)), hexdec(substr($hex,4,2)));
//// CALCULATE
for ($i=0; $i<3; $i++) {
// See if brighter or darker
if ($percent > 0) {
// Lighter
$rgb[$i] = round($rgb[$i] * $percent) + round(255 * (1-$percent));
} else {
// Darker
$positivePercent = $percent - ($percent*2);
$rgb[$i] = round($rgb[$i] * $positivePercent) + round(0 * (1-$positivePercent));
}
// In case rounding up causes us to go to 256
if ($rgb[$i] > 255) {
$rgb[$i] = 255;
}
}
//// RBG to Hex
$hex = '';
for($i=0; $i < 3; $i++) {
// Convert the decimal digit to hex
$hexDigit = dechex($rgb[$i]);
// Add a leading zero if necessary
if(strlen($hexDigit) == 1) {
$hexDigit = "0" . $hexDigit;
}
// Append to the hex string
$hex .= $hexDigit;
}
return $hash.$hex;
}
You do not have to give the colour with the ‘#’ in fron but if you do it will still return the new hex colour with the ‘#’ auto-magically.
$colour = '#ae64fe';
$brightness = 0.5; // 50% brighter
$newColour = colourBrightness($colour,$brightness);
$colour = '#ae64fe';
$brightness = -0.5; // 50% darker
$newColour = colourBrightness($colour,$brightness);
]]>The link we were getting the HREF value from was set as below
<a href="uploads/images/photo.jpg"></a>
We were trying to obtain the HREF using jQuery with the following code:
$(this).attr('href')
But this would return the absolute link (eg. http://www.domain.com/uploads/images/photo.jpg) instead of the HREF that was set. Usually we would use absolute links everywhere but didn’t in this case as we just needed the image address.
We then tried the basic javascript way of getting the href as below which still didn’t work:
<a href="uploads/images/photo.jpg" onclick="alert(this.href);return false;"></a>
We then found the following post which worked but as our system was using AJAX later to get more links for some reason IE still wanted to automatically append the full URL.
<a href="uploads/images/photo.jpg" onclick="alert(this.getAttribute('href',2));return false;">
In the end we went for the way that was our last option. We output the absolute link and we set a hidden input field with our base_url (eg. http://www.domain.com/) and then did a replace over the href with the base_url. Not the most elegant solution but unfortunately the only way we could get it to work:
var href = $(this).attr('href');
var imgPathFull = href.replace($('input[@name=base_url]').val(),'');
var img = '
‘;
]]>The first thing I did was to look at the current connections in the mySQL server so I could see what sites were causing the problems which can be achieved by the following when accessing your server by SSH:
mysqladmin -uUSERNAME -pPASSWORD processlist
The first thing that came to my attention was a heap of connections left in sleep mode for 10000 seconds and over! Obviously these were counting to the ‘max_connections’ standard setting of 100.
The other thing I found odd was that majority of these databases were all CodeIgniter (a PHP framework) based. After a bit of quick research I was able to narrow the problem down to the use of the mySQL pconnect (persistant connection) option with many suggestions on not needing to use it. The odd thing was that CodeIgniter has this set to be ON by default and hence why all of these sites were appearing in the processlist.
To fix this issue in CodeIgniter simply goto your /application/config/database.php file and change the following setting as follows:
$db['default']['pconnect'] = FALSE; // Was set to TRUE
For anyone else using PHP avoid using the ‘mysql_pconnect’ command and use the ‘mysql_connect’ command instead.
And lastly for anyone using a server and needing to stop other sites from using this you can change the following setting in your php.ini file:
[MySQL]
; Allow or prevent persistent links.
mysql.allow_persistent = Off
]]>