Bueno este texto es explicativo del esquema.png que te envio: Empecemos por el principio... estrutura "fisica" de directorios de la aplicacion. Hay dos tipos: Desarrollo y Normal. El modelo Desarrollo seria del tipo de estructura que tu tienes en el ordenador en la que la Base tiene varias versiones de codigo en directorios diferentes y el acceso a los datos se hace por medio de enlaces simbolicos. p.e. helvete.utilitas.org en el esquema. El modelo Normal seria el que antes teniamos, el que normalmente la gente utiliza para consulta/edicion y NO para desarrollar nuevo codigo fuente. p.e. urreta.utilitas.org en el esquema. Salvando esas pequeas diferencias el resto de la estructura es IGUAL. Como puedes ver en el esquema... (esto de Dia es un vicio...) al final para el codigo conseguimos que la estructura sea equivalente y ni se entere. En cuanto a las diferencias con el esquema que tenemos ahora: - aparece un directorio "utilitas-users", la idea seria que para acceder al contenido de ese directorio tuvieses que identificarte (utilizando .htaccess y demas del apache) y dentro del directorio se encontraria el codigo que permite la edicion de datos. Pero no me termina de encajar todo. Porque si lo planteo como en el dibujo (sacando el directorio fuera de la version especifica) tengo un unico .htaccess que voy modificando con todas las versiones, pero el CODIGO esta FUERA de la version lo cual es ... ilogico. ideas?? - Aparece un "utilitas-public" que seria el directorio en el que estan TODOS los modulos de informacion, cada uno con su directorio. p.e. "i18n" contendria los actuales "languages.xml" "countries.xml" y "cities.xml" Que prentendo con estas divisiones, pues preparar el camino para los "admins". Que todos los usuarios puedan ver y meter datos en todos los modulos publicos es LOGICO (al fin y al cabo es colaboracion altruista), pero cada modulo debe tener al menos un administrador (posiblemente el que lo creo en un primer momento) o mas si es necesario. El administrador del modulo i18n puede modificar (por medio de formularios) datos internos de los archivox XML, en cuanto a sus caraceristicas, estructura, nombres, crear mas celdas, crear mas archivox XML, referenciarlos, decidir su forma de representacion, aadir mas administradores a SU modulo, etc.... Pero ese adminitrador puede no ser el adminitrador de "architecture". Por eso dentro de cada modulo tendra que haber un directorio "utilitas-admin" con los archivos .htacces incluyendo SOLO a aquellos usuarios que sea administradores de este modulo en concreto. Como te puedes imaginar aqui tengo el mismo problema. Lo ideal seria encerrar el codigo para hacer estas ediciones "especiales" en estos directorios, pero entonces estarian fuera del propio directorio de de "utilitas-0.7" y ademas habria que copiarlo tantas veces como modulos hubiese.....otra cosa TOTALMENTE ILOGICA. Lo logico es que todo el codigo estuviese en utilitas-X.XX: index.php (navegar por los datos) user.php (editar datos y guardar en el archivo XML) admin.php (editar estructuras internas de cada modulo) [sigo mas abajo sobre este tema...] Estos modulos publicos se pueden "rsync"-ear para que el original (y el unico sitio donde uno puede modificarlo) este SOLO en un servidor y el resto mantenga una copia solo para navegacion y para poder referenciarlos con modulos propios. - y por ultimo aparece el "utilitas-private" que es igual al public con par de diferencias: a) Son privados, por lo que para navegar por ellos es necesario ser un usuario valido (no vale con ser un usuario normal de utilitas). Por lo que cada modulo tiene su propio .htaccess y por anadidura su propio directorio /adimin/ con el .htaccess de aquel admin que lo creo. b) Pueden utilizar referencias hacia los modulos "publicos", pero no pueden ser referenciados (porque NO se puede conocer su contenido). Ni siquiera entre diferentes modulos privados. SOLO entre archvivos XML de un mismo modulo. c) No se pueden rsyncear... son privados. Su uso seria para cosas particulares, como mantener un listado privado de pelis Divx, o mantener al dia los datos de los servidores de ecolnet y solo los interesados tienen derecho a ver y editar, por ejemplo en este esquema meteria la pagina del "pack" que somos la cuadrilla de la uni, que cada vez nosvemos menos y aqui podremos (desde cualquier parte del mundo) mantener al dia nuestros datos y buscar los datos de algun compaero al que necesitemos contactar. ..... Bueno sigamos con el tema ILOGICO... Lo logico es que todo el codigo estuviese en utilitas-X.XX: index.php (navegar por los datos) user.php (editar datos y guardar en el archivo XML) admin.php (editar estructuras internas de cada modulo) Con lo cual lo que habria es que redireccionar desde cada directorio: utilitas-users/index.php utilitas-private/divx/index.php utilitas-private/ecolnet/index.php a ---> user.php (para edicion de contenido) y tambien: utilitas-public/i18n/admin/index.php utilitas-public/architecture/admin/index.php utilitas-private/ecolnet/admin/index.php utilitas-private/pack/admin/index.php a ---> admin.php (para edicion de estructuras) Pero el problema que le veo es que uno que sepa con en vez de ir a la pagina principal index.php puede escribir user.php y en teoria ya podria acceder ... no se. Escribiendote me acabo de dar cuenta de que el directorio "utilitas-users" no tiene sentido. Si no va a contener codigo y solo el .htaccess de los usuarios publicos, bastaria con poner el .htacccess en "utilitas-public". La unica "solucion" que se me ocurre seria seguir con el sistema de identificacion que tenemos ahora (que tambien es el de apache), que lo que hace es por software pedir que metas tus datos, lo que tengo miedo es meter la gamba en el codigo que por "magia" consiga pasar sin permiso, por eso quiero hacer algo mas limpio y poner la rsponsabilidad de validacion exclusivamente en Apache. Con lo que acabamos volvemos al principio: utilitas/ index.php (codigo de navegacion) users/ .htaccess index.php (codigo de edicion de contenido) admins/ .htaccess index.php (codigo ed. estruct.) Pero aqui los .htaccess estan dentro de la version de utilitas, con lo cual para cambiar de version hay que tener mucho cuidado (y es un rollo). Ademas no podrias definir adminitradores por cada modulo... ni usuarios especiales para los modulos privados.