some define variable are not propagate

some variable are not user-configurables

well, you modify scripts.conf.php or you create a copy of it and indicates it in the JELIX_CONFIG environnement variable.

some variables modified at system level (i.e. jelix lib) are not listen by jelix itself (e.g: DO_CHMOD and all))

This defines are intended to be used by jelix-scripts, not by jelix itself.

So it seems impossible to change the unix mode fore apache générated file

this is a system issue, not a jelix issue

the temp/JELIX_APP_PATH should be (by defauld) part of the user app itself (e.g. "JELIX_APP_PATH/var/temp" or "JELIX_APP_PATH/var/tmp)"

No, it shouldn't. When a developer want a copy of his app to install it on a production server, the content of the temp directory should not be copied. If this temp directory is inside the app directory, it is not easy to copy the app directory. So no, by default, the temp directory will not inside the app directory. If the developer want it, he will modify scripts.conf.php etc.

Also, the "temp" directory should be create when it is needed

And if the temp/ directory is a directory where apache has no rights ? Sorry but this is not acceptable.

 >> Also, the "temp" directory should be create when it is needed
 > And if the temp/ directory is a directory where apache has no rights ? 
 > Sorry but this is not acceptable.

Ok, but then, why not make default temp dir as '/tmp/" and then jelix could create it's one cache files in it's own single subdirectory (e.g. /tmp/jelix_temp/)

For know, jelix generated cached name are two generic (e.g. "compiled" wich is not acceptable on a commun directory like "/tmp"

Application should have their OWN temp directory. So a directory should be created inside /tmp (or in an other directory, depending what you want) for each application. This is what the createapp command do. It creates the directory indicated in JELIXS_APPTPL_TEMP_PATH. The value of this define is different for each application.

| Application should have their OWN temp directory

I agree! I just said that the default root directory for Jelix could be something like:

/tmp/jelix_temp/appli1/...
/tmp/jelix_temp/appli2/...

Which should work out of the box (yes: obsédé!) on any unix server while being costomisable by the user. Also , using such a default root directory "/tmp" allow jelix to create its global "/tmp/jelix_temp" temp dir if needed.

Which should work out of the box

If you want that it works out of the box, don't specify a directory like tmp/, because it can requires rights. the default settings are enough, or modify the scripts.conf.php as you want.

In the default settings, this is the temp/ directory provided in the archive, not the /tmp, just because on some system, there isn't /tmp directory.

| In the default settings, this is the temp/ directory provided in the archive,
| not the /tmp, just because on some system, there isn't /tmp directory.

(I've never seen an unix system (osx include) without a "/tmp" directory !)

But ok, so I suggest two solutions:

• either you create a meaningfull subdirectory name under "temp/" like "temp/jelix_$appname" which contains the "compile" sub directory and other files, and you should only delete this subdirectory,
• either you create the $temp directory if it doesn't already exists (so that one can choose something like "/tmp/jelix-$appname" and you can delete it if needed. It's the user responsabity to choose a tmp base directory with the apache writable access.

If the above solutions a rejected, another solution could be using two jelix variables :

• a TMP_BASE_DIR for a standard temporary base directory, which can be set to "/tmp" by the user. this directory should exist and being writable by apache (and never deleted
• a TMP_APP_NAME which is specific to the application ($appname as currently is not suffisant) : as some conflict are still possible on the same server. Probably TMP_APP_NAME could be based on a part of the url of the application (hostname, baseurl?)

Perhaps this discussion should have been submit on the forun, or a minimalist annonce on the forum could point to this ticket? So that we can see different points of vue (Anyway, you'll decide in fine, but with more opinions ;-)

I've never seen an unix system (osx include) without a "/tmp" directory !

Do you know an operating system named Windows and installed on more 90% of desktop computer in the world ? :-p

For the rest of your comment : I don't understand what do you want to fix. What's the problem at present time in jelix about the temp directory ?

If you want to create a temp/jelix_$appname , ok, do it ! Modify your scripts.conf.php and that's all ! But I don't see why your proposition should be in the original scripts.conf.php. Really, I don't understand. Could you explain the issue here ?

| Do you know an operating system named Windows and installed on more 90%
| of desktop computer in the world ? :-p

ok, I understand why jelix (and jelix.php..) is not perfect ;-)

We are talking about server, which are sometimes used by several people at the same time (;-) not desktop computer.
Also I'm not sure that 90% of the web servers run under windows
And for web server under windows how many of them use php instead of asp or java?
Someone said to me that even windows have "/tmp" directory (alias to temp ?)
Etc... But this is not my problem.

My problem is that I would want to use jelix on an unix web server which is shared among several hundred users (yes, more than 400) , each with its one public_html directory. Each user could potentialy create some file in /tmp/ directory on the server (via the php as "apache" user), and only delete the file he created.
Also each user has very limited access to the server itself. And it can not modify the server httpd.conf, but any user can modify it's .htaccess in a reasonable way.

The previous server, while very useful (and very used!), is not considered as critical in the professional sens.

Another but "critical " server with less than 10 users has more or less the same constraints even if I can ponctually (ask for) modification of the httpd.conf. Even on this server, I'd like to use /tmp/ directory if jelix can create the directory name I specify.

That unix "/tmp/" directory exists precisely for that purpose: create temporary by any application.
Jelix currently allows specify the "/tmp" directory for the "temp" but create in it some files or directories like "compile" which is not acceptable

What I want is to specify for the temp dir something like:

"/tmp/jelix_mySuperAppli_id51544354365436/"

and I want jelix being able to create this temp dir if it doen't exists (and delete it needed)

There are other solutions (see previous messages) but this one seems the simplest way for jelix. It consists of be able to create the missing "temp" directory.
Some time ago, I saw another discussion were a user (probably a pour unix user) asked for creating the the missing "temp" dir. But he doesn't seem to have succeded...

P.S. Could please change the original subject of this ticket from:
"some define variable are not propagate"
to something like:
"managing temp directory"

which reflet more the problem (the first subject was more about one hacking possible solution)

I really think you should build *your* custom scripts.conf.php for your big installation for 400 users.

Also don't forget that before being on a server (mainly unix/linux, ok) developpers really often work on windows plateform, so the temp directory can't be set to /tmp (as it does not exist there).

Last, i really don't want to see jelix to check every action if the application temp directory exists or not (and create it if needed). This is the little thing that, step after step, leads a project to be less performant (adding 1 more disk access when you have a huge traffic is really important).

In fact here, i really don't see where is the problem with Jelix.

I understand why jelix (and jelix.php..) is not perfect

no comment...

We are talking about server, which are sometimes used by several people at the same time (;-) not desktop computer.

You forgot that developers, even on big developers teams, work often on their own desktop computer, with their own web server.

Jelix currently allows specify the "/tmp" directory for the "temp" but create in it some files or directories like "compile" which is not acceptable

THIS IS FALSE IF YOU CORRECTLY CHANGE VALUES IN scripts.conf.php or IF YOU CORRECTLY CHANGE YOUR application.init.php.

La procédure pour que jelix fonctionne bien avec un répertoire est le suivant :

• tu indique le repertoire temp de l'application dans application.init.php au niveau de la constante JELIX_APP_TEMP_PATH (tu peux mettre /tmp, /tmp/mon/super/repertoire/temp/de/la/mort, /etc/n/importe/ou CE QUE TU VEUX)
• tu met les droits qu'il faut pour apache sur ce répertoire

et c'est tout.

Si tu utilises la commande createapp et que tu veux éviter d'avoir à modifier à chaque fois le application.init.php, tu modifie le scripts.conf.php pour qu'il soit en adéquation à ta conf.

Bref, ça a toujours bien fonctionné, je n'ai jamais eu de souci, ni les autres users. Si il y a un bug, lors de createapp ou du fonctionnement de jelix, alors explique le cas où ça ne fonctionne pas, le contenu de application.init.php et/ou de scripts.conf.php, quel est le résultat. Bref donne des détails.

Par détails, je parle aussi de la procédure exacte de création de ce répertoire temp et de l'application.

Each user could potentialy create some file in /tmp/ directory on the server (via the php as "apache" user), and only delete the file he created

Et ? Si c'est eux qui créer des applis jelix, je ne vois pas comment jelix pourrait les obliger à mettre les fichiers dans /tmp/machin/bidule plutôt que /tmp. Si ils changent le application.init.php de leur application fraichement créée, c'est leur problème. Et jelix n'y peut absolument rien.

D'ailleurs, pourquoi ne pourraient-ils pas utiliser un temp qui est dans leur public_html ? Après tout, c'est ce qui se passe si ils installent jelix dans leur repertoire sans toucher au scripts.conf.php.

Also each user has very limited access to the server itself. And it can not modify the server httpd.conf, but any user can modify it's .htaccess in a reasonable way.

C'est quoi le rapport avec le repertoire temp d'une appli jelix ?

Si tu installe jelix pour le mettre à disposition de tout le monde, change le scripts.conf.php pour que le répertoire temp crée pour une appli soit dans le répertoire que tu veux. Je doute que le code php de ce fichier soit super compliqué à modifier

   define ('JELIXS_APPTPL_TEMP_PATH'   , "/tmp/jelix_$APPNAME_$ID/");

$ID étant ton "id51544354365436" mais je ne sais pas à quoi correspond ce truc. Bref, tu fais en sorte que dans cette variable il y a ce qu'il faut.

This is the little thing that, step after step, leads a project to be less performant (adding 1 more disk access when you have a huge traffic is really important).

Moi je suis pour que jelix reste simple et performants en charge comme actuellement ...

Si c'est pour avoir un Frameworks à tweaker de partout et ... ( bon je vais pas cité de noms Z... , S... C... ) Merci bien.

Jelix ma reconcilier avec les frameworks, j'aimerais bien qu'ils reste sur ça " lancer " on va dire ;-) et ne pas integrer tout plein de truc, juste pour simplifier un peu une ligne de code, le default de la plupart des frameworks actuel, pourtant bien au debut.

Ceci n'engage que moi pas la peine de faire de débats la dessus ...

Merçi.

Autre chose Maurice, que tu ne te méprennes pas : il n'y a aucun problème à faire ce qu'il faut pour que Jelix fonctionne en hébergement mutualisé et autre (dans la mesure où ça ne sacrifie en rien les perfs et la philosphie du framework). Mais pour le moment, tu n'es absolument pas clair sur ce que tu veux faire : pas de description détaillé de ton installation, de la façon dont tu as installé jelix, de la façon dont les utilisateurs vont utiliser jelix, ce qu'ils vont faire avec etc.. Si tu expliquais les choses, on comprendrait peut-être un peu mieux. Au début, on croit que tu parles sur ton desktop, ensuite tu nous parles d'un serveur (cf ta discussion sur le forum), maintenant dans un de tes commentaires tu nous parle de 400 utilisateurs qui font on ne sait pas encore trop quoi. Et peut être que demain tu vas nous parler d'une ferme d'une centaine de serveurs mutualisé.

Bref, si tu veux qu'on résolve ton problème, expliques en détails ce que tu veux faire, le contexte.

Je précise que j'ai pas envie d'utiliser une usine à gaz, et que c'est pour cette raison que je me tourne vers jelix, dont j'aime le codage (sauf le choix du format ".ini" qui ne devrait etre créé que dans le cache ;-)

Effectivement je connais très peu jelix, et c'est peut-être cela que je mets du temps à trouver la solution jelix à mes probleme.

... your big installation for 400 users ...

There are not my users!! I'm just one of these.
(If I were the admin of this server, there were no problem!)

Last, i really don't want to see jelix to check every action if the application

temp directory exists or not (and create it if needed).
This is the little thing that, step after step, leads a project to be less performant
(adding 1 more disk access when you have a huge traffic is really important).

That could be a strong argument, ... but it doesn't seem to apply in this case because the temp file is never tested for itself only its content files already are (the cache files).
and it is created only once for a given application (as the same tile the "compile" subdirectory is

Nevertheless, I understand that you don't want to modify (add one level to) the content of the temp dir.
...more later

sauf le choix du format ".ini" qui ne devrait etre créé que dans le cache ;-)

La lecture d'un fichier ini est plus rapide qu'un fichier PHP ou autre. Et c'est trés simple à écrire ou à générer (par des outils tiers, ide ou autre). C'est pourquoi j'ai choisi ce format, d'autant qu'il est suffisant au niveau de la structure.

There are not my users!! I'm just one of these. (If I were the admin of this server, there were no problem!)

Ok. But I don't see problem if you are a simple user... I'm waiting for your next explanations...

@bballizlife & webseb : in fact, I see that the temp directory is checked at each request. But I can improve this behavior and check it only during the creation of the cache of the ini file.

	Bref, si tu veux qu'on résolve ton problème, expliques en détails ce 
	que tu veux faire, le contexte.

Bon d'accord, en relisant le tout, je m'aperçois que j'ai créé beaucoup
de malentendus, et que je n'ai pas été très clair . Alors je vais remettre
les choses à plat, dans le bon ordre (j'espère) et exprimer ma démarche 
et mes contraintes décrivant mon problème de fond.

Ma démarche et le choix de jelix
================================

- je ne suis pas webmaster professionnelle, mais j'ai eu quelques petits sites 
  à faire ou à maintenir (php, sqlite, css, le tout séparé comme je pouvais)

- je n'ai jamais utilisé de framework, mais j'ai par ailleurs une culture objet 
  qui me rend plutot réceptif à ce genre d'outils et tolérant par rapport à leur
  coté carcan (dans une certaine limite que le ne connais pas encore ;-)

- je me suis orienté plutôt vers jelix parce que :

  - prérequis pour php5.2 : je me suis dit qu'au moins, jelix n'est pas rempli de 
    verrues pour pouvoir tourner sur php3, php4, php4etdemi (j'aime bien).... or 
    j'en ai bavé avec du php4 (tres déçu apres avoir avaler par erreur un bouquin 
    de php5 ... non disponible sur le server que j'allais devoir utiliser alors 
    (il y a deux ans) )

  - jelix m'a paru relativement sobre (Moins de 10 Moctets tout en offrant des 
    possibilités puissantes), et le code semble bien organisé et très lisible,

  - un peu jeune, donc peu connu, mais pas de mauvais boulet à trainer et peut donc 
    partir sur des bases techniques saines (tout en ayant fait ses preuves sur de gros 
    sites !)

  - la doc qui était légère mais qui s'améliore à vue d'oeil
    (cf. mon premier post sur le forum "documentation imprimable" : merci Laurent !)

  - je n'ai cependant regardé que trés superficiellement d'autres framework que 
    j'ai éjecter pour des raisons complémentaires à celles précitées (usine à gaz...)

  - cependant, j'ai passé plus de temps que prévus sur des choses du style 
    "déployement en milieu hostile", et le temps presse... mais je ne pense pas 
    passer à un autre framework : au pire des cas j'intègre jelix et je le modifie 
    pour pouvoir résoudre mes problemes (d'où l'importance de l'organisation du code)

Mes environnements de travail :
===============================

Typiquement j'ai l'habitude de travailler en local sur un compte unix (appelons 
le ~maurice) et plus précisément dans un sous-répertoire de public_html
par exemple ~/public_html/work/essaisjelix/
Le répertoire essaisjelix pourrait contenir :
   lib_jelix_11_snap/
   lib_jelix_104/
   appli1/
   appli2/
   temp/

Je peux alors tester mes appli en local par une url du type :
    http://localhost/~maurice/public_html/work/essaisjelix/appli1/www/
(j'espère pouvoir virer le www final par un .htaccess judicieux dans appli1,
mais je n'en suis pas là.)

Le déployement
==============

Comme je l'ai (très mal !) exprimé dans un autre message, voici le principal
serveur auquel j'ai accès

Un serveur de page perso, ***que je ne maitrise pas*** (contrairement à 
une interprétation possible de  mon message précédent), héberge 
environ 400 pages personnelles (d'où le qualificatif de "non critique"
car pas d'info sensibles).
Ma page web n'est une de ces 400 pages et je ne peux pas me loguer dessus 
pour faire mes bidouilles.

Pour la à laquelle,  je transfert mon compte local vers une machine 
distante, auquel un serveur apache a accàs.

Ce compte conserve le même propriétaire que l'original, mais le serveur web 
est l'utilisateur "apache". Par conséquent il y a conflit si apache veut
créer des fichiers cache dans mon répertoire.

Tout cela montre les raisons de mon intérêt pour une 
    "APPLICATION WEB RELOGEABLE AVEC BASE DE DONNEES"
qui, une fois faite, impliquerait que j'ai résolu tous ces problèmes,
y compris :
- le tiquet demande de pouvoir spécifier un fichier sqlite3 en relatif !
- le tiquet  faire du "application.init.php" le premier fichier sourcé par les 
  points d'entrées (ce qui permettrait de ***centraliser** le choix du
  fichier init.php à sourcer (donc la version de jelix)
  (on pourrait imaginer que le choix du jelix soit calculé en détectant le 
  serveur...)

J'ai d'abord vu deux solutions
==============================

1 - soit m'arranger pour créer un répertoire "temp_xxxx" bien planqué dans mon
public_html avec des droits du style "777" et m'arranger pour que tout fichier 
créé par apache soit également en 777 de façon à ce que ces fichiers apaches puisse 
être effacés par ma prochaine copie "local vers server".
Ceci nécessite la modif du core de jelix pour l'instant 
pour permettre le gestion par apache (et plus seulement par jelix.php) 
des variables DO_CHMOD (objectif initial de ce ticket)
C'est pas vraiment pas terrible mais ça marche. MAUVAISE SOLUTION

2 - Utiliser le répertoire standard unix "/tmp/" qui est local au serveur
Cependant, comme on est nombreux (400) à pouvoir l'utiliser je ne peux pas
définir simplement /tmp/ (qui existe déjà)) comme fichier "temp" de jelix, 
mais je voulais créer un sous-répertoire prpre à mon appli, en ajoutant 
même clé arbitraire ainsi que je mot "jelix" (voir "$user") pour supprimer 
tout embiguité (ce qui donne /tmp/jelix-$myapp-4325435645/)

Problème : 
  je n'ai pas accès au serveur apache, d'où l'idée de demander que jelix 
  crée le répertoire temp si nécessaire (comme il crée l'arborescence 
  "compile" d'ailleurs : pas de sur-coût ni de verrue nécessaire pour cela)
  C'est aussi pour cela que le "jelix.php createapp" ne m'est pas utile 

Et voici probablement la solution évidente
==========================================

Il suffit que le mkdir en question soit créé par le server apache, donc ce n'est 
par forcément par jelix mais tout simplement dans application.init.php
puisque c'est quasiment le premier fichier exécuté.
...Non testé cependant...

Vous pouvez facilement imaginer que même moi j'aurais pris moins de temps de 
faire les quelques modif directement dans jelix (soit un mkdir quelque part 
soit quelques changement de modes) que simplement d'écrire ses derniers mail... 
sauf que ça devient la galère pour les mises à jour de jelix.

Ce que je cherche plutôt, c'est 
	"THE JELIX WAY"
pour résoudre mes problèmes !

P.S 2  
  Ce système devrait aussi marcher en mutualisé chez OVH (plan90)
  (création d'un répertoire sous /tmp/xxxx,)

P.S 2
  Je ne sais pas pour free

P.S 3
  Je n'arrive pas à nettoyer mon message "humoristique" (pas éditable pour moi)
  Tu peux virez ce que tu veux

P.S 4
  si apache pouvait prendre l'identité du propiétaire d'un répertoire
  avant d"écrire dedans, ça aurait simplifié le problème... 

Voila, dodo maintenant !  

Bon effectivement, je pouvais faire cette modif sur le server par l'intermédiaire dans mon "application.init.php"

L'extrait suivant permet la création du répertoire temporaire, que ce soit en local sur mon mac, ou sur le serveur partagé (par beaucoup).

Un problème que j'ai rencontré était du à la différence de comportement de la commande realpath(...) utilisée à l'origine pour construire JELIX_APP_TEMP_PATH.
En effet macosx et un unix bsd alors que le serveur distant est sous linux. (ben oui, je sais c'est donc la doc php, mais j'ai du jouer avec des die() pour le trouver ;-)

Quoi qu'il en soit, dans notre cas (on n'a pas besoin de calculer un répertoire parent et donc la commande realpath(...) ne se justifie pas.
De plus, on peut toujours appelé realpath(...) après avoir créé récursivement le répertoire.

L'inconvénient de cette méthode, est qu'un appel système est effectué à chaque appel d'url alors que ce test pourrait problement se faire une seule fois lors de la création d'un fichier cache (mais pas sûr de cela)

// require_once ('../lib/jelix/init.php'); // pour l'instant : fait dan les points d'entrée

define ('JELIX_APP_PATH', dirname (__FILE__).DIRECTORY_SEPARATOR); // don't change

// ATTENTION à realpath(...), 
// Si le fichier n'existe pas, le comportement est  différent entre BSD et LINUX :
// - LINUX return false (donc une chaine vide) alors que 
// - BSD fonctionne si le parent du fichier existe existe
// Conclusion : inutile d'utiliser realpath dans ce cas !
// 
// define ('JELIX_APP_TEMP_PATH',    realpath(JELIX_APP_PATH.'./var/temp/').DIRECTORY_SEPARATOR);
// define ('JELIX_APP_TEMP_PATH',    realpath('/tmp/dupond/jelix/actu.org').DIRECTORY_SEPARATOR);
// 
// De plus, pour un tutorial exécutable clé en main, il faudrait détecté windows
// et  utiliser autre chose de "/tmp/" (e.g.  \WINDOWS\temp\ ?)
// 
// Evidement dans un environnement productif la variable JELIX_APP_TEMP_PATH peut
// être définie une fois pour toute
// 


define ('JELIX_APP_TEMP_PATH',  '/tmp/dupond/jelix/actu.org'.DIRECTORY_SEPARATOR);


if (!is_dir(JELIX_APP_TEMP_PATH)) {
    mkdir(JELIX_APP_TEMP_PATH, 0700, true);
}

Pour la relogeabilité du tutorial, il me reste à trouver une bidouille pour redéfinir en php le chemin d'acces à la base sqlite3 codé en absolu dans dbprofils.ini.php. Je vais mettre cela de coté pour l'instant (sauf si quelqu'un à une astuce)

Voila, désolé pour tout ce dérangement, mais ce problème est maintenant résolu au niveau de mon application, sans avoir à modifier jelix.

Voila, ça va un peu mieux que ce matin ;-)