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.

El problema de dejar PRODUCTION en false:

De manera predeterminada, KumbiaPHP expone la información detallada de cualquier tipo de excepción, a modo de permitirle al desarrollador revisar y entender dónde debe realizar mejoras. El problema es que si se olvida de cambiar el flag de PRODUCCION y lo deja en su valor inicial (false) cuando los usuarios finales realicen alguna operación indebida, o exista algún fallo no previsto en el servidor, por ejemplo con el acceso a la base de datos o al sistema de archivo, Kumbia no tendrá contexto de que se trata de una aplicación en producción y expondrá todos los detalles.

La nueva configuración Exception:

La nueva funcionalidad, de forma definitiva, evita exponer información de excepciones, lo cual es un alivio tanto para los desarrolladores como para los clientes. Para permitir la visualización de excepciones se ha agregado un nuevo archivo llamado exception.php. En su contenido se pueden definir las direcciones IP que tendrán permiso para recibir los detalles entregados por KumbiaPHP tanto en desarrollo como en entorno productivo.

Ventajas de la nueva funcionalidad

Dentro de las ventajas que se obtienen con esta nueva mejora podemos mencionar las siguientes:

• Seguridad: evita la exposición accidental de información sensible.
• Control: permite que sólo los desarrolladores o administradores puedan acceder a los detalles de los errores.
• Fácil configuración: los usuarios solo necesitan añadir las IPs de confianza.

Cómo implementar la nueva funcionalidad:

Para implementar la nueva funcionalida necesitamos seguir los siguientes pasos:

1. Configurar las direcciones IP en el archivo exception.php.
2. Comprobar que los errores solo son visibles desde las IPs configuradas.

Caché:

Desde esta nueva funcionalidad, el flag PRODUCTION asignado con el valor true, sólo será reponsable de habilitar el uso de la caché para el sitio web.

Recordatorio:

Nunca está demás dejar un recordatorio extra: aunque estés en modo desarrollo, si no se incluyen las direcciones IP dentro del archivo exception.php verán únicamente el error clásico, sin todos los detalles. Por lo tanto, no se olviden de agregar su propia dirección dentro de la nueva configuración.

Conclusión:

La nueva configuración de Exception en KumbiaPHP es un gran paso hacia la seguridad en entornos de producción, permitiendo que sólo quienes están autorizados puedan ver los detalles de los errores. Este tipo de mejoras no sólo protegen nuestras aplicaciones, sino que también promueven buenas prácticas en el desarrollo. De todos modos, el equipo está trabajando en agregar funcionalidades para esta nueva característica, así que no te pierdas las próximas mejoras que publicaremos también en nuestro blog.

Mucho ánimo a todos en nuestra comunidad, y como siempre les decimos… ¡larga vida a KumbiaPHP!

¡Un abrazo!

La entrada Mejora en la configuración de errores en KumbiaPHP: Nueva funcionalidad Exception para entornos de producción se publicó primero en KumbiaPHP Framework PHP en español.

KumbiaPHP 1.2 optimizado para PHP 8: Adopción total y ventajas

Una de las principales novedades de KumbiaPHP 1.2 es su completa compatibilidad con PHP 8. Si ya estás utilizando PHP 8 o tienes planes de actualizarte pronto, esta versión de KumbiaPHP es esencial para ti. PHP 8 introduce una serie de mejoras y nuevas características que permiten escribir código más limpio, eficiente y moderno. Al adoptar estas innovaciones, hemos optimizado el núcleo de KumbiaPHP, logrando una reducción significativa en las líneas de código.

Un núcleo más ligero y rápido

Gracias a las nuevas características de PHP 8, hemos logrado simplificar y reducir el núcleo de KumbiaPHP. Esto se traduce en menos líneas de código, y lo convierte en un framework aún más rápido y eficiente. Menos código significa menos posibilidades de errores y un rendimiento mejorado, lo cual es crucial para el desarrollo de aplicaciones modernas y escalables.

Todo funciona igual, pero de forma más eficiente

Sabemos lo importante que es la estabilidad y la compatibilidad para nuestros usuarios. Por eso, aunque hemos realizado cambios significativos en el núcleo, el funcionamiento general de KumbiaPHP sigue siendo el mismo. Puedes actualizar a la versión 1.2 con la confianza de que tu aplicación continuará funcionando como antes, pero con las mejoras en rendimiento y eficiencia que PHP 8 ofrece.

Futuras actualizaciones y nuevas librerías

La versión 1.2 de KumbiaPHP es sólo el comienzo. En las próximas versiones menores, continuaremos aprovechando las ventajas de PHP 8, incorporando nuevas librerías y actualizaciones que enriquecerán nuestro framework. Estamos comprometidos en mantener a KumbiaPHP a la vanguardia de la tecnología, proporcionando a nuestros usuarios las herramientas necesarias para desarrollar aplicaciones robustas y eficientes.

Recomendación adicional

Dado que PHP 8.0 cumplió su ciclo de vida, sería recomendable ir adaptándose a las versiones más modernas que actualmente tienen soporte activo como la 8.2 y 8.3.

¿Por qué actualizar a KumbiaPHP 1.2?

• Compatibilidad Total con PHP 8: Aprovecha todas las mejoras y nuevas características de PHP 8.
• Menos Código, Más Eficiencia: Un núcleo más ligero que mejora el rendimiento de tu aplicación.
• Estabilidad Garantizada: Continúa desarrollando con la tranquilidad de que todo funciona igual.
• Futuras Mejoras: Nuevas librerías y actualizaciones que seguirán optimizando tu experiencia de desarrollo.

¡Actualiza hoy mismo a KumbiaPHP 1.2 optimizado para PHP 8 y lleva tu desarrollo al siguiente nivel!

La entrada KumbiaPHP 1.2 optimizado para PHP 8: código simplificado y mayor velocidad se publicó primero en KumbiaPHP Framework PHP en español.

La entrada Compartir el core para diferentes aplicaciones se publicó primero en KumbiaPHP Framework PHP en español.

Instalación de KumbiaPHP usando XAMPP en Windows

El segundo video trata sobre la…

Configuración de virtual host en Apache para usarlo con KumbiaPHP

La entrada Instalación de XAMPP y configuración de VirtualHost se publicó primero en KumbiaPHP Framework PHP en español.

Tendremos un servidor local de PHP perfecto para desarrollo, sin usar WAMP o XAMPP server.

Antes de comenzar, te dejamos un enlace donde se explican las implicancias del WSL (Windows Subsystem for Linux) https://es.wikipedia.org/wiki/Windows_Subsystem_for_Linux

Vamos con los requisitos. Lo primero que necesitamos es habilitar la caracterísca de Subsistema Linux desde Windows.

Instalar WSL en Windows 10

Para ello hacemos clic en inicio y escribimos <em>Características de Windows</em> (en mi caso se verá diferente porque llevo una versión de Windows en inglés)

Luego buscaremos al final de la lista el Subsistema Linux para Windows (ver imagen siguiente)

Lo seleccionamos haciendo clic en la casilla de la izquierda, y finalizamos picando en el botón OK para que los cambios sean aplicados.

Tendremos que reiniciar para que la configuración se vea actualizada.

Seleccionar la distribución de Linux en la Tienda de Microsoft

Una vez hecho eso, iniciaremos a la aplicación Tienda de Microsoft (Microsoft Store) y usando su buscador, escribiremos la palabra linux.

La lista de opciones es variada pues se cuenta con Ubuntu, Kali, Debian, OpenSuse, entre otros. Para cuestiones de demostración he seleccionado la opción Debian (aunque en otra máquina lo he probado con Ubuntu 18.04).

Bastará con seleccionar la opción de vuestro gusto, y luego presionar el botón Obtener (Get en mi caso)

Puede que el instalador te pregunte, si quieres mantener sincronizadas tus máquinas de acuerdo a tu cuenta. En mi caso, prefiero que sólo sea instalado en esta máquina, sin importar la sincronización posterior (para ello te requerirá iniciar sesión con una cuenta de Windows Live – Hotmail, Outlook u otra)

En este diálogo he seleccionado «No, gracias». Luego de la respuesta, ha comenzado el proceso de instalación.

Crear usuario y contraseña de la consola de linux

Cuando la configuración de la consola linux haya finalizado, nos pedirá crear un usuario con nombre y contraseña.

Noten que el nombre de usuario de la consola, no tiene por qué coincidir con el nombre de usuario de la máquina de Windows. Una vez creado el usuario habremos finalizado la instalación de la consola de Linux!

Entonces ya tenemos nuestra estación Linux completamente funcional. 

Actualizar paquetes de Linux

En los derivados de Debian (como Ubuntu y Kali) les recomiendo comenzar ejecutando el comando:

<span class="token function">sudo</span> <span class="token function">apt-get</span> update

Con ello cargarás los repositorios de paquetes que podrás usar posteriormente.

Instalar PHP y MariaDB (MySql) en la consola Linux de Windows

Para usar Debian y derivados, con los requerimientos mínimos de desarrollo kumbiero necesitamos hacer la siguiente instalación

<span class="token function">sudo</span> <span class="token function">apt-get</span> <span class="token function">install</span> php php-cli php-mysql mariadb-server php-mbstring <span class="token function">git</span> <span class="token function">wget</span> unzip

Instalar KumbiaPHP framework

Una vez que hemos finalizado la instalación, podemos hacer una prueba descargando la versión de KumbiaPHP desde la página principal del proyecto

Lo hacemos desde el icono de descarga para el formato tar. Hacemos clic con el botón secundario (normalmente el derecho) y copiamos el link desde el botón Copiar enlace (Copy link)

Luego desde la consola escribimos wget y pegamos lo que tenemos en el portapaleles. Deberíamos lograr una línea de ejecución como la siguiente:

<span class="token function">wget</span> https://github.com/KumbiaPHP/KumbiaPHP/archive/v1.0.0.tar.gz

Descomprimimos la descarga:

<span class="token function">tar</span> xvfz v1.0.0.tar.gz

Y renombramos la carpeta resultante con un nombre que tenga relación con el trabajo que llevaremos a cabo (usando el comando mv)

Finalizamos la prueba de instalación entrando en la carpeta que hemos creado hasta llegar a <strong>default/app</strong>

Servidor PHP local

Sin instalar Apache o Nginx,  escribiendo el comando:

bin/phpserver

Windows nos preguntará, si acaso queremos permitir conexiones desde redes internas o desde fuera de la red. Para efectos de prueba he seleccionado ambas opciones y he presionado el botón «Permitir acceso» (Allow access)

Entonces, nuestra aplicación recién instalada de KumbiaPHP estará disponible desde la dirección http://0.0.0.0:8001. En caso que no resulte también puedes invocarla usando la url de http://localhost:8001, o usando http://127.0.0.1:8001, o incluso la dirección ip interna de tu máquina como por ejemplo http://192.168.1.101:8001. Esta última opción nos servirá para hacer pruebas desde otros dispositivos conectados a la misma red (por ejemplo desde un tablet, o un móvil)

Permisos de la base de datos (Mysql, MariaDB, Postresql, otros)

Un dato final, es si usamos MySQL o MariaDB o Postgresql, Windows nos preguntará si queremos dar acceso a dichos servicios, tal como ha hecho cuando hemos lanzado <strong>bin/phpserver</strong>. En dicho caso sólo les recomiendo habilitar el uso en el equipo y la red local. No para el exterior. Aunque esta es una decisión que debe tomar cada uno.

¿Y qué hemos ganado con lanzar KumbiaPHP con el comando bin/phpserver?

Pues la ventana en la que lo hemos lanzado, se ha convertido en una ventana de log de utilización, por la que veremos cada una de las acciones que realice el framework mientras estamos trabajando con él

Y lo más importante, también veremos los errores al instante, para depurar más rápidamente nuestas aplicaciones.

Y hasta aquí nuestra publicación :-)

Esperamos que les sea de utilidad y que con ello tengan nuevas opciones de disfrutar programando con el framework más rápido del oeste!

Saludos a todos nuestros colegas kumbieros!

Post data: si eres nuevo por aquí te recomendamos ver algunos de nuestros posts para los recién llegados:

KumbiaPHP essentials

Scaffolding con KumbiaPHP

Dicho esto,

Larga vida a KumbiaPHP!

La entrada Servidor PHP desde la consola Linux de Windows se publicó primero en KumbiaPHP Framework PHP en español.

Para el software de gestión tumia.co hemos desarrollado más de 30 módulos, creado un API REST y también un APP para Android y para iOS.

Ha sido un trabajo largo, llevamos 5 años en este proyecto y nos apoyamos en Kumbiaphp como se indica en el post que publicamos

Antes de tumia.co …

Antes de crear tumia.co desarrollamos varios sistemas de CRM, de comercio electrónico, de historia clínica, entre otros y eso nos sirvió para ver lo tedioso, complejo y costoso que resulta hacer un software sin un buen framework y sin una buena comunidad que lo respalde.

Crear otros sistemas fue fácil, pero dar soporte, actualizar, mejorar y agregar nuevos módulos era un dolor de cabeza (en ese tiempo).

Mediante Kumbiaphp resolvimos ese asunto, luego de aprender a usar el framework en poco tiempo, creamos una plataforma llamada Recaudo Efectivo con la cual atendíamos la facturación electronica de los clientes, poco a poco fue creciendo, pero a diferencia de los proyectos anteriores, con Kumbiaphp dar mantenimiento, realizar mejoras y agregar nuevos módulos no fue un dolor de cabeza, todo lo contrario.

Con Kumbiaphp crear nuevos módulos y dar soporte es todo un placer.

Equipo de desarrollo de tumia.co

Durante casi 5 años hemos depurado nuestro sistema, en ocaciones no usamos patrones de diseño y nos desviamos, pero retomar el buen camino con el framework y el apoyo de la comunidad resulto en algo muy sencillo.

Las actualizaciones del framework

Posteriormente actualizar la version de PHP y adoptar las nuevas características del framework en nuestro sistema no fue nada complejo y es algo que nos gusto muchísimo, pues con otros framewoks suele ser un problema.

Actualizando Kumbiaphp no hemos tenido problema, siempre ha resultado fácil y nos beneficiamos de las nuevas características.

Equipo de desarrollo de tumia.co

Al momento de crear la APP android vimos la necesidad de crear una buena API para nuestro sistema y así compartir información con otros dispositivos; En esto nos sorprendió mucho Kumbiaphp, pues con el Rest Controller todo es super super fácil.

El rest controller junto con el Active records hace un equipo ganador… realmente veloz como lo indica el benchmark y para desarrollar nuevas funcionalidades resulta muy fácil y nada preocupante.

Capturas de pantalla de tumia.co

Dejamos unas pocas, pues el sistema es bastante extenso

Disfrutamos mucho en el desarrollo de tumia.co tenemos muchos módulos para desarrollar y otros para actualizar.

Con la evolución de Javascript y los frameworks JS, gran parte de nuestro sistema se esta apoyando también en vueJS, pero sin dejar a un lado a Kumbiaphp pues nos continua brindando una excelente API REST.

Agradecemos a la comunidad Kumbiaphp en Slack y buscamos el tiempo para apoyar este excelente proyecto http://slack.kumbiaphp.com/

Muy contentos animamos a los emprendedores a conocer y beneficiarse de todo lo que ofrece Kumbiaphp Framework.

La entrada Tumia.co Nuestra experiencia 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.

[Actualización: Abril 2020] Hemos creado un nuevo repositorio llamado Sandbox en Github donde van a estar todos los ejemplos y que podrán visualizar en vivo en la página KumbiaPHP Framework Examples por lo tanto el código se ha mejorado y los links han cambiado.

Template PDF

Un template permite ahorrar código que se repite en la vistas, permitiendo así un fácil mantenimiento y separación del contenido. Realizará la carga de librería, la cabecera y el pié de página y por supuesto el contenido que queremos mostrar.

Para los que aun no han visto el tema de templates en KumbiaPHP o tienen dudas de su funcionamiento los invito a leer la sección sobre el manejo de vistas en KumbiapHP. A continuación el código completo del template y más abajo con capturas se explica cada parte importante.

Archivo: app/views/_shared/templates/pdf/mpdf.phtml

<?php

use Mpdf\Mpdf;

/* Defaults */

// fileName
$fileName = $filename ?? "Reporte-de-$controller_name";

// Title
$title = $title ?? "Reporte de $controller_name";

// CSS
$css = $css ?? 'css/pdf.css';

// Destination I show in browser  D download
$destination = isset($download) && $download ? 'D' : 'I';

//Activa el almacenamiento en búfer de la salida
ob_start();

?>
<!DOCTYPE html>
<html lang="en">

<head>
    <title><?= $title ?></title>
    <link rel="stylesheet" type="text/css" href="<?= $css ?>">
    <meta name="author" content="KumbiaPHP framework">
    <meta name="description" content="PDF output example with KumbiaPHP framework">
    <meta name="keywords" content="kumbiaphp, php, pdf, mpdf, examples">

<body>
    <htmlpageheader name="myHeader1">
        <section id="page-header">
            <a href="https://www.kumbiaphp.com"><img src="img/kumbiaphp.svg" alt="Logo KumbiaPHP"></a>
            <p>Powered by</p>
        </section>
    </htmlpageheader>

    <?php View::content() ?>

    <htmlpagefooter name="myFooter1">
        <section id="page-footer">
            <div id="printed-date">{DATE d/m/Y}</div>
            <div id="page-number">{PAGENO}/{nbpg}</div>
        </section>
    </htmlpagefooter>
</body>

</html>
<?php
$html = ob_get_clean();
ob_clean();

// Crea una instancia de la clase y le pasa el directorio temporal
$mpdf = new Mpdf([
    'tempDir' => APP_PATH . 'temp/mpdf',
    'format' => 'A4',
    'title2annots' => true,  // convert headers <hx> in annotations
    'mirrorMargins' => 0,    // mirror the left and right margin values on odd and even pages 
    'exposeVersion' => false // security 
    // more variables in https://mpdf.github.io/reference/mpdf-variables/overview.html
]);

// Escribe el contenido HTML (Template + View):
$mpdf->WriteHTML($html);

// Genera el PDF, ya sea para su descarga o visualización en el navegador
$mpdf->Output("$fileName.pdf", $destination);

El proyecto ya usa el autoload de composer para tener disponible mPDF y simplemente importa Mpdf\Mpdf. Luego se definen algunas variables para personalizar el PDF y se ejecuta la función ob_start(). «Esta función activará el almacenamiento en búfer de la salida. Mientras dicho almacenamiento esté activo, no se enviará ninguna salida desde el script (aparte de cabeceras); en su lugar la salida se almacenará en un búfer interno.»

Si desean conocer como agregar encabezados y pies de páginas con mPDF un compañero realizó un manual en la Wiki de KumbiaPHP que muestra como agregarlos usando las funciones explicadas en el artículo anterior: Exportar a PDF con cabecera y pie de pagina

Ahora en el <body> definimos el contenido de la cabecera y el pie de página, y entre ellos la función View::content() que nos permite mostrar el contenido de la vista.

mPDF maneja sus propias etiquetas, van entre llaves {} y usamos algunas de ellas:

• DATE: Para mostrar la fecha actual
• PAGENO: Número de la página
• nbpg: Número total de páginas del documento

Y la parte final del template es la que se encarga de unir el template con la vista, generar el PDF con ese contenido y hacer que el documento se visualice o descargue.

Controlador PHP

Vamos a crear una nueva vista y para ello empezamos con el método que llamaremos pdf() en el controlador templates_examples_controller.php El código se encuentra explicado entre líneas.

Archivo: app/controllers/templates_examples_controller.php

public function pdf()
{
    //Usa el tempalte 'pdf'
    View::template('pdf/mpdf');
    //Modifica el nombre del archivo a descargar
    $this->fileName = 'user-list';
    //Modifica el título del documento PDF en la cabecera
    $this->title = 'User List';
    $this->download = false;

    $this->data = User::all(); // data to show (model User from db)
}

Vista HTML

Ahora crearemos la vista la cual tendrá la tabla, recorriendo uno a uno los registro de la consulta realizada por el modelo en el controlador.

Archivo: app/views/templates_examples/pdf.phtml 

<?php if (!count($data)) : ?>
    <h2>No hay ningún registro</h2> 
<?php else : ?>
    <table class="report">
    <caption class="caption"><?= $title ?></caption>
        <thead>
            <tr>
                <th scope="col">First Name</th>
                <th scope="col">Last Name</th>
                <th scope="col">Email</th>
                <th scope="col">Birthdate</th>
            </tr>
        </thead>
        <tbody> 
            <?php foreach ($data as $item) : ?>
                <tr>
                    <td><?= $item->first_name ?></td>
                    <td><?= $item->last_name ?></td>
                    <td><?= $item->email ?></td>
                    <td><?= $item->birthdate ?></td>
                </tr>
            <?php endforeach ?>
        </tbody>
    </table>
<?php endif ?>

No hace falta explicar mucho más de la vista anterior ya que es una vista normal en KumbiaPHP, esta vista es reutilizable por ejemplo si se quiere pasar a un documento Excel o devolver la vista mediante AJAX.

Enlazar al reporte PDF

Y en donde queramos que esté el enlace al reporte PDF simplemente lo añadimos a la vista deseada, nosotros lo hemos añadio a la página de información de los ejemplos de template.

Archivo: app/views/templates_examples/info.pdf.phtml

<a href="/templates-examples/pdf" target="_blank">Export users list</a>

Y al pulsar el botón visualizaremos el documento PDF como el siguiente:

Descargar código completo

Como siempre, el código completo está disponible para todos en el siguiente repositorio en Github listo para usar: https://github.com/KumbiaPHP/Sandbox/

La entrada Exportar tabla HTML a PDF 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.