Ive used Paul Irish's excellent infinte scroll on a number of projects before but recently found that I was having issues with ending the scrolling after the last items was retrieved on Hikashop. The issue is due to Joomla's error handling - instead of returning a 404 'page not found' error response it returns a normal page ok response (200) - it can do this intentionally when it provides a useful user defined 404 error page but can also do this unintentionally as in this case. This behavior is commonly known as a soft 404.

As infinite scroll relies on a 404 error being returned when there are no more pages to stop further processing, the net result is that the scrolling keeps on going. Not a massive issue but one that results in an annoying animated icon appearing when you scroll past the end of the page.

In my opinion this is not necessarily the best way of detecting the 'end of the internets' as it assumes that the 404 error means there are no more pages. I'm sure we all know what assumptions usually lead to. By far the best way to determine if there is no more data is to check the actual data itself.

I initially tried looking at the length of the data returned but found that this was not really suitable as it contained the entire page and was really hard to separate the parts that I required although this is possibly due to my lack of javascript skills more than anything else. After some testing I found that instead of looking at the data length looking at the length of the child elements returned was the way to go. I this way I could detect when no more data was present.

If you are experiencing memory issues with scripts, it may be necessary to increase the memory available to the script.

If you have access to your servers php.ini file, this is relatively straightforward - simply increase the value of the memory_limit directive to 128M then restart apache. However, I'm guessing that if you're reading this post, looking for a solution to memory issues, then the last sentence probably made little sense, and chances are that you do not have access to your servers php.ini file - this is true for most shared servers.

If you do not have access, all is not lost - you can override the value in either a custom php.ini file, or via the htaccess file - the method needed depends on the following:

If PHP is compiled to run as a cgi script then you will need to use a custom php.ini, but if it is compiled to run as a module then you will need to use htaccess. (tip - you can view your servers php_info() to find out which one)

Some of you may be familiar with the heredoc string handler which allows multi-line strings to be easily assigned to a variable, this great tool has many uses - such as retaining pre-formatted layout and improving the readability of code. The heredoc handler also parses variables contained within the string - much the same way that using double quotes does. Replacing any variables with their respective values

This has some not so obvious drawbacks, one of which i discovered whilst trying to inject complex PHP code into a database for later evaluation via the eval() statement. (please don't ask why)

The problem I found was that whilst it was easy to escape the string so that it would not break the SQL statement, The same escape characters also broke the evaluation. This might not have been an issue in any other situation, but for this particular project i did not have access to the code that carried out the evaluation so that I could strip the escape characters out before running the eval query.

However, PHP 5.3 has now introduced the nowdoc syntax - this basically operates in the same manner as heredoc, but does not parse any of the content. This means that not only are variables not parsed, but neither are any characters that would normally require escaping. In essence, any string read into a variable by the nowdoc handler will not require any escaping whatsoever.