A user, pfaffman, experienced an issue where they were unable to log in to their Discourse site after enabling read-only mode. This was due to the user not being logged in before enabling the mode. codinghorror suggested logging in before enabling read-only mode as a simple solution.
pfaffman pointed out potential issues with this approach, such as cookies being deleted or the person enabling read-only mode being unavailable. steef proposed alternative solutions, including a timer for read-only mode or a special URI to disable it.
pfaffman considered these suggestions and mentioned plans to develop a remote control panel for tasks like disabling read-only mode. Another user, Bathinda, shared a similar experience of accidentally locking themselves out after enabling read-only mode.
Bathinda later found a solution by running a command in the rails console to disable read-only mode, which they shared with the community: Discourse.disable_readonly_mode(Discourse::USER_READONLY_MODE_KEY).
I did an import of some Wordpress data to an already active site. I thought it would be a Good Idea to put the site in read-only mode while I was doing the import so that people wouldn’t add data to the site that would get erased when the site + import_data was uploaded.
That’s a Bad Idea. Now I can’t log in. On a self-hosted site, you can fix this from the rails console, on a hosted site, however, you’re stuck (I just emailed team). I tried /users/admin-login, but it can’t work either (obvious in retrospect).
This doesn’t seem like that much of an edge case, shouldn’t there be a way to freeze a site that still allows admins to log in?
As an alternative (or addition), perhaps a way to set a timer when enabling Read Only? Something like: Enable Read Only for: X hours.
Or maybe a special URI specifically to disable read only mode? Something like /admin/read-only which displays a login box for an administrator account and then disables read only when the credentials are correct. That wouldn’t need write-access to the database I imagine (only read to check the credentials).
Yeah. If I’d thought ahead to have an API key I probably could have fixed it that way. One of my plans is a remote control panel to do things like that. I think that there are a handful of tasks that it would be handy to be able to do via API calls via a remote web interface. Things like:
Creating sets of categories with certain colors and permissions for a particular purpose
control settings for sets of users
help to walk a user through Wordpress integration
It seems a little bizarre to build a web interface to remotely control a web app, but plugins get stale, and hosted people can’t install them anyway.
Casi me pasa a mí hoy.
¡No sabía que, una vez que activaba este modo y cerraba accidentalmente la pestaña de la ventana de incógnito, no había forma de volver a iniciar sesión!
¡Dios mío!
¡Qué fácil fue bloquearme a mí mismo!
¡Y no es menos que un milagro que, en solo 5 minutos (desde que desactivé el ‘modo de solo lectura’), tropezara con este post!
Ahora, al menos, intentaré recordar esto en el futuro, cada vez que quiera experimentar con algunos ajustes de administrador.