Basic rules for SSL protection for a website
How would a secure implementations look like and where can one expect problems?
These rules are intended to provide SSL protection, that is protection against an opponent that can intercept and alter packets.
You probably into mixed mode in some scenarios
If, in a HTTPS page, you load any script, or CSS resource in plain http, that nullifies the SSL benefit (not just reduce).
As a rule, in a HTTPS page, load every subcomponents (frames, scripts, styles, images) over HTTPS, from trustworthy hosts.
A particularly unfortunate mistake is to forget to make all cookies "secure". If you forget to mark all security relevant cookies with this attribute, it nullifies the SSL security. (Obviously a login/session cookie is security sensitive.)
As you want your website to be entirely over HTTPS, mark all cookies "secure".
One problem is that even "secure" cookies can be replaced by cookies HTTP non-secure cookies! What makes it even worse is that the browser will not even tell you if the cookie came from HTTP or HTTPS!
You can assume that a secure cookie cannot be read by an opponent. But you cannot assume that a cookie sent by a browser over HTTPS is the secure cookie you sent previously.
Whole site SSL protection
By providing content over HTTPS not just for some "sensitive" pages, but for the whole site, you will train users to only use your site over HTTPS which is quite good for security.
In order for users to be able to enter an HTTP URL, you will certainly do an HTTP redirect from HTTP to HTTPS, so that the only non-encrypted HTTP traffic is a HTTP redirect (in the usual, no attack, case).
The problem here is that if users get used to type the HTTP URL, and they might fail to check every time that they are properly redirected to the corresponding HTTPS site: an attacker that can intercept and modify packets can alter the HTTP request to redirect to another misleading HTTPS site, or just assume that the user doesn't usually doesn't detect the HTTP/HTTPS difference: this is a good reason to use HSTS.
Other website security principles
The SSL cryptographic protection is an essential part of website security, especially to protect the secrecy of passwords. But it isn't the end of the security requirements that are specific to websites.
Just as a reminder, some other essential security principles:
Safe handling of untrusted data
When taking user input and outputting it in web page, you must apply proper escaping to avoid XSS vulnerabilities. For this, you must understand that different parts of the HTML page have different syntax (normal HTML, attribute value, URL have completely different syntaxes) and thus need different escaping.
As in any other program taking external untrusted input, you must properly validate every input, and store and output it in a way that does not misbehaved if an unusual character is present (see: SQL injection).
Verification of authorisation on the web
You cannot only rely on cookies (or HTTP authentication) to validate that a specific order from a HTTP client is authorised: doing so would expose your website to a CSS attack from another website if the user browse both websites in the same browser.
My view of secure design
The problem with website security is often caused either by not understanding the different specific requirements of these web protocols, or by securing all but one "entry point".
Before you even to design a "secure" website, you should understand all these requirements; then you should apply them in a systematic way. Your design should be simple, regular, understandable, and easy to audit.
The best style is one where you just cannot forget to apply to escape text that is going to be interpreted as HTML/HTML attribute/SQL/SQL "regexp"/shell commands/shell regexp. The best approach, when possible, is to prevent variable data that is not intended to be interpreted as HTML/HTML attribute/SQL/SQL "wildcard expr"/shell commands/shell regexp to appear in such context that it requires escaping: avoiding need to escape is safer because you cannot forget to escape things.
I know that I am drifting off topic here... so I will stop now. I just wanted to it clear that HTTP security doesn't stop at "100 % over SSL".