1) Nuevas guías: instalación en Apache y Nginx (en inglés)

Publicamos instrucciones claras para servir aplicaciones KumbiaPHP detrás de Apache (VirtualHosts) y Nginx (server blocks), destacando los puntos clave: usar public/ como document root y habilitar las reglas de reescritura para el front controller. Estas guías facilitan el despliegue en entornos modernos sin dependencias innecesarias. GitHub

Qué encontrarás:

• Estructura mínima y document root correcto (public/).
• Directrices de reescritura para URLs limpias (pretty URLs).
• Notas rápidas para PHP-FPM (Nginx) y módulos en Apache.

2) “Primera App” — más clara y didáctica

La guía Primera App fue reescrita con foco en personas que inician con MVC:

a. Se aclaró la arquitectura MVC y el manejo de URLs, explicando cómo el front controller enruta /controlador/acción/param hacia tu lógica.
b. Se actualizaron los ejemplos de controladores y vistas, con código más legible y ordenado.

c. Se mejoraron los títulos y subtítulos para escanear mejor el contenido.
d. Se reemplazaron capturas de pantalla, haciendo más evidente cada paso (crear controlador, renderizar vista, pasar variables).

3) Instalación con Composer (nuevo apartado)

Ahora el manual incluye un flujo directo para iniciar proyectos con Composer:

Requisitos mínimos: PHP 8.x recomendado.
Pasos típicos:

1) Crear un nuevo proyecto base de KumbiaPHP
composer create-project kumbia/framework myapp
2) Entrar al proyecto
cd myapp/default/app
3) Iniciar servidor de desarrollo de PHP apuntando a public/
./bin/phpserver

El paquete framework es el esqueleto básico para comenzar: genera la estructura y te deja listo para desarrollar. Si eres nuevo en Composer, la sección Instalación con Composer te guiarán sobre cómo funciona composer.json y los comandos principales.

4) Controladores: contenido revisado + nuevas imágenes

La sección de Controladores se reordenó para mejorar la lectura y cubrir escenarios reales:

• Validación de parámetros: número de parámetros, pasar valores a la vista, convenciones de nombrado, acciones y filtros.
• Controladores dinámicos: cuándo conviene y cómo mantenerlos legibles.

Enlaces rápidos

• Manual (repo): documentación central y carpetas es/ y en/. (GitHub)
• Paquete framework en Packagist: referencias y enlaces al manual. (Packagist)

Gracias a la comunidad

Estas mejoras nacen de pull requests recientes y la colaboración constante de la comunidad. Si quieres proponer cambios, abre un PR en el repo del manual o únete al Slack para coordinar traducciones/imágenes adicionales. ¡Seguimos puliendo el contenido para que empezar con KumbiaPHP 1.2 (PHP 8) sea cada vez más fácil!

La entrada Novedades del Manual de KumbiaPHP — noviembre 2025 se publicó primero en KumbiaPHP Framework PHP en español.

En este artículo, exploraremos una forma más limpia y eficiente de gestionar la renderización condicional en KumbiaPHP con return 1;. También profundizaremos en por qué este enfoque es preferible sobre el uso estándar de return; o estructuras if-else anidadas.

El Enfoque Tradicional: Uso de if-else

Considera un escenario donde quieres mostrar un mensaje si no hay datos para mostrar y renderizar el resto de la vista solo cuando los datos están disponibles. Un enfoque típico podría verse así:

<?php if (!$products): ?>
    <h2>No hay productos disponibles</h2>
<?php else: ?>
    <h1>Lista de Productos</h1>
    <ul>
        <?php foreach ($products as $product): ?>
            <li>
                <h3><?= $product->nombre ?></h3>
                <img src="<?= $product->imagen_url ?>" alt="<?= $product->nombre ?>" />
                <p><strong>Categoría:</strong> <?= $product->categoria ?></p>
                <p><strong>Descripción:</strong> <?= $product->descripcion ?></p>
                <p><strong>Precio:</strong> $<?= number_format($product->precio, 2) ?></p>
                <p><strong>Stock:</strong> <?= $product->stock ?> unidades disponibles</p>
                <p><strong>SKU:</strong> <?= $product->sku ?></p>
                <a href="/productos/<?= $product->id ?>" class="btn">Ver Detalles</a>
            </li>
        <?php endforeach ?>
    </ul>
<?php endif; ?>

Aunque esto funciona, envolver todo el código de la vista dentro de un bloque else añade una indentación y complejidad innecesarias, especialmente en vistas más grandes.

Renderización condicional en KumbiaPHP con return 1; Una Solución Más Limpia:

Para mejorar la legibilidad y mantener el código más limpio, podemos utilizar return 1; para salir de la vista de manera anticipada si no hay datos. Aquí está cómo se vería el código:

<?php if (!$products) {
    echo "<h2>No hay productos disponibles</h2>";
    //View::partial('sin-datos'); // o enviamos un partial
    return 1;
}?>

<h1>Lista de Productos</h1>
<ul>
    <?php foreach ($products as $product): ?>
        <li>
            <h3><?= $product->nombre ?></h3>
            <img src="<?= $product->imagen_url ?>" alt="<?= $product->nombre ?>" />
            <p><strong>Categoría:</strong> <?= $product->categoria ?></p>
            <p><strong>Descripción:</strong> <?= $product->descripcion ?></p>
            <p><strong>Precio:</strong> $<?= number_format($product->precio, 2) ?></p>
            <p><strong>Stock:</strong> <?= $product->stock ?> unidades disponibles</p>
            <p><strong>SKU:</strong> <?= $product->sku ?></p>
            <p><strong>Fecha de Lanzamiento:</strong> <?= date('d/m/Y', strtotime($product->fecha_lanzamiento)) ?></p>
            <p><strong>Calificación:</strong> <?= $product->calificacion ?> estrellas</p>
            <a href="/productos/<?= $product->id ?>" class="btn">Ver Detalles</a>
        </li>
    <?php endforeach ?>
</ul>

En este ejemplo:

• Si $products está vacío o es false, se muestra el mensaje «No hay productos disponibles» y la ejecución de la vista se detiene gracias a return 1;.
• Si $products tiene datos, el código continúa ejecutándose y se muestra la lista detallada de productos sin necesidad de un bloque else.
• El código es más limpio y fácil de leer al eliminar la indentación adicional.

Aplicación en Templates y Partials

La misma técnica puede aplicarse en templates y partials. Esto es útil cuando necesitas condicionar la inclusión de ciertas secciones o elementos de la interfaz de usuario.

Ejemplo en un Partial

En un partial que muestra comentarios de un artículo:

<?php
if (!$comments) {
    echo "<p>No hay comentarios aún. ¡Sé el primero en comentar!</p>";
    return 1;
}?>

<div class="comments">
    <h3><?= count($comments) ?> Comentarios</h3>
    <?php foreach ($comments as $comment): ?>
        <div class="comment">
            <p><strong><?= $comment->autor ?></strong> dice:</p>
            <p><?= $comment->contenido ?></p>
            <p><em>Publicado el <?= date('d/m/Y H:i', strtotime($comment->fecha_publicacion)) ?></em></p>
        </div>
    <?php endforeach ?>
</div>

Entendiendo View::render() y include

En KumbiaPHP, las vistas se renderizan usando el método View::render(), que internamente incluye el archivo de vista:

// Carga la vista
if (!include self::getView()) {
    throw new KumbiaException('Vista "' . self::getPath() . '" no encontrada', 'no_view');
}

La sentencia include en PHP devuelve false si falla al cargar el archivo (debido a que el archivo no existe, falta de permisos, etc.). Si el archivo incluido ejecuta un return; sin un valor, devuelve null, lo que la validación del include se interpreta como false. Esto lleva a que View::render() crea que el archivo de vista no pudo ser incluido y lanza una excepción.

La Importancia de return 1;

Al usar return 1;, la vista devuelve 1, lo que include interpreta como una inclusión exitosa. Esto permite que el proceso de renderización continúe sin problemas sin desencadenar una excepción.

Beneficios de Usar return 1;

• Código Más Limpio: Al eliminar bloques else innecesarios, el código es más sencillo y legible.
• Facilidad de Mantenimiento: Menos indentaciones y anidaciones facilitan la comprensión y modificación del código en el futuro.
• Consistencia: Puedes aplicar esta técnica en vistas, templates y partials de manera uniforme.
• Mayor Claridad: Separar la lógica de control del contenido principal mejora la claridad y organización del código.

Conclusión

Usar return 1; en las vistas de KumbiaPHP es una forma simple pero efectiva de gestionar la renderización condicional sin complicar tu código con estructuras if-else innecesarias. Asegura que tus vistas se ejecuten sin problemas y que el proceso de renderización continúe sin excepciones.

Al adoptar este enfoque, puedes escribir vistas más limpias y mantenibles en tus aplicaciones KumbiaPHP. Pruébalo en tu próximo proyecto y experimenta la diferencia que hace en tu base de código.

¡Feliz codificación con KumbiaPHP!

La entrada Optimizando la Renderización Condicional en Vistas de KumbiaPHP con return 1; se publicó primero en KumbiaPHP Framework PHP en español.

DDL y modelo para la tabla

Veamos la estructura de la tabla user que hemos visto en ejemplos anteriores:

CREATE TABLE `user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(255) NOT NULL,
 `age` int(11) NOT NULL DEFAULT '0',
 `email` varchar(255) NOT NULL, 
 PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

Y el modelo para este caso lo haremos heredar de la clase ActiveRecord y lo ubicamos en default/app/models/user.php

<?php

class User extends ActiveRecord
{
    
}

Implementación de la autocarga de objeto

KumbiaPHP implementa la Autocarga de objeto la cual, siguiendo una convención mínima modelo.campo donde para el ejemplo el modelo es user, es decir existe una tabla llamada user en la base de datos y campo serán cada una de las columnas de esa tabla (id, name, age, email).

En concordancia con las columnas de la tabla user se indica el comportamiento de la Autocarga de objeto para que el controller no tenga que recoger uno a uno los valores enviado por POST.

Para este caso usaremos el helper Form:

Archivo: default/app/views/user/create.phtml

<?php View::content() ?>

<?= Form::open() ?>
<?= Form::text('user.name') ?> 
<?= Form::email('user.email') ?>
<?= Form::number('user.age') ?>
<?= Form::submit('Guardar') ?>
<?= Form::close() ?>

Automáticamente cuando esos valores vayan a la url /user/create KumbiaPHP interpreta que existe una tabla user con los campos name, email y age.

Aplicando autocarga en el controlador

Ahora vemos el código que se utiliza en controllers/user_controller.php en su acción create().

Archivo: default/app/controllers/user_controller.php

<?php 
/**
 * Controlador para las acciones y vistas con el usuario 
 */ 
class UserController extends AppController
{ 

    public function index()
    {
        // Se debe implementar la función de listar
    }

    public function create()
    {
        //se verifica si se ha enviado via POST los datos
        if ( ! Input::hasPost('user')) {
            return;
        }
            
        //Intenta guardar el usuario
        if ((new User)->create(Input::post('user'))) {
            //Mensaje de éxito 
            Flash::valid('Usuario creado');
            //Elimina los datos del POST, muestra limpio el formulario
            Input::delete();
            return;
        }
        //Mensaje de fallo 
        Flash::error('Falló al intentar crear el usuario');
    }
}

Si probamos el formulario y por alguna razón falla al guardar, automáticamente mostrará el formulario con los datos que se intentaron guardar, sin que debamos estar verificando si hay datos en el POST y si los hubiera indicarle al input el value, ya que el helper Form lo hace por nosotros.

Con esto se ahorra mucho trabajo y le sacamos el máximo provecho a KumbiaPHP Framework.

Acceder a un campo del formulario enviado mediante POST

A veces nos consultan como se accede a un campo específico del formulario que viene en el POST en el controlador, y es muy sencillo veamos qué valor trae Input::post(‘user’):

array(3) {
  ['name']=>
  string(8) "John Doe"
  ['email']=>
  string(12) "jd@email.com"
  ['age]=>
  int(30)
}

Como pueden ver al hacer un var_dump() de la variable nos muestra que es un simple arreglo por lo tanto la manera de acceder es la siguiente:

$name = Input::post('user.name');
// or
$name = Input::post('user')['name'];

Son casos especiales y lo mejor es que aprovechen al máximo la autocarga.

Error común de novatos

Es común ver en quienes inician con KumbiaPHP cometer varios errores y uno de ellos es crear el objeto o registro campo por campo. Lo vemos mejor en el siguiente código de la función create() del controlador UserController:

public function create()
{
    //se verifica si se ha enviado via POST los datos
    if (Input::hasPost('user')) {
        $data = Input::post('user');
        //Código incorrecto: Obtener del POST el valor de
        //cada input y asignarlo uno a uno al objeto.
        $user = new User();
        $user->name = $data['name'];
        $user->email = $data['email'];
        $user->age = $data['age'];
        //Intenta guardar el usuario
        if ($user->create()) {
            //Mensaje de éxito
            Flash::valid('Usuario creado');
            //Elimina los datos del POST, muestra limpio el formulario
            Input::delete();
            return;
        }
        //Mensaje de fallo
        Flash::error('Falló al intentar crear el usuario');
    }
}

Funciona si, pero como pueden notar, se agregaron para este caso cinco líneas de código innecesarias. Ahora imaginen que no son tres campos en el formulario, si no que son diez, veinte o más campos por formulario. Ahora multipliquemos eso por el número de formularios de toda la aplicación.

El código creado sería muy extenso y se convierte en difícil de leer y mantener.

Espero que les sea de utilidad este artículo.

PD: Agradecimientos a Deivinson Tejeda por el borrador de este artículo.

La entrada Formularios a base de datos fácilmente con 1 línea de código se publicó primero en KumbiaPHP Framework PHP en español.

Va especialmente dedicado a nuestros colegas que alguna vez han llegado al chat grupal con la frase:

Es que no funciona en producción

La primera pregunta que debemos resolver es:

¿Por qué no funciona?

A continuación presentamos una lista de los temas más comunes que deberíamos tener en cuenta para resolver la pregunta que impulsa este artículo.

1. ¿El servidor apache está ejecutándose?
2. ¿El mod rewrite está activo?
3. ¿El mod rewrite está configurado para nuestra ruta en el servidor?
4. ¿PHP está instalado y configurado?
5. ¿El servidor de bases de datos está activo?
6. ¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?
7. ¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?
8. ¿Nuestra aplicación tiene los permisos bien configurados?
9. ¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos .htaccess)?
10. ¿Hemos configurado correctamente la constante PUBLIC_PATH?
11. ¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?
12. Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?
13. El sitio presenta un error ERR_TOO_MANY_REDIRECTS al cargarlo.

NOTA: Si es la primera vez que haces un paso a producción (deployment) a un servidor dedicado o en un hosting compartido, te recomendamos leer los siguientes artículos que hemos alojado en nuestra wiki.

• Pasar a producción: http://wiki.kumbiaphp.com/Pasar_a_produccion
• Kumbia en servidor con CPanel: http://wiki.kumbiaphp.com/KumbiaPHP_en_servidor_con_CPanel

Continuemos entonces con el checklist:

¿El servidor Apache está ejecutándose?

Nuestra primera tarea será revisar que el servicio de Apache se encuentre activo y en el puerto necesario. Asumiendo que la tarea de despliegue (deployment) se realiza en un servidor linux, podemos revisar si el servicio está activo y si acaso el puerto está escuchando.

Revisemos el servicio web con los siguientes comandos:

ps -fea | grep -i http
ps -fea | grep -i apache

Si encontramos resultados, es decir, al menos 2 líneas se visualizan como salida a nuestro comando*, es que el servicio está activo.

*el comando ps es “process status” o estado del proceso. Las opciones -fea son para indicar que nos liste los procesos de nuestro usuario como del resto, así como algo de información relacionada con el proceso. Para realizar el filtro entre todos los procesos hemos usado un pipe | o tubería para enviar el resultado del comando ps al comando grep que buscará en la lista si acaso existe algo que contenga el texto “http”, o algo que contenga “apache”. Se usa con -i para que no discrimine entre mayúsculas y minúsculas o alguna combinación de ellas. Para más ayuda sobre estos comando les recomendamos usar el comando man ps o también pueden usar man grep.

NOTA: si usan el comando man (manual) para ps o para grep lo más seguro es que se encuentren con el editor vi. Para salir de él bastará con presionar Esc (escape), luego : (dos puntos) y luego q (la letra q para quit).

Revisemos ahora que el servicio está activo y escuchando peticiones.

Para eso nos bastará en primera instancia abrir un navegador y apuntarlo a la dirección de nuestro servidor. Si tenemos respuesta de la página de bienvenida del servicio (apache) ya tendremos este tema resuelto.

Ahora, si tenemos acceso por consola, podemos probar usando el comando

netstat -av | grep http

En mi caso, uso apache y su nombre de servicio es http. En otros Sistemas Operativos o paquetes de software que incluyen Apache, el servicio web puede encontrarse como apache o apache2.

¿El mod rewrite está activado?

Esta pregunta no es difícil de responder si usamos un pequeño archivo PHP al que llamaremos info.php. En él escribiremos <?php phpinfo(); ?> y luego lo abriremos desde el navegador (normalmente http://localhost/info.php)

Así aprovecharemos para revisar que PHP está activo y en la versión del mismo.

Una vez cargue la página de información de php buscaremos (en general con Ctrl + F o Cmd + F) la palabra rewrite. Deberíamos encontrarla en la sección apache2handlers, en la fila Loaded Modules.

Como se aprecia en la imagen anterior también está activo mod_php7 :-)

En caso que no lo encontremos, o que el archivo info.php no nos dé información, bastará con hacer la activación desde la consola (en el caso de tener servidor con shell activa). Vamos a asumir que usamos un servidor con un sistema operativo derivado de debian (ubuntu o similar). Entonces escribiremos en la consola como root

a2enmod rewrite

Y luego reiniciamos el servicio de apache (también como root)

service apache2 restart

Con esto ya deberíamos tener activado el módulo de sobrescritura de url.

¿El mod rewrite está configurado para nuestra ruta en el servidor?

Bueno, no basta con activar el mod rewrite, hay que configurarlo también.

Nota del autor: esto es lo que normalmente hago en mi configuración de apache. 
No sé si es lo más recomendado. Los comentarios son bienvenidos :)

Para realizar este cambio iremos al archivo de configuración de apache (generalmente alojado en /etc/apache2/apache2.conf)

Lo editaremos y buscaremos una sección llamada Directory.

Buscaremos aquella cuya línea sea Directory /var/www y cambiaremos la opción AllowOverride None por AllowOverride All. Guardaremos la configuración y procederemos a reiniciar el servicio apache.

En las imágenes siguientes se ve el antes y el después de la configuración.

Con estos pasos el mod rewrite estará activo y configurado.

¿PHP está instalado y configurado?

Si hemos llevado a cabo los pasos anteriores para saber si el mod rewrite estaba activo, y lo hemos encontrado en el archivo info.php, entonces es que tenemos PHP bien instalado.

En caso que no hayamos logrado entonces deberemos instalar el módulo PHP en nuestro servidor.

Para hacer esta tarea usaremos nuevamente la consola (shell) para hacer la instalación.

La instalación varía un poco entre distribuciones de servidor, pero haremos la instalación pensando en algún derivado de debian (como si fuéramos root)

apt-get install libapache2-mod-php php

Una vez que la instalación haya finalizado necesitaremos reiniciar el servicio web (como root)

service apache2 restart

Si tenemos aún el archivo info.php, pues lo abriremos desde el navegador (normalmente http://localhost/info.php)

Si logramos ver el resultado de nuestro archivo, entonces ya tendremos claro que PHP está activo en nuestro servidor.

¿El servidor de bases de datos está activo?

Si usamos MySQL o MariaDB bastará con intentar hacer login con la cuenta que tenemos en la configuración de nuestra aplicación desde la consola.

mysql nombredelabasededatos -u miusuario -p

Digitamos la contraseña y presionamos enter para lograr acceso.

Si nos da un error como el que se ve en la imagen siguiente es porque el servicio no está activo.

Para activarlo deberemos ejecutar un comando como el que sigue desde la consola (como si fuéramos root):

service mysqld start

Si ahora logramos acceso y todo va bien, es decir, logramos conectarnos al servidor mysql, sería bueno saber si tenemos acceso a la base de datos que usará la aplicación.

Para eso, estando en la consola interactiva de mysql, escribimos el comando use mibasededatos; (donde mibasededatos es el nombre de la base de datos que está configurado en el archivo database.ini) seguido de punto y coma. Y presionamos enter.

Nos debe aparecer un mensaje como “database changed”.

Seleccionamos alguna de las tablas del sistema (podemos listarlas usando el comando show tables;), y escribimos alguna instrucción y le ejecutamos, por ejemplo;

<span class="token keyword">SELECT</span> <span class="token operator">*</span> <span class="token keyword">FROM</span> tablaseleccionada<span class="token punctuation">;</span>

Si todo ha ido bien, ya podemos pasar al siguiente punto.

¿La cuenta en el servidor de bases de datos es la que corresponde en la configuración de nuestra aplicación?

Bueno, en el punto anterior ya hemos realizado esta prueba usando el comando:

mysql nombrebasedatos -u usuario -p

Si esto no resulta, será necesario crear un usuario de mysql con los permisos necesarios sobre la base de datos correcta. Para eso te recomendamos leer el siguiente artículo que ya explica muy bien cómo lograr esta labor.

https://www.digitalocean.com/community/tutorials/crear-un-nuevo-usuario-y-otorgarle-permisos-en-mysql-es

¿Hemos trasladado todos los cambios desde el servidor de bases de datos de desarrollo hacia el servidor de producción?

A veces el error se produce porque tenemos tablas en el servidor de desarrollo que no hemos pasado al servidor de producción o porque alguna de las tablas de producción no tiene atributos (campos) nuevos que sí hemos estado usando en desarrollo. Hacer una revisión de las estructuras de las tablas será de gran ayuda si comparas cómo es el estado en ambos servidores.

¿Nuestra aplicación tiene los permisos bien configurados?

Si hemos leído los artículos de la wiki, y hemos comprobado que los permisos son los correctos, sólo nos quedará pasar al siguiente punto.

¿Hemos copiado completamente la aplicación desde el servidor de desarrollo (incluidos todos los archivos ocultos)?

Por obvia que parezca la pregunta, resulta que en ocasiones el cliente que usamos para copiar los archivos, omite los archivos ocultos que comienzan en punto (los dot files). En KumbiaPHP se usan varios archivos que comienzan en punto, y aunque todos se llaman igual, cada uno cumple una misión diferente dependiendo del lugar en el que esté alojado. Este archivo es el .htaccess.

Personalmente la forma que más me resulta para lidiar con este problema es comprimir el sitio, copiarlo comprimido al servidor de producción y luego descomprimirlo en él. Si esto no fuera posible (porque por ejemplo no tienes acceso a la shell o si el panel web de administración no provee de gestión de archivos), toma en cuenta que el cliente de ftp que uses lleve todo lo que necesitas al servidor de producción.

¿Hemos configurado correctamente la constante PUBLIC_PATH?

Aunque también es parte de lo que se habla en los artículos escritos y mencionados de la wiki, uno de nuestros colegas ha escrito un artículo interesante sobre este tema y el siguiente en el blog de KumbiaPHP https://www.kumbiaphp.com/blog/2018/07/31/no-input-file-specified-arreglar-el-error/

¿Podemos usar PATH_INFO o necesitamos cambiar la estrategia de generación de URL?

Al igual que el punto anterior, nuestra recomendación es leer el artículo que ya se mencionó en él.

Si estamos completamente a ciegas, ¿hemos activado la visualización de errores?

Si el servidor no nos da información alguna sobre el error, podemos aprovechar una configuración especial que está alojada dentro del archivo default/public/index.php para activar el registro de los errores y permitir visualizarlos directamente en el navegador web.

Para eso iremos archivo mencionado (default/public/index.php) y buscaremos la línea:

//error_reporting(E_ALL ^ E_STRICT);ini_set('display_errors', 'On');

Y le quitaremos los comentarios iniciales, es decir, los dos primeros caracteres iniciales //

Adicionalmente debemos asegurarnos que KumbiaPHP no esté en modo producción, así que en el mismo archivo default/public/index.php verificamos que la constante PRODUCTION sea igual a false:

const PRODUCTION = false;

Esto hará que las excepciones que ocurran sean mostradas en pantalla evitando la redirección a la página de error 404, que es comportamiento por defecto de KumbiaPHP cuando está en producción.

Con eso ya tendremos alguna idea a partir de la presentación de los errores en pantalla.

Existe una forma extra de visualizar errores, pero para ello hay que tener acceso al servidor en modo consola (shell) y tener acceso al log de errores del servidor web (apache generalmente). Normalmente este archivo se aloja en /var/log/apache2/error.log

Si se tiene acceso a él, usar el comando tail -f error.log será de gran utilidad pues cada vez que recargues tu navegador, los errores se verán reflejados en tu terminal. Los mensajes que recibas serán de gran utilidad al momento de buscar posibles soluciones, o para pedir apoyo a algún colega.

El sitio presenta un error ERR_TOO_MANY_REDIRECTS al cargarlo

Si a pesar de haber eliminado los archivos de la caché este error persiste es momento de revisar nuestra rutina de autenticación. En ocasiones la implementación de la gestión de la sesión del usuario nos puede causar algunos dolores de cabeza, y el consejo aquí es verificar la forma en la cual se lleva a cabo las redirecciones cuando un usuario no tiene los privilegios necesarios y requiere de autenticación. Hay diferentes formas de llevar a cabo la autenticación, pero siempre vale la pena consultar alguna forma que ya haya sido probada. Para tales efectos les recomendamos leer http://wiki.kumbiaphp.com/Beta2_Sistema_de_Login o también https://soyprogramador.liz.mx/implementando-logueo-en-kumbiaphp/ como elementos formativos. Te dejamos como tarea extra mirar código de otras personas. Puedes hacer una búsqueda en github con la palabra clave kumbiaphp.

Una recomendación final

Si hemos pasado de PRODUCCION = true a false y viceversa, es necesario recordar eliminar el contenido de la carpeta de cache que genera KumbiaPHP cuando estamos en modo producción. Para ello iremos a la carpeta default/app/temp/cache y borraremos su contenido para evitar que no logremos visualizar los errores porque el framework está presentando los contenidos “cacheados” en vez de las vistas reales.

Con todo esto, te deseamos lo mejor y mucho ánimo cuando te encuentres con un problema, pues recuerda que resolverlos es parte de nuestro aprendizaje y nuestra labor como desarrolladores.

Un abrazo cordial,

El equipo de KumbiaPHP

La entrada Errores comunes al subir web o aplicación php a producción se publicó primero en KumbiaPHP Framework PHP en español.

Nueva meta u objetivo usando ScaffoldController

Este post tiene por objetivo hacer un resumen de lo que ya hemos visto en las entregas anteriores, y sacar aún más partido al uso de scaffolding con nuestro framework, de tal manera que puedas aplicar los conceptos que se describen en otras situaciones y así buscar mantener el principio DRY: No te repitas.

En sí, el uso de Scaffolding es una declaración clara del principio DRY, pues lo usamos para no tener que copiar y pegar comportamientos que son inherentes a diferentes situaciones: como crear, actualizar, eliminar y listar registros de una tabla (a modo de ejemplo, podríamos crear controladores scaffolding o heredables para otras tareas que no sean siempre la gestión de datos en tablas).

A modo de añadir más fuerza al principio, los frameworks de desarrollo web se han creado basándose primariamente en dicha idea: escribir lo necesario, evitando repetir comportamientos, y por ende se disminuye el número de líneas de código, el nivel de errores y, por ende, el tiempo de desarrollo y mantenimiento de los sistemas o aplicaciones creados con ellos.

Por eso es que existe una clasificación de carpetas: para controladores, modelos, vistas, ayudantes (helpers), librerías particulares, y librerías externas (vendors).

Si necesita comprender más los conceptos básicos de nuestro framework puede ver Kumbia Essentials.

Manos a la obra

Como ya se mencionó, un scaffolding es una estrategia para no repetir código que se usa en labores comunes. Hasta aquí lo hemos usado para tener un CRUD de la tabla que representa las categorías, y también nos ha permitido sobrescribir la forma en que hacemos la presentación de la acción index (listar los registros de la tabla).

Ahora iremos un poco más lejos

1. Modificaremos la vista particular de la acción index.
2. Sobrescribiremos nuestro controlador para modificar el comportamiento al guardar y actualizar los registros.

El cliente nos pide modificar la visualización de la lista de categorías para quitar de ella los atributos de fecha y renombrar el atributo nombre y categorías por Nombre Categoría y Categoría Padre. También nos solicita modificar el comportamiento de la acción crear para que el formulario aparezca limpio para agregar nuevamente, en vez de viajar a index una vez enviado el formulario.

De igual forma debe hacerse para que la acción editar recargue el formulario modificado en vez de viajar a index. Iremos de lo fácil a lo menos fácil.

Modificaremos el comportamiento de crear, y editar en nuestro controlador.

Podemos mirar el método crear desde ScaffoldController (app/libs/scaffold_controller.php) y mejorarlo para nuestro controlador de categorias (app/controllers/categorias_controller.php)

Una propuesta podría ser como la que se presenta a continuación:

public function crear()
{
    if ( Input::hasPost('Categorias') ) {
        $categoria = new Categorias(Input::post('Categorias'));
        
        //comprobar si se puede realizar la creacion del elemento
        if ( !$categoria->save() ) {
            Flash::error('Falló Operación');
            //hacer persistente el objeto con los datos enviados
            $this->Categorias = $categoria;
            Input::delete('Categorias');
        }
    }
    $this->Categorias = new Categorias;
}

Esta propuesta elimina la redirección a index, y limpiar el contenido de Input::post(‘modelo’) para que el formulario permanezca en blanco y así nos permita agregar un nuevo elemento de forma inmediata.

Repetiremos el procedimiento en el método editar. Iremos al controlador ScaffoldController, y desde él mejoraremos el método editar, pegándolo bajo el método crear del controlador de categorías. La propuesta para editar debería ser algo como la siguiente figura:

public function editar($id)
{
    View::select('crear'); //usamos la misma vista que crear

    if ( Input::hasPost('Categorias') ) {
        $categoria = new Categorias;          
        //comprobar si se puede realizar la actualización del elemento
        if ( !$categoria->update(Input::post('Categorias')) ) {
            Flash::error('Falló Operación');
            //hacer persistente el objeto con los datos del formulario
            $this->Categorias = $categoria;

            Input::delete('Categorias');
        }
    }
    //aplicar autocarga del objeto para comenzar/continuar la edición
    $this->Categorias = (new Categorias)->find((int)$id);
}

Modificando vistas

Modificaremos la vista index estándar. Para ello crearemos una nueva vista index dentro de app/views/categorias. El archivo debe ser llamado como index.phtml.

La estructura de archivos del proyecto debería verse así:

Copiaremos el contenido de la vista index del scaffolding, la que está en app/views/_shared/scaffolds/kumbia/index.phtml

Quitaremos los atributos de fecha y renombraremos las columnas de nombre y de categoría padre. La vista nos debería quedar más o menos así:

<div id="scaffold">
<?php View::content()?>
<h1><?= ucwords("$model"), ": <span>$action_name</span>" ?></h1>
<div class="actions">
    <?= Html::linkAction("crear/", 'Crear registro', 'class="btn btn-primary"')?>
</div>

<?php if (isset($data->items) && (count($data->items) > 0)) : ?>
<table class="t">
    <thead><tr>
    <th>Id</id>
    <th>Nombre</id>
    <th>Categoria Padre</id>
    <th>Acciones</th>
    </tr></thead>
    <tbody>
    <?php foreach ($data->items as $item) : ?>
        <tr>
            <td><?= h($item->id)?></td>
            <td><?= h($item->nombre)?></td>
            <td><?= h($item->categorias_id)?></td>
            <td><?= Html::linkAction("ver/$item->id", 'Ver')?> |
            <?= Html::linkAction("editar/$item->id", 'Editar')?> |
            <?= Html::linkAction("borrar/$item->id", 'Borrar', 'onclick="return confirm(\'¿Está seguro?\')"') ?>
            </td>
        </tr>
    <?php endforeach?>
    </tbody>
</table>

<?php View::partial('paginators/digg', false, array('page' => $data ,'url' => Router::get('controller_path').'/index')) ?>
<?php else : // Si no hay items?>
<h2>No hay ningún registro</h2>
<?php endif ?>
</div>

Al ejecutar el acceso a la vista deberíamos lograr algo similar a la siguiente figura:

Pero nuestro cliente necesita que la categoría padre quede expresada con el nombre, no con su código de referencia.

Entonces, lo que haremos finalmente es modificar el método index y el modelo que enlaza la tabla categorías de la siguiente forma, comenzando por el modelo (app/models/categorias.php):

<?php
class Categorias extends ActiveRecord
{      
    function getCategorias($page = 1)
    {
        return $this->paginate(
            'columns: categorias.id, categorias.nombre, cat.nombre as categorias_id',
            'join: left outer join categorias cat on categorias.categorias_id = cat.id',
            "page: $page", 'order: categorias.id desc');
    }
}

Modificamos la consulta para dotar a la paginación de la referencia al nombre de la categoría padre usando los parámetros columns y join.

En nuestro controlador de categorías modificaremos el método index para que pueda usar esta nueva paginación, quedando el resultado como se ve a continuación:

<?php
class CategoriasController extends ScaffoldController
{
    public $model = 'Categorias';
    public $scaffold = 'skeleton';   

    public function index($page=1)
    {
        $this->data = (new Categorias)->getCategorias($page);
    }

Finalmente el resultado de la vista index se verá como lo presenta la siguiente figura:

Hasta aquí llega la publicación dedicada al tema del scaffolding, pero antes de terminar haremos un resumen hasta aquí.

Resumen

En este episodio hemos modificado el comportamiento del método crear sobrescribiendo el método base del controlador Scaffold, también hemos modificado el comportamiento para editar, y para index.

Hemos agregado una vista personalizada para la acción index, y aún así seguimos usando ScaffoldController.

Sólo nos restará por tarea crear nuestro propio Scaffold para poder mantener el principio DRY usando los comportamientos sin redirección para el método crear y editar.

Si te perdiste los otros post de esta serie, puedes leerlos en los siguientes enlaces:

Scaffolding para CRUD (ABM) sencillos (y no tanto) – primera parteparte 1

ScaffoldController: Modificando comportamientos y contenidos

Un abrazo cordial a nuestros colegas y a los que han de venir,

@nelsonrojas

La entrada ScaffoldController: Modificando vistas se publicó primero en KumbiaPHP Framework PHP en español.

Para que se entusiasmen, dentro de las posibilidades  tenemos: reescribir métodos y modificar comportamientos en controladores, modificar los archivos de vista, e incluso puedes crear tus propios scaffoldings. Pero bueno, vamos paso a paso.

Manos a la obra con ScaffoldController

Vamos a trabajar en base a supuestos. Supongamos que queremos mostrar el nombre de la categoría padre para aquellas categorías que estén anidadas.

Como se ve en la lista, las categorías relacionadas sólo se ven con su identificador.
Por lo tanto, vamos a modificar la fuente de datos que pasamos a la vista Index para que ésta pueda presentar los contenidos respectivos.

En el modelo

Lo que vamos a hacer es crear un método que cumpla con lo que queremos lograr: mostrar el contenido de la tabla de categorías incluyendo el nombre de la categoría padre en aquellas categorías que heredan de otra. De este modo tendremos una modificación como la siguiente:

Archivo: models/categorias.php

<span class="token delimiter"><?php</span>

<span class="token keyword">class</span> <span class="token class-name">Categorias</span> <span class="token keyword">extends</span> <span class="token class-name">ActiveRecord</span> 
<span class="token punctuation">{</span>

    <span class="token keyword">function</span> <span class="token function">getCategorias</span><span class="token punctuation">(</span><span class="token variable">$page</span> <span class="token operator">=</span> <span class="token number">1</span><span class="token punctuation">)</span> 
    <span class="token punctuation">{</span>
        <span class="token keyword">return</span> <span class="token variable">$this</span><span class="token operator">-</span><span class="token operator">></span><span class="token function">paginate</span><span class="token punctuation">(</span>
            <span class="token string">'columns: categorias.id, categorias.nombre, cat.nombre as categorias_id, categorias.creada_at, categorias.actualizada_in'</span><span class="token punctuation">,</span> 
            <span class="token string">'join: left outer join categorias cat on categorias.categorias_id = cat.id'</span><span class="token punctuation">,</span>
            <span class="token string">"page: $page"</span><span class="token punctuation">,</span> <span class="token string">'order: categorias.id desc'</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>

<span class="token punctuation">}</span>

En el controlador

El segundo cambio lo haremos desde el controlador, para cargar los cambios que hemos hecho en el modelo. Lo que reemplazaremos (porque es una sobre escritura de index en ScaffoldController) será la función index tal como se muestra a continuación.

Archivo: controllers/categorias_controller.php

<span class="token delimiter"><?php</span>
<span class="token keyword">class</span> <span class="token class-name">CategoriasController</span> <span class="token keyword">extends</span> <span class="token class-name">ScaffoldController</span>
<span class="token punctuation">{</span>
    <span class="token keyword">public</span> <span class="token variable">$model</span> <span class="token operator">=</span> <span class="token string">'Categorias'</span><span class="token punctuation">;</span>

    <span class="token keyword">public</span> <span class="token keyword">function</span> <span class="token function">index</span><span class="token punctuation">(</span><span class="token variable">$page</span><span class="token operator">=</span><span class="token number">1</span><span class="token punctuation">)</span>
    <span class="token punctuation">{</span>
        <span class="token variable">$this</span><span class="token operator">-</span><span class="token operator">></span><span class="token property">data</span> <span class="token operator">=</span> <span class="token punctuation">(</span><span class="token keyword">new</span> <span class="token class-name">Categorias</span><span class="token punctuation">)</span><span class="token operator">-</span><span class="token operator">></span><span class="token function">getCategorias</span><span class="token punctuation">(</span><span class="token variable">$page</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
    <span class="token punctuation">}</span>
 
<span class="token punctuation">}</span>

Ahora se ve así

Con esto lograremos que el listado cumpla que el requerimiento solicitado.

¿Por qué funciona?

Como puede verse, con cambios mínimos hemos logrado adecuar la presentación de la vista index sin actualizar su archivo. Lo que hemos hecho principalmente es un reemplazo dentro de la metadata de ActiveRecord. Scaffolding espera contar con todos los atributos de la tabla de categorías (id, nombre, categorias_id, creada_at, actualizada_in). Nosotros hemos modificado la salida cambiando categorias_id por nombre desde categorias (nombre as categorias_id). Así hemos logrado que el pintador de la vista index haga su tarea sin enterarse del reemplazo que hemos hecho a nivel de modelo.

Bueno, eso es todo por esta semana. En la siguiente entrega veremos cómo modificar una vista particular para hacerla parecer según nuestros requerimientos. (ver parte 3)

Últimas recomendaciones

Recuerden que pueden revisar el código desde: https://github.com/nelsonrojas/Scaffold-KumbiaPHP

No olvides visitarnos en http://slack.kumbiaphp.com/ para contarnos cómo te va usando KumbiaPHP. Si necesitas apoyo procuraremos estar atentos. Además, si te gusta lo que escribimos compártelo ya mismo con tus amigos y colegas.

Saludos y larga vida a KumbiaPHP!

Con cariño desde Talca, Chile: @nelsonrojas

Ps: Si te perdiste lo que escribimos la semana pasada, puedes leerlo aquí: https://www.kumbiaphp.com/blog/2017/04/03/scaffolding-para-crud-abm-sencillos-y-no-tanto-primera-parte/

Si quieres ver lo que sigue: ScaffoldController: Modificando vistas

La entrada ScaffoldController: Modificando comportamientos y contenidos se publicó primero en KumbiaPHP Framework PHP en español.

A pesar de lo anterior, el texto está listo y ha quedado bastante jugoso, así que no los haré esperar más y los dejaré con el compendio de  preguntas resueltas:

¿Cómo hacer un confirm alert? Pregunta ycaicedo

Este ejemplo es con javascript usando el helper Html::link() o Html::linkAction() que permite mostrar primero un diálogo de confirmación al usuario, aunque es fácil de saltar, por ejemplo si el usuario desactiva javascript en el navegador:

<?= Html::linkAction("borrar/$item->id", 'Borrar', 'onclick="return confirm(\'¿Está seguro?\')"') ?>

¿KumbiaPHP soporta CamelCase en el nombre de tablas? Pregunta abriceno

Con el atributo $source de la clase ActiveRecord se le puede indicar a que tabla consultar, pero el desarrollador debe acordarse de hacer el cambio.Ejemplo:

<?php

class MateriaPrima extends ActiveRecord {

    //Tabla utilizada para realizar el mapeo
    protected $source = 'MateriaPrima';
}

¿Cómo le inserto una clase a un select generado con Form::dbSelect()? Pregunta jerson.fuentes

El helper Form::dbSelect() tiene los siguientes argumentos:

Form::dbSelect(campo_id, campoAMostrar,array(modelo,metodo),"Seleccione",atributos)

Ejemplo:

Form::dbSelect("lotes.lotes_categorias_id","nombrecategoria",null,"Seleccione",'class="form-control"');

Saben como después de actualizar un dato, redirigirme a la vista anterior

Para redireccionar en KumbiaPHP existe la clase Redirect

La redirección se puede hacer con Redirect::to() antecedido con un return para que sea lo último que ejecute.

Recomendaciones de joanhey

Mitos sobre el rendimiento de PHP

Busted! 10 Performance Myths you should avoid. Es una presentación muy recomendable de Thomas Lohner de SysEleven GmbH que en 2015 en una charla menciona los 10 mitos sobre mejorar el rendimiento que se deben evitar.

Lo más importante es usar bien las herramientas.

HTTPie un buen sustituto de Curl

HTTPie es una app que funciona en Linux, MacOs y Windows. Es muy útil como sustituto de Curl.

Nos permite fácilmente probar nuestros servidores, API RESTful y web services.

La entrada Preguntas resueltas en Slack 2 se publicó primero en KumbiaPHP Framework PHP en español.

Como algunos sabrán, va en aumento las personas que nos empiezan a contactar a través del chat de KumbiaPHP en Slack. Donde de manera voluntaria y altruista Kumbieros con más experiencia dedicando algo de su tiempo ayudan a novatos y no tan novatos a resolver sus dudas sobre el framework y otros menesteres propios del diseño e implementación de software. Si aun no has ingresado puedes pedir tu ingreso en esta dirección: http://slack.kumbiaphp.com/

Slack es muy bueno para dar soporte, pero con el transcurrir del tiempo los mensajes se van perdiendo y se escurre por el desagüe ese gran contenido que nos podría ayudar a todos. Por eso hemos decidido crear esta sección para mantener de manera permanente y pública esta valiosa información. Sin más introducción les dejo la siguiente colección de preguntas y respuestas:

¿Cómo hacer enlaces en KumbiaPHP que registre en donde estoy o mejor dicho el enlace activo?

Pregunta jerson.fuentes
Pregunta relacionada de josher1601

¿De alguna forma se puede obtener el controlador que estoy viendo y la acción?

En el controlador y la vista disponemos de variables para obtener está información:
$module_name;
$controller_name;
$action_name;

Ejemplo de uso en un controlador:

<?php
class AppController extends Controller
{
  final protected function initialize()
  {
    Flash::info("El módulo es $this->module_name"); //Si hay módulo retorna el nombre del módulo
    Flash::info("El controlador es $this->controller_name"); //Retorna el nombre del controlador
    Flash::info("La acción es $this->action_name");  //Retorna el nombre de la acción
  }

  final protected function finalize()
  {
  }
}

Ejemplo de uso en una vista:

Usted está en el controlador <?= $controller_name ?> y la acción <?= $action_name ?>


¿Para que funcione Flass::success() había que activar algo?

Pregunta marcelok. Pregunta relacionada de yecaicedo:

Acabé de realizar un CRUD sencillo pero cuando guarda no me muestra el Flash::valid()

Para mostrar los mensajes Flash y solo si hay redirección de URL (usando por ejemplo Redirect::to()) se debe poner antes de ninguna salida, la función session_start() con ponerlo en el controlador que lo necesita es suficiente.

¿Cuando realizo el save() hay algún método que retorne el last_insert_id? Pregunta xavi92

Si haces un save() el objeto ya tiene el valor en el campo id

Ejemplo:

<?php

//Si guarda correctamente
if($album->save()){
  $album->id; //Retorna el id con el cual ha sido guardado
}

¿En Skeleton puedo usar al 100% el ancho de la pantalla? Leí que el grid tiene un ancho de 960px Pregunta marcelok

Es igual para todos los frameworks css, los row siempre son fluidos, si no se usa container será del máximo siempre, si se usa container el máximo será 960 que se puede cambiar si se quiere. Hay que tener cuidado con usar el máximo de la pantalla ya que hay pantallas muy anchas y por usabilidad esto podría ser un fallo.

¿Me gustaría saber utilizar librerías propias? Hace tiempo utilicé la de Captchar… Pero si son algo mas complejas no tengo idea. Pregunta viclomu

La idea general es la siguiente. Van en la carpeta vendor si es para PSR0 y PSR4 lib, las que no lo son cada una tiene una forma, lo mejor es crear un fichero php en libs y poner la carpeta dentro de libs con la librería. Si la librería es un fichero solo en libs. Si es mas completa va en una carpeta y un fichero nombre_clase.php que tendrá que llamar a lo que necesite, algunas traen autoload otras has de llamar al fichero principal, hay que hacerle un puente en los casos necesarios ya que no hay una forma única.

Tip para usuarios de Atom:

Se puede lanzar fácilmente un servidor de PHP con el siguiente paquete: https://atom.io/packages/php-server recuerda lanzarlo desde la carpeta public como muestra la siguiente imagen:

Esto ha sido parte de todo lo que se aprende en Slack y los Kumbieros ¡Hasta la próxima!

La entrada Preguntas resueltas en Slack 1 se publicó primero en KumbiaPHP Framework PHP en español.

Esto sirve como muestra de que es muy estable, a pesar de tener el calificativo de versión «Beta»,  para desarrollar aplicaciones.

Empléate.com es una de las bolsa de empleo mas importante de la región latinoamericana. Han realizado su renovación del portal, con KumbiaPHP como herramienta de desarrollo, obteniendo resultados importantes. En el Portal de Empléate.com encontramos números muy interesantes.

Presentes en toda Hispanoamérica, con énfasis en Colombia, México, Perú y Venezuela.
+ 1,2 millones currículos en nuestra base de talentos.
+300 mil nuevos currículos ingresados cada año.
+70% de técnicos y profesionales.
+70 mil currículos enviados diariamente a las empresas reclutadoras.
+600 mil búsquedas automáticas («alertas») activas por parte de los usuarios.
+400 mil correos enviados a diario.
+80 mil empresas utilizan nuestros servicios.
+150 mil ofertas de empleo publicadas anualmente.
+12 millones de páginas vistas y +1 millón usuarios únicos cada mes en www.empleate.com.
+20 mil vacantes de empleo activas
La bolsa de trabajo más utilizada en Venezuela (50% de todas las ofertas publicadas por cualquier medio, sea impreso o digital).

Torneo de Futbol Copa Sa Pobla es un torneo que se hace en semana santa es Sa Pobla, Mallorca de futbol base menores de 10, 12 y 14 años.

Chattagena es una web de publicaciones de actualidad en musica, video, cine y a fines, en apoyo al talento cartagenero (Colombia).

CatGenie el Autor nos comenta…

CatGenie es un proyecto que vende un producto innovador y exclusivo para gatos (un arenero autolavable). CatGenie esta realizado en KumbiaPHP en la versión Spirit de principio a fin, aprovechando la velocidad y demás características del framework que hacen que el desarrollo y el mantenimiento sea rápido y fácil.

Esta lista es mas extensa, sólo hemos tomado algunas al azar.

Puedes enviarnos tu sitio web y/o publicarla en Webs Hechas con KumbiaPHP, asimismo invitamos a todos agregar sus Casos de Exitos Utilizando KumbiaPHP. No necesitas una aplicación grande ni pequeña, es sólo colocar un breve de resumen, de lo útil que te ha sido utilizar KumbiaPHP para tu desarrollo.

La entrada Webs hechas con KumbiaPHP Framework se publicó primero en KumbiaPHP Framework PHP en español.

P.D. si no entienden algunas de las láminas pregunten por aquí :-D

La entrada KumbiaPHP un framework con ñ se publicó primero en KumbiaPHP Framework PHP en español.