ADD Maintenance to CMSimple_XH 1.6.5

cmb · Post by **cmb** » Fri Dec 12, 2014 2:41 pm

Holger wrote:I would welcome to have a real maintenance mode in the core, maybe controlled by a file in the download folder, as it's done with the debug-mode.
And, of course, there must still remain the possibility to log in...

That would help with regard to plugin updates, but it still doesn't solve the issues when updating/upgrading the core, what I consider the main problem. Nonetheless, something to consider.

Holger wrote:BTW, what happened to this proposal: viewtopic.php?f=29&t=6262 ?

I have not been able to fully reconstruct this decision. On July 10, 2013 Frank noted a problem with the detached login form in an email to me: looks really strange when you have a dark template. I faintly remember to have that discussed with you in the following, but I can't find the email (likley it was via PM). Anyway, now it's on the roadmap for XH 1.7. Not sure if nobody voted, or if the votes had been deleted in the meantime; probably the former, but you'll never know. We should consider to improve the roadmap or move to some better system.

FWIW: the XH_builtinTemplate() has been already implemented; originally with r659. r788 turned back the detached login form.

PS:

svasti wrote:However controlling it via a file in the download folder would mean controlling it via ftp.

Not necessarily; one could upload/rename the file via the filebrowser.

svasti wrote:In this case one could just as well change something in the index.php.

If at all, I would prefer a change to cms.php, because for multilingual sites there are multiple index.php involved.

Holger · Post by **Holger** » Sat Dec 13, 2014 10:15 am

cmb wrote: That would help with regard to plugin updates, but it still doesn't solve the issues when updating/upgrading the core, what I consider the main problem.

That's not true, if you agree that 'index.php' is part of the core

./index.php:

Code: Select all

<?php

if (file_exists('./cmsimple/.maintenance')) {
    session_start();
$t = count($_SESSION['xh_password']);
    if ($t !== 1) {
        if (!isset($_GET['login']) && !isset($_POST['keycut'])) {
            include('./cmsimple/maintenance.html');
            exit;
        }
    }
}

include('./cmsimple/cms.php');

?>

./2lang/index.php:

Code: Select all

<?php

if (file_exists('./../cmsimple/.maintenance')) {
    session_start();
$t = count($_SESSION['xh_password']);
    if ($t !== 1) {
        if (!isset($_GET['login']) && !isset($_POST['keycut'])) {
            include('./../cmsimple/maintenance.html');
            exit;
        }
    }
}

include('./../cmsimple/cms.php');

?>

./cmsimple/maintenance.html:

Code: Select all

<?php
header('HTTP/1.0 503 Service Unavailable');
header('Content-Type: text/html;charset=UTF-8');
?>
<!DOCTYPE html>
<html lang="en">
    <head>
        <title>Maintenance</title>
        <style type="text/css">
            body {
                text-align: center;
                font-size: 24pt;
            }
            #footer {
                padding-top: 3em;
                font-family: Arial,sans-serif;
                font-size: 8pt;
            }
        </style>
    </head>
    <body>
        <p>Due to maintenance this website is temporarily not available.</p>
        <p>Please try again later.</p>
    </body>
</html>

The hidden file '.maintenance' should be created by a form in admin-mode. And maybe a warnig-message in the backend should be fine too.
I think it's better to store this file in the ./cmsimple folder, because the user is able to rename the userfiles folder or the folder structure.

The admin can still login with http://www.example.com?&login but it would be nice when the login form is displayed with the emergency template.

IMO this way it is "core-update-proof".

cmb · Post by **cmb** » Sat Dec 13, 2014 12:20 pm

Holger wrote:IMO this way it is "core-update-proof".

Practically, yes. (There are some rather theoretical issues, for instance, when index.php will be replaced by the update, or if some external file is being accessed directly, which includes other core files.) I'm not too happy with putting more logic to multiple index.php files, though, but it seems that is the best available solution. Nonetheless we might consider postponing this to XH 1.7.

A minor thing: why:

Code: Select all

$t = count($_SESSION['xh_password']);
    if ($t !== 1) {

Multiple passwords would refer to separate installations, so it seems to me this check could be omitted.

Holger wrote:The hidden file '.maintenance' should be created by a form in admin-mode. And maybe a warnig-message in the backend should be fine too.
I think it's better to store this file in the ./cmsimple folder, because the user is able to rename the userfiles folder or the folder structure.

Basically I agree, but if we create the file in cmsimple/ the folder has to be writable. Maybe it's better to put an empty file there (which has to be writable; a system check should be added), and check for filesize($filename) >= 0.

What about internationalization of maintenance.htm[1]? Do we need that?

[1] Regarding the file extension: it's probably best to stick with .htm for consistency. We may consider to change .htm to .html (or even .php or .phtml) throughout the core for XH 2.0.

svasti · Post by **svasti** » Tue Dec 16, 2014 6:34 pm

cmb wrote:Frank noted a problem with the detached login form in an email to me: looks really strange when you have a dark template.

The detached login form was simply horrible with some templates. If ever something like this is coming, one has to take care that it works on light as well as on dark templates. Maybe in some sort of lightbox style? Anyhow I don't see the point in it as the present solution works all right

cmb wrote:What about internationalization of maintenance.htm[1]? Do we need that?

Of course, if maintenance is coming.
Now, if there is maintenance, you may want to check if your system is working correctly, or? So the maintenance sign should only be visible to the visitor while at the same time the webmaster may want to see the working of the website.

cmb · Post by **cmb** » Tue Dec 16, 2014 7:12 pm

svasti wrote:The detached login form was simply horrible with some templates. If ever something like this is coming, one has to take care that it works on light as well as on dark templates. Maybe in some sort of lightbox style? Anyhow I don't see the point in it as the present solution works all right

Well, the idea was that the admin is able to log in from the maintenance form (at least that is possible with Holger's maintenance plugin). Presenting the login form inside the normal template does not work, if the template is broken due to ongoing maintenance. Using the built-in template for the login form would solve this issue. However, that would not help, if the core or a required plugin is unusable due to ongoing maintenance. If only the normal template is unusable, the admin would indeed be able to login, but he would not be able to work on the site (unless there would be a working admin template installed).

svasti wrote:
cmb wrote:What about internationalization of maintenance.htm[1]? Do we need that?
Of course, if maintenance is coming.

I agree, even though that makes the suggested maintenance solution more complex, and requires translators to translate maintenance.html.

svasti wrote:Now, if there is maintenance, you may want to check if your system is working correctly, or? So the maintenance sign should only be visible to the visitor while at the same time the webmaster may want to see the working of the website.

That is taken care of by Holger's suggestion above. My suggestion that the check for ($t != 1) could be omitted was simply nonsense. Actually, it is this check that dispatches the admin to admin mode, and visitors to the maintenance notice.

svasti · Post by **svasti** » Tue Dec 16, 2014 8:08 pm

cmb wrote:I agree, even though that makes the suggested maintenance solution more complex

I see, the maintenance shouldn't depend on XH's language files. Hm, one could simply put the word "maintenance" in many languages. If somebody doesn't like it, he can change the maintenance.html. As long as we keep it simple, I think that's acceptable.

cmb wrote:the idea was that the admin is able to log in from the maintenance form

What about a lightbox style form?

Holger · Post by **Holger** » Wed Dec 17, 2014 1:06 pm

svasti wrote:The detached login form was simply horrible with some templates.

svasti wrote:What about a lightbox style form?

Seems there is some misunderstanding. I meant a login-screen complete detached from the template so it could never look horrible.
It's the common way for backend-logins in other systems, see Contao for example: http://demo.contao.org/contao/
The "in-template" login is in other systems in most cases used for frontend-users. But that was not my main point.

In the long run I have the feeling, that a "simple" task like a update-proof maintenance-mode is not easy to integrate in XH for some reasons.
So I would suggest to postpone this request for now and look for another way to integrate such things.

But IMO the core is not flexible enough to code such things with a plugin.
One possibility seems to put only something like the userfuncs.php to index.php and /2lang/index.php:

Code: Select all

<?php
if (is_readable('./some_new_folder/some_new_filename.php')) 
{
   include('./some_new_folder/some_new_filename.php');
}
include('./cmsimple/cms.php');

?>

New file / folder are created by the user and not part of the default installation. So they get not overwritten on updates.

cmb · Post by **cmb** » Wed Dec 17, 2014 2:18 pm

Holger wrote:In the long run I have the feeling, that a "simple" task like a update-proof maintenance-mode is not easy to integrate in XH for some reasons.
So I would suggest to postpone this request for now and look for another way to integrate such things.

I tend to agree.

Holger wrote:But IMO the core is not flexible enough to code such things with a plugin.
One possibility seems to put only something like the userfuncs.php to index.php and /2lang/index.php:
[ code ]
New file / folder are created by the user and not part of the default installation. So they get not overwritten on updates.

I'm not sure if that really would be helpful. For one thing, it is not necessarily clear, if there should be a common some_new_filename.php for all languages or separate files for each language. The former would simplify things, but it would make it harder wrt. internationalization. For another thing, depending on the storage place of some_new_filename.php, the file(s) could not be uploaded from the backend. If the user has to use FTP anyway, they could (temporarily) replace index.php (or maybe cmsimple/cms.php) with something else.

svasti · Post by **svasti** » Wed Dec 17, 2014 4:12 pm

Holger wrote:Seems there is some misunderstanding. I meant a login-screen complete detached from the template so it could never look horrible.
It's the common way for backend-logins in other systems, see Contao for example

I don't think there is a misunderstanding. There was some testing of a XH login form independent of the template. However — as far as I remember — it looked strange, when the template was dark, to have suddenly a fully white screen with a small login form in the middle. I'd propose for the detached login form that either the template remains in the background with a dark overlay and the login form will be in the foreground, or alternatively that the surrounding area of the login form be middle gray.

I have see the login form in word press (detached, all white), because one client proudly

showed me his new site he has together with his colleages

(They are editing with 4 people, so they didn't consider XH) Luckily he still kept his XH site.

cmb · Post by **cmb** » Wed Dec 17, 2014 5:31 pm

svasti wrote:I have see the login form in word press (detached, all white)

It seems noteworthy to mention that not only the login form is detached in Wordpress (and most, if not all, other CMS), but the complete administration is detached from the frontend template. IOW, frontend and backend have completely different look and feel.

CMSimple_XH–Forum

ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5

Re: ADD Maintenance to CMSimple_XH 1.6.5