Pleased to report I’m back! The problem was that the “Human or Robot?” tick box had fallen off, probably due to a simple typo.
So far as I tell, login is working correctly for me this morning, but I’ve been caught by false dawns before. Based on previous experience, now it works, now it doesn’t symptoms are characteristic of back-end resource problems.
Application Developers are trained not to obsess about micro-efficiency because – most of the time – resources are managed by system software. In contrast, System software (operating system, databases, network services etc) is written to be performant, and is highly tuneable. Linux can be deployed on anything from a single CPU microcontroller with tiny memory and no peripherals, up to a multi-CPU super-computer with Terabytes of memory and a warehouse full of peripherals. Same Linux, but tiny and massive are configured very differently. Server-Windows has a narrower range of performance options, specialising in desktop and big commercial server farms rather than embedded systems or super-computers.
Modern hardware is so powerful that there is often no need to worry about performance. Reading up on WordPress, by default it is assumed that the customer is building a small web-site that will run off-the-shelf. This approach is typical of most software, because it allows developers to deliver functionality and look and feel without having to understand how it works under the bonnet.
I think what’s happened to Mortons is that the old forum managed more data and accounts than off-the-shelf WordPress can cope with. Failing to cope means sluggish performance and apparently random malfunctions due to time-outs, paging, insufficient storage for queues, and scale inefficiencies. The behaviour of the application varies depending on the load, which depends on who is logged in and what they are doing, plus external influences such as backing-up. Random malfunctions very difficult to pin down, because testing works or fails depending on whatever else the system is doing at the time.
What we see of WordPress as users is an unsatisfactory look and feel, and it’s tempting to think that’s the big problem, and everything would be fixed simply by switching to another product such as InVision. DANGER!!! Before doing that, it’s necessary to make sure that the InVision, or any other products, backend won’t overload in the same way as WordPress. I’ve read the WordPress documentation, but not InVision’s. My guess is they both take much the same approach.
WordPress has plenty of scaleability options but choosing which are needed requires performance skills and a good understanding of what’s overloading. That information is deep inside the system, and quite likely it will be necessary to turn logging on specially to get it, and maybe apply a load simulator to flush out the hot spots. It is possible that InVision being more modern, has a Wizard, or better diagnostic tools that make it easier to pin down and fix problems. I don’t know – anyone else?
Dave