En este post nos iremos hasta la etapa de producción de nuestro proyecto y veremos las consideraciones que deberemos tener en cuenta  para no llevarnos una sorpresa y sobre todo nuestros usuarios.

Config.php Configuración de Aplicación

Si ya estamos en modo de producción es importante indicárselo a KumbiaPHP y esto se hace en el archivo config.ini, que por default viene como off (production = Off).

Es recomendable tambnien tener un dataSocurce de nuestra base de datos para la producción(production) y otro para desarrollo (development) donde podremos hacer pruebas.

Y por su puesto que no nosgustaria que nuestros usuarios vean los errores de php.

debug = Off #muestra los errores en pantalla (On|off)

El timezone, creo que esto se debe de configurar desde la etapa de desarrollo.

En mi caso la configuración seria así. En este archivo se explica para que es cada línea.

• database = production                      ;base de datos a utilizar
• production = On                               ;Indica si esta en producción
• timezone = “America/Mexico_City”
• debug = Off                                     ;muestra los errores en pantalla (On|off)
• log_exceptions = Off                        ;muestra las excepciones en pantalla (On|off)
• cache_driver = file                            ;driver para la cache (file, sqlite, memsqlite)

default/public/index.php

Bueno en este mismo archivo nos indican que líneas deben estar en desarrollo y cuales en producción.

error_reporting(0); // Usar este en producción, no envia errores
//error_reporting(E_ALL ^ E_STRICT); // Comentar en producción
//comentar la siguiente linea en producción
//ini_set('display_errors', 'On'); 

La cache

Como se observa en el config.ini la cache se lleva mediante archivos, por lo que es importante que esta carpeta este vacía (o al menos no contenga ningún archivo de cache).

Ojo, si hacemos un cambio a nuestra base de datos ya estando en producción, entonces les recomiendo que vuelvan a borrar estos archivos, ya que es posible que no le reconozca los cambios de su BD.

Error 404

KumbiaPHP tiene una vista para mostrar este error en modo producción, sin embargo es recomendable personalizar esta pagina, para indicar a nuestros usuarios del problema o mostrarles otros enlaces.

app\views\_shared\errors/404.phtml

Espero que esto les sea de utilidad para cuando vayan a lanzar su aplicación a producción, y claro nos pueden compartir su experiencia la cual siempre será bienvenida.

Artículo origen

En GitHub se encuentra una aplicación de kumbiaPHP llamada KumBoot, el cual es por la combinación entre los frameworks KumbiaPHP y Bootstrap. Esta app se encuentra lista para descargar y empezar a desarrollar.

Es necesario contar con el core de Kumbia ya que lo que estaremos descargando es solo la aplicación.

Sitio oficial Descargar la app

KumbiaPHP como cualquier otro framework, hace uso del modo rewrite de apache, pero internamente cuentra con una clase llamada Router con la cual podemos crear url´s, las cuales se configuran en /app/config/rouerts.ini (Que por default biene desactivado),  en este post veremos unos ejemplo prácticos del uso de esta clase, y sobre todo una adecuación que realice para sacarle a un mas ventaja a esta clase.

El router que viene de ejemplo en routers.ini es:

/status/ = pages/show/

El cual al escribir la URL:  http://miDominio/status/  en realidad estará ejecutando la función show del controlador pages.

Podemos usar

Router::get(‘module’).”/”.Router::get(‘controller’).”/accion/parametros”

Entro de los enlaces, de esta manera si cambiamos el nombre del controlador o del modulo no afectaremos la navegación ya que esta estará tomando el nombre del modulo y controlador actual, de echo podremos llevarnos un controlador a otro modulo y la navegación funcionara de maravilla.

Ahora bien, veamos un ejemplo practico del Router con el cual nos ahorraremos mucho trabajo.

Supongamos que tenemos una aplicación para gestionar ventas, clientes y proveedores.

/app
–Views
—-Ventas
—-Clientes
—-Proveedores

Dicha aplicación nos genera reportes los cuales se encuentran y se mandan llamar de la siguiente manera.

ventas/reportes/deldia
ventas/reportes/mensual
clientes/reportes/deudores
clientes/reportes/foraneos
proveedores/reportes/foreneos

Por lo que tenemos en cada modulo un controlador llamado reportes_controller.php el cual gestionara los reportes de cada modulo.

Pero un día se nos ocurre la gran idea de reorganizar esto, por que hemos pensado que seria mejor y mas limpio tener un modulo que gestione todos los reportes existentes y por haber con la siguiente estructura:

app/
–Views
—-reportes
——clientes
——ventas
——proveedores

Entonces nos encontramos con un problema.

• Actualizar los link que nos llevaran al nuevo modulo de los reportes
• Una ves echo lo anterior nos quedarían las urls:
  

  reportes/ventas/deldia
  reportes/ventas/mensual
  reportes/clientes/deudores
  reportes/clientes/foraneos
  reportes/proveedores/foreneos

  Pero nos podemos evitar esto creando unos routers los cuales quedarían de la siguiente manera:
  

  ventas/reportes/*             = reportes/ventas/*
  ventas/reportes/*             = reportes/ventas/*
  clientes/reportes/*            = reportes/clientes/*
  clientes/reportes/*            = reportes/clientes/*
  proveedores/reportes/* = reportes/proveedores/*

  De esta manera solamente nos preocupamos por reorganizar los archivos y no los link, ya que haciendo uso de la tabla de enrutamiento, KumbiaPHP hará el resto (podemos enviar todos los parámetros necesarios).

  Recordemos que el nombre de las acciones deben ser iguales.

Artículo origen

En un post anterior les presente un plugins para jQuery el cual nos permite la manipulación del componente select de HTML, pues bien ahora veremos como crear servicios con kumbiaPHP para usar la característica de cargar un select mediante este plugin.

El servicio que vamos a crear nos deberá devolver un objeto en formato JSON (Debemos especificar que el contenido es de este tipo, de lo contrario solo lo tomara como texto).

Para hacernos la vida mas sencilla e identificar que controlador hace la función de servicio, vamos a crear un nuevo controlador base de la cual extenderán todos nuestros controladores de servicios.

En este caso el nuevo controlador se llama ServicesController y se encuentra ubicado en app/libs/

ServicesController

La razón por la que debemos crear un nuevo es por las siguientes razones:

• Teniendo este controlador base ya no será necesario especificar en cada controlador donde queramos hacer un servicio, indicar que la respuesta a devolver es de tipo JSON.
• Separar nuestros servicios de nuestros controladores para una mejor organización
• En cada creación de servicio indicar que no debe seleccionar ninguna vista y ningún template.

Nuestro controlador

Como podemos observar ahora nuetro controlador extiende de ServiceController. por lo que solo nos enfocamos en devolver la respuesta en formato JSON, para esto podemo hacer uso de la función propia del Active_Record que es –>to_json(), la cual usa la función json_encode nativa de php (versión 5,3 en adelante).

Nuestro modelo

En nuestro modelo concentramos las consulta, es importante crear alias value y text ya que serán estos serán usados por el plugin HTML SELECT (sus nombres son muy descriptivos) para llenar el select.

Y listo ahora solo nos queda llamar a estas funciones desde nuestra vista.

y nos llenara el select con el id “id_select”

Y listo con esto le sacaremos mucho mas partido a KumbiaPHP

https://github.com/govaniso/Html-select

http://soyprogramador.liz.mx/plugins-para-manipular-el-componente-html-select/

Artículo origen

En un post pasado se comento sobre el uso de los Routers en KumbiaPHP, pues bien resulta que desarrollando encontré en la necesidad de modificar cla Clase del Router para adaptarlo a mis necesidades y las que exigía el proyecto. antes de ir pasar y ver en que consistió esta modificación vemos un escenario del problema.

Su pongamos que estamos desarrollando un sistema para un inventario, en el cual es necesario dar de alta artículos, pero resulta que esta funcionalidad es necesaria tanto para el administrado, inventarios e incluso en las ventas (Vaya que me ha tocado). Entonces tenemos nuestro sistemas por módulos:

administrador/
ventas/
inventarios/

Por lo que las url deben ser.

http://dominio.liz.mx/administrador/nuevoArticulo

http://dominio.liz.mx/ventas/nuevoArticulo

http://dominio.liz.mx/inventarios/nuevoArticulo

Bueno el problema de la funcionalidad queda resulto con el uso de routers y seria algo como esto:

inventarios/nuevoArticulo/* = common/nuevoArticulo/*
ventas/nuevoArticulo/*= common/nuevoArticulo/*
administrador/nuevoArticulo/* = common/nuevoArticulo/*

Pero resulta que por políticas de la empresa es necesario llevar una bitácora de las acciones de los usuarios. por lo que no será difícil obtener el modulo, controlador y la acción que se esta ejecutando. El verdadero problema viene cuando registramos el modulo ya que todos (sin importar modulo y usuario) que dará registrado como common, pero esta información no le sirve a la empresa, por que lo que ella quiere saber es si entro desde inventarios, ventas o administrador.

¿Por que pasa esto?

Esto pasa por que KumbiaPHP se queda con el modulo destino y no desde el cual se esta invocando, ya que se podría llamar desde controlador sin modulo.

La solución

Conociendo nuestra necesidades y el como procesa KumbiaPHP las URL entonces es momento de hacer esta adecuación, por lo que antes de ser procesada la URL debemos de obtener el modulo origen para después reescribir el modulo destino.

y con esto nuestra aplicación seguirá funcionando de manera normal y obtendremos la bitácora que deseamos. y vaya que funciona.

Aquí les dejo él archivo con la solución.

Si tienen implementado ya funcionalidad y hacen uso del modu

Este archivo mantiene la la funcionalidad de kumbiaPHP, pero agrega la posibilidad de conocer el modulo origen al cual se le aplicara el rewrite.

https://gist.github.com/3960630

Este otro fue el que modifique, y como ya tenia un buen avance desarrollado, decidí sobre-escribir la variable “module”, para que mantuviera el modulo origen y así no me perjudicara. Teniendo conciencia de este cambio. Pero lo comparto por si alguien ya tiene un avance significativo y no quiere cambiar su código.

https://gist.github.com/3960622}

Para aplicar los cambios bastara con  con reemplazar el código del archivo /core/kumbia/router.php por el de las ligas.

Artículo origen

En kumbiaPHP podemos seleccionar la base de datos con la cual queremos trabajar para una determinada tabla, con lo cual podemos tener en nuestro proyecto modelos de distintas base de datos, veamos un ejemplo de un modelo:

Nuestro archivo de configuración de base de datos.

En este archivo es necesario definir todas las conexiones a usar en nuestra aplicación.

[development]
host = localhost
username = root
password = kasandra
name = kumbia
type = mysqli

[ex]
host = localhost
username = root
password = kasandra
name = ex
type = mysqli

Nuestro modelo

En nuestro modelo en el metodo de initialize debemos indicar que base de datos se utilizara en nuestro caso es “ex”.

class Escolaridad extends ActiveRecord
{
    public function initialize(){        
        $this->set_database("ex");
    }
}

con esto podemos consultar datos de otras BD en una misma aplicación.

Articulo Origen: Kumbiaphp.info

Es probable que nos encontremos con este error catchable fatal error al estar usando alguna librería de algún tercero, ¿y por que asocio kumbiaPHP con este error?, estaba usando una librería pero actualice el core de kumbiaPHP, y fue como apareció este error pensé que era problema del servidor ya que curiosamente actualice cuando iba  a subir el código al server. pero después de analizar un poco y sin entrar en tanto detalle lo resolví de la siguiente manera.

Antes

Load::model("services/libreria");

Después

require_once APP_PATH . 'models/services/libreria.php';

Y con esto volvió a funcionar de manera correcta.

El problema se debe a una actualización de la clase load.php del core de kumbiaPHP

en el return de la función model se agrego la variable $params

Ultimo commit

return new $Model($params);

Anteriormente

return new $Model();

Y el problema viene cuando usamos librería complejas donde se llaman entre si a muchas clases y se envían variables al constructor por ejemplo:

public function __construct(array $options = array())
	{
		$this->vhost = null;
		$this->hostname = self::DEFAULT_URL;
		...
		parent::__construct($options);
	}

En fin la solución mas rápida y sencilla es el uso de require_once ..

Como les comente hace algunos días estoy preparando una app para demostrar las cualidades de kumbiaPHP y sirva a otros para iniciar sus nuevos proyectos, la aplicación consistirá en una app para el control del inventario de préstamo de libros en una biblioteca.

KumbiaPHP + Biblioteca = Kateca

En este primer post se entrega lo siguiente

• Creación del repositorio en github el cual es: https://github.com/govaniso/kateca.git
• Integración del framework foundation vrs 3.2 para nuestro front-end.
  • Se agregan archivos css con sus respectivas imágenes y archivos js
  • Se modifica el témplate default para adaptarse al framework.
• Creación de un partial llamado menu
• Configuración del archivo config.ini
  • Establecer zona horaria
  • Nombre de la aplicación
  • namespace para la autenticación

Entonces en nuestro template default quedara dividido en tres secciones

• Menú
• Content
• Footer

Es muy probable que agreguemos la sección header.

Cabe notar que en el titulo de la pagina se verifica si existe de no ser hacer por default será Kateca Dev

Articulo Origen: Kumbiaphp.info

Este proyecto es una buena opción para iniciar nuestra app en kumbiaPHP, y los módulos de los que consta esta son los necesarios.

ya ahora tenemos dos opciones para el Backend la otra es esta opción de la cual ya se hablo antes, para cualquier duda sobre el proyecto pueden dirigirse a al grupo de kumbia en google.

Módulos de la APP

Perfiles

La gestión de perfiles permite administrar los direfentes roles de los usuarios que acceden al sistema.

Recursos

Los recursos son las acciones o métodos que se pueden ejecutar en los controladores

Privilegios

Los privilegios son los recursos que puede acceder cada perfil creado, brindando una mayor seguridad y escalabilidad al sistema

Menús

La administración de menús permite gestionar los diferentes menús para que los usuarios accedan a los recursos. Por ahora cada menú puede tener un submenú

Empresa

Permite la administración de los datos básicos de la empresa

Sucursales

Si esta opción está habilitada, permite gestionar las sucursales de la empresa y asignarla a un usuario específico

Accesos

Permite la visualización de las entradas y salidas de los usuarios del sistema

Backups

Permite crear copias de seguridad y restaurar el sistema en un punto específico

Auditorías

Las acciones que realizan los usuarios en el sistema se registran para tener un control sobre los eventos generados.

Visor de sucesos

Si está activo, permite la visualización de los logs de las consultas generadas en la base de datos, para tener un control sobre la base de datos

Mantenimiento

Permite optimizar, vaciar el cache, desfragmentar y reparar (si es posible) las tablas de la base de datos

Archivos de configuración

Permite editar los diferentes archivos de configuración del sistema ubicados en la carpeta “config” de la aplicación

Este backend es 100% responsivo y adaptado a todo tipo de pantalla con la elegancia del bootstrap de twitter y el poder de kumbiaphp
El repo del proyecto está en https://github.com/dailyscript/dbkm/
El demo: dbkm.dailyscript.com.co
usuario: admin
pass: 123456

Articulo Origen: Kumbiaphp.info

KumbiaPHP nos permite usar base de datos SQLite, pero antes contare anécdota para evitar que ustedes sufran por no configurar correctamente su DNS en el archivo databases.ini

Les recomiendo que es preferible usar la librería de conexión SQLite con PDO, una vez habilitada esta librería debemos especificar el DSN que no es otra cosa mas que la ubicación de la base de datos, en mi experiencia diseñe mi BD (creación de tablas, llaves primarias, etc) con Valentina Studio, y como por default en el archivo databases.ini se establece

  dsn = “test/data.db”

podemos llegar a pensar que la carpeta test deberá ir en la carpeta app, así que omití esta carpeta y hay guarde mi archivo de SQLite directamente en app para probar la conexión con la bd, quedando así la configuración

dsn = “SQLite.db”

Sin embargo después de crear el modelo y crear una instancia de un modelo, me tope con el mensaje de  La tabla Usuarios no tiene una llave primaria definida,  por lo cual no entendí el error ya que si había especificado dicha llave, después de investigar por unos minutos encontré el que problema, y lo que pasa que, esta configuración de DNS buscaba el archivo SQLite en la carpeta de public, por lo cual por seguridad prefiero que este ubicado en app, así que modifique el archivo para que tomara el archivo correcto, quedando a configuración de la siguiente manera.

;Ejemplo de SQLite

[development]
dsn = ../app/SQLite.db
type = sqlite
pdo = On

Con este articulo espero haber explicado y dar respuesta para los que llegaron o tienen este problema de configuración, por otra parte también se explica como configurar correctamente el DNS cuando trabajamos con SQLite.

Anunciando el próximo Taller de KumbiaPHP en México,  este taller se llevara a cabo en el Instituto Tecnológico de San Juan del Río, dentro su 8° congreso Nacional de Tecnologías de la Información, El taller tendrá una duración de 3 x 3 (3 horas x 3 días)

Adelantando la presentación (versión NO final)

Publicidad oficial del Instituto Tecnológico de San Juan del Río

Taller KumbiaPHP Mexico ITSJR

Que necesitas para el taller

• PHP 5
• MySQL
• Apache (Appserv, bitnami, wamp, xamp)
• NetBeans para PHP (importancia de un IDE)
• HeidiSQL (u otro software de SGDB)

Articulo recomendados

Información via: http://www.kumbiaphp.com

Como dice el titulo esta es la primera entrega de como subir archivos con kumbiaPHP, para esta primera entrega utilizare la herramientas propias de kumbiaPHP posteriormente utilizaremos algunas librerías de terceros.

Estoy trabajando para que puedan ver los ejemplos de los tutoriales corriendo en vivo y lo puedan comprobar por sus propios ojos los resultados. pero por lo mientras espero que disfruten este post.

A subir imágenes

Nuestra vista imagenes.phtml

echo "Subir Imágenes";
 //upload/imagenes
 //uload: nuestro controlador
 //imagenes; nuestra accion
 echo Form::openMultipart('upload/imagenes') ;
    echo "Ingrese una imagen .jpg , .gif ó .png :";
     echo Form::file('imagen') ;
     echo Form::hidden('oculto'); //para saber si se envió el form
     echo Form::submit('subir') ;
 echo Form::close() ;

Nuestro controlador uploadController

public function imagenes() {
	View::template("default");
	 if (!empty($_FILES)) {  //para saber si se envió el form
	     //llamamos a la libreria y le pasamos el nombre del campo file del formulario
	    $archivo = Upload::factory('imagen');

	    $archivo->setMinSize("262144");//Tamaño minimo del archivo 250 bytes aprox
	    $archivo->setMaxSize("1048576");//Tamaño maximo del archivo 1 MB
		/*
		Establememos la ruta donde se guardara el archivos
		Si no se establece:
		$archivo->setPath("files/upload/imagenes");
		Por default almacena el archivo en: files/upload/
		*/
	    $archivo->setPath("files/upload/imagenes");

	   //le asignamos las extensiones a permitir
	   $archivo->setExtensions(array('jpg','png','gif')); 

		if ($archivo->isUploaded()) {
		        if ($archivo->save()) {
				Flash::success("Imagen subida correctamente");
			}
		}else{
	              Flash::error('No se ha Podido Subir el Archivo...!!!');
		}
	}
}

Más funciones para archivos de tipo imagen

/*Asigna el ancho mínimo de la imagen*/
$archivo->setMinWidth($value);

/*Asigna el ancho máximo de la imagen*/
$archivo->setMaxWidth($value);

/*Asigna el alto mínimo de la imagen*/
$archivo->setMinHeight($value);

/*Asigna el alto máximo de la imagen */
$archivo->setMaxHeight($value);

KumbiaPHP incorpora un controlador llamado RestController el cual nos viene de gran  ayuda al momento de crear servicios REST ya que nosotros solo nos preocupamos por los datos a devolver  y manipular los recibidos y este controlador le dará formato en json, xml o csv según corresponda o nosotros especifiquemos.

Ahora veremos cómo empezar!!

Crearemos un controlador como siempre lo hemos realizado con la diferencia que ahora lo vamos a extender de RestController

En el código anterior he creado un controlador llamado services, el cual al momento de recibir una petición GET invocara a la acción get, Por default cada acción se llama como el método usado por el cliente  como pueden ser  GET, POST, PUT, DELETE, OPTIONS, y demás.

Por lo cual en un controlador REST podríamos tener al menos 4 acciones

Public function get($id){}

Public function post($id){}

Public function put($id){}

Public function delete($id){}

Pero muchas veces necesitamos algo más que eso, para ello podemos hacer uso de la convención de nombre para servicios rest de KumbiaPHP el cual es:

get_nombre_accion()

post_nombre_acccion()

Por ejemplo en la clase servicio tendré un método para buscar un artículo, mi método se llama buscarArt y cómo va atender las peticiones get pasara a llamarse get_buscarArt($id) quedando de la siguiente manera:

Como se puede observar el formato de salida es Json, en la siguiente imagen vemos los datos devuelto por la aplicación.

POST

Ahora mi aplicación en el lado del cliente enviara al servidor la información para guardar la nota venta, dicha petición será mediante post.

En este caso como no especifico la acción a guardar KumbiaPHP por default  buscara y ejecutara la acción post.

Ahora para recibir la información que estoy enviando desde el cliente, simplemente invocamos al método $this->param(); el cual contendrá los datos enviados.

Como observamos empiezo por recorrer los artículos enviados en el carrito y posteriormente los datos de la venta.

Al final le regresare prácticamente la misma información al cliente, pero si observamos ahora el id tiene ya un valor, lo que el cliente interpretara que la inserción fue correcta.

Para regresar lo anterior de la imagen: en cada iteración del carrito y conforme guardaba un artículo en base de datos, también lo almacenaba en un array, para los primeros tres datos solo se sobrescribían (esto se puede optimizar)

Original: http://www.kumbiaphp.com/blog/2015/02/03/servicios-rest-con-kumbiaphp/

Después de iniciar con la migración de una aplicación web desarrollada en KumbiaPHP, me topé con algunos problemas en la configuración del servidor, el nuevo hosting es proporcionado por NameCheap.

El error se dio a simple vista, ya que no se visualizaba correctamente, fuera la URL que fuera siempre me mostraba lo mismo. Había algunos controladores que extendían de una clase que valida la sesión, los otros controladores son públicos, por lo que algo estaba mal evidentemente.

Después de realizar algunas pruebas, para ver cómo se estaba procesando la información, me di cuenta que siempre se tomaba como controlador y acción “index/index”

Sin tanto rodeo, el probema es que los servidores de nameCheap no estan configurado para la variable $_SERVER[‘PATH_INFO’] y después de inspeccionar los valores de $_SERVER, el equivalente es $_SERVER[‘ORIG_PATH_INFO‘] por lo tanto en el archivo /default/public/index.php me quedo asi:

$number = isset($_SERVER[‘ORIG_PATH_INFO‘]) ? strlen(urldecode($_SERVER[‘ORIG_PATH_INFO‘])) – 1: 0;
$number += empty($_SERVER[‘QUERY_STRING’])? 0:strlen(urldecode($_SERVER[‘QUERY_STRING’]))+1;
define(‘PUBLIC_PATH’, substr(urldecode($_SERVER[‘REQUEST_URI’]), 0, -$number));

$url = empty($_SERVER[‘ORIG_PATH_INFO‘]) ? ‘/’ : $_SERVER[‘ORIG_PATH_INFO‘];

Y listo volvio a funcionar, si tienes un problema similar, simplemente aplica un

<pre>

<?php var_dump($_SERVER) ?>

</pre>

Para identificar la equivalencia de $_SERVER[‘PATH_INFO’]

NameCheap

Los Partials son fragmentos de vistas que podemos reutilizar, y opcional mente pasar variables para convertirlas en vistas dinámicas y claro indicar si se almacenara en cache y por cuanto tiempo.

En este ejemplo he migrado el código de la tabla que lista los dominios a un partial y también he implementado el código del helpers creado anteriormente.

–

–

El resultado

Para comprender mejor este ejemplo revisa los post:

1. DISEÑO DE LAYOUT PARA HAPPYDOMAIN
2. Relaciones entre modelos con KumbiaPHP
3. Uso de Helpers en KumbiaPHP

KumbiaPHP cuenta con una librería para hacernos más fácil la tarea de implementar la funcionalidad del login y así restringir acceso a ciertas páginas.

En este ejemplo todas las paginas están restringidas, a excepción del login (obvio).

Para entender el sistema de logue repasemos lo siguiente.

Este tutorial es parte de la app http://happydomain.gvn.mx/dominios/index donde ya he implementado el sistema de logueo

Todos los controladores extiendan la funcionalidad de AppController, y esta a su vez de Controller, por lo cual cada petición que realizamos pasa primero por AppController, a provechando esto, en este controlador es donde verificaremos si el usuario esta logueado, de ser así el sistema continua con el flujo normal, de lo contrario re direccionaremos al formulario del login.

Para evitar bucles, el controlador del login NO extenderá de AppController, si no que lo haremos directamente de Controller.

Si lo hacemos de AppController, entonces cada vez que vayamos al login, validara si estamos logueados, algo que es ilógico, y para evitar agregar más validaciones, mejor lo extenderé de Controller directamente.

En el archivo /public/index.php agrega session_start();

/public/index.php

A continuación les dejo el código necesario

Por cierto esta es mi tabla de usuario:

Tabla usuarios

Para quienes quiera iniciarse en el desarrollo de aplicaciones web, les recomiendo ampliamente KumbiaPHP por su sencilles y velocidad en la curva de aprendizaje.

Entonces para inciar vamos les mostrare como configurarlo con nginx, en mi caso estoy con ubuntu 18.04.

Descargar el proyecto

Descomprimirlo en la carpeta del servidor “/var/www/html”

Em mi caso como tengo otros proyectos decidi correr kumbiaPHP en el puerto 91 y crearle su propio archivo de configuración.

Crear el siguiente archivo: /etc/nginx/sities-enabled/kumbiaphp

Es probable que la configuración de PHP difiera de la tuya, en mi caso uso la version PHP-FPM 5.6, Recuerda que KumbiaPHP funciona es compatible con la version 7.X, yo apenas hare esta configuración.

server {
    listen      91;
    root        /var/www/html/kumbiaphp/default/public;
    index       index.php index.html index.htm;

    location / {
	try_files $uri $uri/ /index.php?_url=$uri&$args;
    }	

    location ~ \.php {
	include snippets/fastcgi-php.conf;
	root /var/www/html/kumbiaphp/default;		
	fastcgi_pass unix:/run/php/php5.6-fpm.sock;

       include fastcgi_params;
       fastcgi_split_path_info       ^(.+\.php)(/.+)$;
       fastcgi_param PATH_INFO       $fastcgi_path_info;
       fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;		
    }

    location ~ /\. {
        deny all;
    }
}

Esta configuracion es usando: Usando $_GET['_url']:

Debemos modificar el archivo: kumbiaphp/default/public/index.php y en el comentar $url que hace uso de PATH_INFO y descomentar la que hace uso de $_GET[‘_url’]. para que funcione.

/**
 * Obtiene la url usando PATH_INFO.
 */
 
// $url =  isset($_SERVER['PATH_INFO']) ? $_SERVER['PATH_INFO'] : '/';

/**
 * Obtiene la url usando $_GET['_url']
 * Cambiar también en el .htaccess.
 */
 $url = isset($_GET['_url']) ? $_GET['_url'] : '/';

Y listo con esto tienes corriendo kumbiaPHP

Les dejo un video tutorial sobre como integrar Bootstrap con KumbiaPHP

Ahora veremos como hacer uso de los partials, para una mejor organización de nuestro código.

Hola programadores, les comparto un curso sobre desarrollo web, aun no esta terminado pero les comparto los primeros 7 vídeos, en los cuales muestro lo básico del framework para ir creando nuestro modulo de inventario.

En el transcurso del día subiré mas vídeos, hasta terminar este modulo.

Sus opiniones serán bien venidas!