William Cameron | Beyond the Keyboard

Retailers frequently add new product lines, brands, or even seasonal items. When these fresh items are introduced, marketers call it a product launch. Product launches are important and frequent events in ecommerce marketing that may be managed with a promotional recipe, removing uncertainty and ensuring measurable results. This sort of marketing is common and, therefore, is best managed in a uniform way within each retailer. This product launch recipe does not imply some lack of creativity. Rather, it suggests the marketing tactics that each of these events should include, allows for consistent and comparable data from launch to launch, and it makes it possible improve common resources like email lists. A Common Thread A good product launch recipe begins with a common strategic goal for each launch event. This should be a standard goal — or type of goals — for all new product or brand introductions. For example, a certain number of sales of the product, the acquisition of some number

According to a post on ne tworkworld.com,  63% of webmasters whose websites get hacked don't know how the compromise occurred! The leading cause of website compromises appears to be outdated content management software (CMS). This was indicated as a reason for their websites being hacked by 20 percent of respondents. Twelve percent of webmasters said that a computer used to update their website was infected with malware, 6 percent said that their credentials were stolen credentials, and 2 percent admitted logging in while using wireless networks or public PCs. However, 63 percent of respondents didn't know how their websites got compromised. The CMS platform most commonly installed on compromised websites was WordPress, as indicated by 28 percent of respondents. However, WordPress accounts for over 50 percent of the entire CMS market according to data from w3techs.com, so the rate between hacked WordPress websites and the platform's actual install base is better than that

I noticed on some server setups I could not do the following inside a .htacess file: php_value upload_max_filesize 250M php_value post_max_size 250M I was getting an error 500 Internal Server Error with the above code in the .htaccess file. What to do to correct this is create a file called php.ini and save it in the same location as your .htaccess file and enter the following code instead: upload_max_filesize = “250M” post_max_size = “250M” One thing to note with this 'hack' is that the php.ini settings do not filter down through sub directories, and only affect scripts in the primary directory - This has caught me out a few times!

I have recently been looking at the PHP Framework CodeIgniter, and am quite impressed at its lightweight approach to providing an MVC framework for building PHP applications on. I haven't had as much time I would like to build anything meaningful with it, but on initial inspection, and every time I pick it up to look at, I am suitably impressed that I would be keen to develop something meaningful with it. Other frameworks do exist, such as Zend, Yii, CakePHP and Symfony.  But none of these are screaming out at me with the simplicity and admiration that CodeIgniter has done quickly from the offset.

I have read conflicting view points on whether the use of $_REQUEST in your code is good or bad. But, what is $_REQUEST, and how do I (ab)use it? - $_REQUEST, is an array of data, similar to form submission data $_POST and $_GET, which merges, $_GET, $_POST and $_COOKIE arrays into one 'easy to reference' array. Until around 3 years ago, I had never used $_REQUEST, and solely used $_POST and $_GET to fetch my URL parameters and form variables.  This was mainly due to the fact I was working on smaller scale projects, and was fully aware of the state of all the pages I was coding.  However, since beginning to work on larger projects, and utilise code written by other developers, I come across the $_REQUEST variable more and more.  Now I am not saying I am perfect, and I must admit I have been pulled to the dark side a bit and do use $_REQUEST overly much, but every time I do, I always look back on my code, and think - I should've taken the time to do this properly. Shoul