If a user tries to paginate the blog using a value that is not an integer SilverStripe will throw a server error.
Example. Visiting `blog/?start=10.1` will cause the following server error:
```You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '10.1' at line 8```
This change casts the pagination variable to an int before using it.
If a user tries to paginate the blog using a value that is not an integer SilverStripe will throw a server error.
Example. Visiting `blog/?start=10.1` will cause the following server error:
```You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '10.1' at line 8```
This change casts the pagination variable to an int before using it.
Adding "string" to the possible return types of category()/tag() didn't stop the scrutinizer from raising two new issues, so I've reverted that change. In future tags/categories may be split into separate controllers (it's cleaner that way), so these "issues" may serve as a reminder.
NOTE: This means that the documented return type for rss() is also wrong
- The RSS feed link was always the blog's root URL, even for category/tag feeds. FIXED
- Changed the return type documented for category() and tag() to include string for the case where an RSS feed is returned (addresses the "Scrutinizer" issues)
- Removed hardcoded URL segment (was test code that I forgot to remove)
- Changed if($rss to if(is_string($rss)
- Moved bracket after isRSS() to next line
- Made rssFeed() protected as it's an internal function and shouldn't be part of the public API
Problems resolved:
1) Case sensitivy of check on Code field of Group
2) MySQL and Postgres have different date functions
3) When BlogID is empty, explicitly set it to 0. If not then all tests break under Postgres
