is not used any more and exists only for history. Post new tickets on the Github account. n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 14 years ago

Closed 11 years ago

Last modified 10 years ago

#161 closed new feature (fixed)

Possibility to put an application offline

Reported by: laurentj Owned by: laurentj
Priority: normal Milestone: Jelix 1.2 beta
Component: jelix:core Version: 1.0 beta2
Severity: minor Keywords: update offline
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description (last modified by laurentj)

Jelix should contains a way to put offline temporarily an application (for maintenance for instance).

An example of implementation : Jelix could check the existance of a OFFLINE file in var/config. If this file exists, it displays an html page (the name of this html file could be set in a config parameter) insead of executing an action. Of course, some specific http headers should be sent (HTTP/1.1 503 Service Unavailable).

This system should be used by the update/install system.

Change History (21)

comment:1 Changed 14 years ago by laurentj

  • Description modified (diff)

comment:2 Changed 14 years ago by bballizlife

This concept is quite simple to use by developers as it allows to simply upload a file via FTP, but what about the performances of checking the existence of such a file at every request ?

Couldn't we add an option in the application configuration that would be less hangry and still easy to use ? For example : applicationOffline = true

comment:3 Changed 14 years ago by laurentj

why not. There is an other case of use : we can imagine a CMS backend where the user can put its application (frontoffice) offline. In this case, it is easier to create or delete a file than modifying an ini file.

But you're right : performance are bad when testing a file..

comment:4 Changed 14 years ago by laurentj

  • Milestone changed from Jelix 1.0beta3 to Jelix 1.0

comment:5 Changed 14 years ago by laurentj

  • Milestone changed from Jelix 1.0 to Jelix 1.1

comment:6 Changed 14 years ago by laurentj

  • Priority changed from high to normal

comment:7 Changed 13 years ago by laurentj

  • Blocking 31 removed

comment:8 Changed 13 years ago by laurentj

  • Blocking 31 added

comment:9 Changed 13 years ago by laurentj

  • Blocking 31 removed

comment:10 Changed 13 years ago by laurentj

  • Blocking 31 added

comment:11 Changed 13 years ago by laurentj

  • Documentation needed unset
  • Milestone changed from Jelix 1.1 beta 1 to Jelix 1.0beta2

comment:12 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0beta2 to Jelix 1.1 beta 2

comment:13 Changed 13 years ago by bballizlife

I realize that in production mode, we do not force compilation and checkCacheFiletime is set to off. So configuration files are not compiled again, except if we clear the cache of the application.

This means that updating the configuration file to set, for example, applicationOffline = true would not work, unless we clear the cache. But as being in maintenance mode often means updating the application, this may not be a real problem.

I carry on thinking at a nice way to implement such a feature...

comment:14 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.1 beta 2 to Jelix 1.2

comment:15 Changed 12 years ago by laurentj

  • Blocking 31 removed

comment:16 Changed 11 years ago by foxmask

in HaveFnuBB i manage this kind of behavior.

I check if the forum is installed with a coordinator plugin.

If the install is not done then i redirect the user to the install page, if yes nothing happens.

This is exactly the same behavior here.

We could use $gJConfig->applicationOffline in the offlineApp.coord.php to check if we have to redirect the user to a "maintenance page" or not.

Wht do you think of that ?

comment:17 Changed 11 years ago by laurentj

Using a coord plugin is not possible, because it supposed that the configuration has been read. But the configuration reader need the installer.ini.php file, which doesn't exists when the application is not installed...

And in most of case, we don't want to redirect to the install script, first, because this script could not be present after the installation, and second, because we don't want that someone else launch the installation before us. (even he couldn't do many things...)

The best solution I found, is a check on a file, var/config/CLOSED for instance. If it exists, jelix should display an html page we can configure (myapp/install/closed.html, or lib/jelix/installer/closed.html by default).

Now, where to check this file ?

  • Not in the constructor of the coordinator, because we couldn't disable this check (a user could have its own way to close his website, by setting the documentRoot to another directory for example, so it is useless to check the CLOSED file at each request)
  • Not in the application.init.php, because this file is loaded... by the installer.

So the best file is the entry point it self. We could provide a function checkApp() for instance, and then just add this call before the instanciation of the coordinator. This function check the CLOSED file, and if present, set the http header with an error (500 or an other code), display the closed.html and exit.

User who don't want never this check for any reason, could remove this call from their entry points.

The only issue I see, is that for existing projects with jelix 1.1, user should add this call in their exiting entry points.

Note that CLOSED could contain a message that checkApp could include dynamically in the html of closed.html

What do you think about this solution ? And do you have a better name for checkApp ?

comment:18 Changed 11 years ago by laurentj

  • Resolution set to fixed
  • Status changed from new to closed

finally fixed.

There are two new function, checkAppOpened to call in entrypoints, and checkAppNotInstalled in wizard installer scripts.

comment:19 Changed 11 years ago by laurentj

  • Documentation needed set

comment:21 Changed 10 years ago by laurentj

Thank you foxmask.

However, I think the page to install application is a better place to write this documentation. I added some details too

I certainly move it in a future new page about how to update an application, when the documentation of the installation system will be written.

Note: See TracTickets for help on using tickets.