Distribución de una pequeña aplicación PHP

Question

Escribí una pequeña aplicación PHP que me gustaría distribuir. Estoy buscando las mejores prácticas para que pueda instalarse en la mayoría de los webhosts con una mínima molestia.

En pocas palabras: es una herramienta sencilla que permite a las personas descargar archivos una vez que inician sesión con una contraseña.

Así que mis preguntas son:

1) ¿Cómo debo manejar los valores de configuración? No estoy usando una base de datos, por lo que un archivo de configuración parece apropiado. Sé que otras aplicaciones de php (por ejemplo, Wordpress) usan define, pero son globales y existe la posibilidad de que los nombres entren en conflicto. (Las variables globales también tienen el mismo problema, obviamente.) Miré el mecanismo de archivo "ini" integrado en PHP. Solo permite comentarios en la parte superior, por lo que no puede anotar cada configuración fácilmente, y no puede validar la sintaxis con "php -f". ¿Otras opciones?

2) ¿Cómo manejar las plantillas? La aplicación necesita bombear un formulario. Posiblemente con un mensaje de error. (por ejemplo, "Perdón, contraseña incorrecta"). Tengo una variable de clase con el formulario HTML, pero también permite que se use un archivo de plantilla externo (especificado en la configuración). Hago búsquedas y reemplazos triviales, por ej. % SCRIPT% al nombre del script,% ESTADO% para mantener el mensaje de error. Esto se siente un poco como reinventar la rueda, pero incluir un sistema de plantillas como Smarty es excesivo. (Además, es posible que ya tengan un sistema de plantillas). ¿Otras opciones?

3) i18n: solo hay 3 cadenas de mensajes, y gettext no parece estar instalado universalmente. ¿Es tan mala idea hacer estos tres parámetros de cadenas en el archivo de configuración?

4) ¿Cómo se integra mejor con otros marcos? Mi aplicación es una sola clase. Entonces, pensé que podría simplemente incluir un script php que mostrara cómo se llamaba a la clase. Sería un punto de partida para las personas que tenían que integrarlo en otro marco, pero también estarían bien para quienes no estén interesados ​​en personalizarlo. ¿Razonable?

5) Parámetros GET/POST - ¿Está mal que una clase mire $ _GET y $ _POST? ¿Deberían pasar todos los valores a mi clase durante la construcción?

Gracias.

Answer 1

configuración

Puede utilizar un archivo php como esta:

<?php 
return array(
    'option1' =&gt; 'foobar', 
    'option2' =&gt; 123, 
    //and so on... 
); 
?> 

Y en la clase principal sólo tiene que utilizar:

$config = (array) include 'path/to/config/file'; 

Y si va a distribuir su mayoría su clase como un componente en otras aplicaciones, luego simplemente ponga config array/object como un parámetro en el constructor de su clase y deje los detalles al usuario.

Templating

Para tal aplicación sencilla el método descrito su debería ser suficiente. Recuerde que siempre puede extender su clase y sobrecargar su método de salida con el suyo.

I10N

Como se mencionó antes, durante 3 variables de algo más de almacenarlas como config es sólo una exageración.

Integración

comentario a cada método público (o incluso mejor protegido y también las privadas) con explicaciones qué hacen y qué parámetros son necesarios. Si combina eso con un ejemplo, debería ser suficiente para la mayoría de los usuarios.

GET vs POSTAL

su clase utiliza contraseñas e incluso pensar en enviarlos por GET? ;) Piensa en el historial del navegador, los encabezados de referencia, etc. - las contraseñas de tus usuarios serían visibles allí.

Answer 2

1. ¿Puede la configuración ser local para instancias de clase? ¿O podrías crear una pequeña clase en la que puedas crear una instancia para consultar valores de configuración? También anteponiendo cualquier vars global con el nombre de tu aplicación debería ayudar a detener los enfrentamientos.

2. Si su creación de plantillas es realmente simple, simplemente escriba una plantilla corta. Será más fácil que tratar de defenderse de los problemas que la gente tiene con cualquier tercero. También podría simplificar los problemas de licencia. Si comienzas a preocuparte por lo que ya tienen, nunca lanzarás nada. Hay demasiadas combinaciones.

3. ¿Para 3 cuerdas? Sí, hazlos de la misma manera que estás manejando la configuración.

4. Buenos comentarios en todo con una introducción que explica cómo usar la clase.

5. Yo no lo creo. Si te molesta, puede utilizar los argumentos por defecto a utilizar argumentos dados en primer lugar, a continuación, busque los valores GET/POST si se proporcionan ninguna (aunque eso podría ser un riesgo para la seguridad)

hay otras cosas a tener en consideración.Muchas personas están en hosts compartidos y, como resultado, no tienen control sobre su php.ini o su versión de php. Debe asegurarse de estar utilizando solo las funciones que son lo más comunes posible.

Un ejemplo es que shorttags no están habilitadas en algunos hosts (usted tiene que utilizar <?php ... ?> y <?php echo "..."?> en lugar de <? ... ?> o <?= "..." ?>) que puede ser un PITA real.

Answer 3

Además de un buen consejo de Krzysztof:

• Uso <?php única
• Si utiliza las funciones que se pueden desactivar, utilice function_exists() para asegurar que estén disponibles. @missing_function() hace que PHP muera silenciosamente sin ningún error registrado.
• No puede confiar en las cosas que se pueden desactivar/cambiar a través del php.ini. Use ini_get() para adaptarse a diferentes configuraciones.
• Si magic_quotes están habilitados, la tira solo se recorta desde su copia de entrada - ¡no modifique las matrices globales! La seguridad de algún código cojo puede depender de que estas barras estén presentes.
• Espere que los usuarios copiarán sin pensar & pegar código de su documentación/sitio web.