What could go wrong with a website?
Posted
#2973
(In Topic #576)
For a future version we're likely to add a system for automatically running checks to make sure a website is performing well.
The thinking is that websites are getting more and more complicated, more complicated than anyone could hold in their head, and things may go wrong without being noticed until it gets embarassing. Particularly after an upgrade happens, but it could be all kinds of triggers.
I'm interested in lists of what might go wrong with a site that could be automatically checked.
Here's my list so far:
- SSL certificate expired
- No description meta tag on front page
- XML Sitemap not building
- Front page loading slowly
- Database table(s) crashed
- Missing </html> tag on front page (implies page isn't fully generating)
- No guest access to front page
- Web server not accessible from external proxy
- E-mails not sending
- Outdated links on a regex of Comcode pages you've set to monitor
- Outdated copyright date
- Fall in Google position
- Fall in hits
- JS error on front page
- Integrity checker fail
- Stuff going into error log
- (Custom check hooks?)
I'd appreciate help expanding the list :).
Last edit: by Chris Graham
Posted
*Improper loading of CSS or Javascript (usually indicates a template error)
*Internal server errors
*CRON tasks not successfully running all the way through
*Unusual / unexpected POST data from forms (such as forms being sent completely blank, or post data not matching what, say, Javascript or autosave had on record, or unusual increase in the number of errors relating to improperly filled in fields for specific fields on specific forms).
*Access denied errors for people who should not be getting them according to permissions.
*Corrupted cache
*Cache misses when there should not be misses
*Server IP banned itself
*Administrators getting banned, either by username or by IP
*Unusual increase in rate limiting triggers (could indicate a distributed denial of service attack).
*High server load
*Unusual increase in failed logins
*Hanging processes
*Unexpected redirects (eg. Composr notices someone is redirected to a page that is different from what Composr expected… extra flag if such page is not a part of the configured domain [only way I think this could be checked is if Composr notices a page hit was not recorded on the page Composr expected the user to end up]. Could indicate rewrite issues or possible malware hack).
*Problems with cookies
*CAPTCHA not generating / getting unusual POST data / users putting in expired codes (could indicate CAPTCHA is not regenerating on the client side when it should)
*Users getting logged out unexpectedly when they should not be getting logged out.
*Users being asked to confirm their session when they have already confirmed it.
I will post more if I think of them
Posted
re Outdated copyright date
If you are referring to the configuration copyright stuff, i.e. "Copyright © 2012-$CURRENT_YEAR=2016 ACME Corps", maybe to set the default copyright code line to include the code "$CURRENT_YEAR=$DATE". You could pick up the start year from from the system date at installation time. The installing person could then further edit the line to put the starting copyright date and the company name if they need. (Maybe just append the Site Name—since it is a required field in the General section of the Site Options).
Posted
I'm not referring to automation.bobmiers said
Chris:
re Outdated copyright date
If you are referring to the configuration copyright stuff, i.e. "Copyright © 2012-$CURRENT_YEAR=2016 ACME Corps", maybe to set the default copyright code line to include the code "$CURRENT_YEAR=$DATE". You could pick up the start year from from the system date at installation time. The installing person could then further edit the line to put the starting copyright date and the company name if they need. (Maybe just append the Site Name—since it is a required field in the General section of the Site Options).
From “Post #2961”, 9th Jun 2017
I don't think there's an issue with the "from date" needing to be automated. I was very reluctant to introduce automation on the to date, which is why by default it is based on content dates. On the from date, we don't know if the copyright starts from the site was built, or if content was made years earlier. Plus I don't think a from date really serves a purpose so we don't have one by default. Either way, it is trivial to set that in the configuration.
I'm referring to cases where people choose to not have it automated, either because they want control over it (they want to explicitly update it each year to ensure it is legally accurate), or if perhaps it's been hard-pasted into the design (common for people building a site from a static design).
0 guests and 0 members have recently viewed this.