include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setDay(31);
$fecha->setMonth(3);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que el resultado fuera: 31/03/2010

Pero en su lugar mostrará 03/03/2010

Esto es porque al hacer $fecha->setDay(31) el sistema intenta crear la fecha: 31/02/2010 que no existe, por lo que “recorre” los días restantes para quedar en 03/03/2010, al asignar el mes, no tiene efecto.

La solución es simplemente hacerlo en orden inverso:

include_once("Zend/Date.php");
$fecha_febrero = mktime(0, 0, 0, 2, 1, 2010);
$fecha = new Zend_Date($fecha_febrero);
$fecha->setMonth(3);
$fecha->setDay(31);
print "Fecha Marzo: ".date("d/m/Y", $fecha->getTimestamp());

Eso parecería la solución ideal (y es la recomendada por la documentación), pero no es totalmente cierta, si por ejemplo estamos en enero 31 del 2010 e intentamos asignar una fecha de febrero, siempre obtendremos una fecha de marzo:

include_once 'Zend/Date.php';
$fecha_enero = mktime(0, 0, 0, 1, 31, 2010);
$fecha = new Zend_Date($fecha_enero);
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Uno esperaría que mostrara la fecha:
10/02/2010

Pero en realidad muestra
10/03/2010

Esto porque cuando asignamos el mes, el sistema intenta crear la fecha 31/03/2010 que una vez más es incorrecta, por lo que crea la fecha 03/03/2010, pero al asignar la fecha, el resultado es un error en el mes.

Aunque esto no es un error, es muy peligroso porque uno puede suponer que la fecha es correcta porque en el código lo parece, la solución sin embargo es trivial, asignar el primer día de un mes que tenga 31 días y asignar los valores en orden inverso (primero año, luego mes y por último día), así el código sin error sería:

include_once 'Zend/Date.php';
$fecha = new Zend_Date(0, 0, 0, 1, 1, date('Y'));
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Resultado (el esperado)
10/02/2010

Esto funciona en la mayoría de los casos; aunque si van a manejar diferentes zonas horarias mediante setTimezone() el código anterior tendrá el mismo error en los casos que la zona horaria sea menor a la zona horaria del servidor, por lo que hay que hacer algo más elaborado:

include_once 'Zend/Date.php';
$fecha = new Zend_Date();
//eliminar "errores"
$fecha->setTimezone('mi_codigo_zona_horaria');
$fecha->setDay(1);
$fecha->setMonth(1);

//nuestro código
$fecha->setMonth(2);
$fecha->setDay(10);
print "Fecha Febrero: ".date("d/m/Y", $fecha->getTimestamp());

Lo peligroso del comportamiento de Zend_Date es que funcionará con errores durante algunos días/meses dependiendo de la manera en como se programe y es un poco difícil de diagnosticar por su misma naturaleza, con esto se elimina cualquier tipo de errores.

strtotime("+1 days", $time)

y en su lugar utilizar directamente la suma de 86,400 segundos que es un día:

60 * 60 segundos = 3600 segundos (1 hora) * 24 = 86400

El calendario no tenía ningún problema hasta que noté que tenía repetido dos veces el día 1º de noviembre, los tiempos eran los siguientes (tiempo Unix):

1257051600: 2009-11-01 00:00:00
1257138000: 2009-11-01 23:00:00

Si hacen la suma, observarán que se sumó 86,400 segundos a una fecha y otra; pero el tiempo regresado por PHP (de hecho por el sistema Linux) es de 23 horas y no 24 horas.

Hice algunas pruebas en otros servidores y solo uno imprimió la fecha que esperaba (2009-11-02 00:00:00), la primera idea (por el cansancio) fue que era un error de PHP/Linux. Buscando un posible error, encontré algunas preguntas que como yo habían tenido un problema similar, pero mencionaban algo de la zona horaria, eso me recordó que el 1º de Noviembre en México atrasamos el reloj una hora por lo que en realidad el cálculo era correcto desde la perspectiva de Linux ya que estaba olvidando esa “hora perdida” en mis cálculos, el servidor que regresó bien la fecha estaba en otra zona horaria por lo que no compartían nuestro cambio de horario.

El tiempo Unix correcto es: 1257141600 no es otra cosa que es el día (86400) más la hora “perdida” (3600), este tiempo lo obtuve llamando a strtotime en PHP en lugar de calcularlo por mi cuenta.

Moraleja: Manipular el tiempo Unix de forma directa agregando valores puede ser muy rápido y simplifica la implementación, pero si quieres hacer algo que no tenga errores utiliza siempre las funciones de tiempo de PHP/Linux.

USER=root;PASS=mi_pass;for database in `echo "SHOW DATABASES" | mysql --user=$USER --password=$PASS | sed '1d'`; do mysqldump --user=$USER --password=$PASS $database > $database.sql; tar jcvf $database.tar.bz2 $database.sql; rm $database.sql; done

Un poco más leible:

USER=root
PASS=mi_pass
for database in `echo "SHOW DATABASES" | mysql --user=$USER --password=$PASS | sed '1d'`
do
    mysqldump --user=$USER --password=$PASS $database > $database.sql
    tar jcvf $database.tar.bz2 $database.sql
    rm $database.sql
done

Básicamente manda todas las bases de datos y quita la linea inicial (que siempre es Databases) y por cada base de datos invoca mysqldump y por último lo comprime con bunzip2 para obtener un archivo muy pequeño y por supuesto elimina las “fuentes” de sql.

En este directorio el script /etc/init.d/xendomains buscará las configuraciones de las máquinas virtuales a iniciar/detener estos pueden ser vínculos simbólicos a las verdaderas configuraciones.

Para que todo esto suceda en primer lugar debes de tener el script /etc/init.d/xendomains que se instala junto con /etc/init.d/xend

También debes haber habilitado el inicio de este script con el siguiente comando:

update-rc.d xendomains defaults 21 20

 
El script /etc/init.d/xendomains necesita del archivo de configuración: /etc/sysconfig/xendomains

En este verás una línea que contiene:

XENDOMAINS_AUTO=/etc/xen/auto

Con esto definimos el directorio donde se buscarán los dominios que se auto iniciarán

rsync es un comando para hacer réplicas de un directorio a otro lugar, lo que hace es checar el comparar los directorios y copiar todos los archivos que hayan sido modificados, que sean nuevos o incluso que hayan sido elminados para hacer una copia exacta.

La gran ventaja de rsync es que aparte de crear una réplica, es sorprendentemente rápido, en especial con archivos pequeños.

El uso es muy simple:

rsync -az -e ssh FUENTE usuario@servidor:DESTINO

Eso es todo, para que funcione ambos servidores deben tener el programa rsync instalado, FUENTE es el directorio local a copiar (o puede ser un archivo), DESTINO es el directorio del servidor remoto a donde se copiará.

La opción -az envia la información compresa y -e ssh indica que hay que usar el programa ssh para transferir los archivos (con esto se puede enviar también mediante ftp, etc)

Otra opción que uso mucho es --delete, de esta manera rsync también borrará los archivos “extra” para que la copia sea exacta. Hay que tener cuidado, porque en algo descuidado se pueden borrar los archivos locales (inversión de parámetros)… algo que me pasó una vez, pero tenía respaldo =).

Esto significa que linux ya no tiene “lugar” para montar más dispositivos loop (montar tu disco duro virtual o swap), por defecto tienes ochos dispositivos loop permitidos, que son para cuatro máquinas virtuales (debido a que utilizan al menos dos imágnes, una para el swap y otra para el disco duro)

Para aumentar este límite es muy fácil, primero detienes las instancias virtuales de Xen:

/etc/init.d/xendomains stop

Agregas al archivo /etc/modprobe.d/local-loop lo siguiente (o crealo si no existe):

options loop max_loop=64

Después vuelves a cargar el módulo

rmmod loop
modprobe loop

Por último inicias las instancias virtuales

/etc/init.d/xendomains start

Con esto puede tener hasta 32 instancias de Xen sin problemas.

Lamentablemente nos dieron IPs en otra subred, esto puede ocasionar algunos problemas pero aqui está una solución =)

Vamos a suponer que nuestro servidor Xen tiene ip 192.168.1.90 y que nuestras nuevas ips a asignar son 192.168.247.130 y 192.168.247.131, y que el gateway de nuestra máquina anfitrión es 192.168.1.1

Configuración de Xen

Debido a que en mi caso necesitaba rutear los datos entre mi máquina anfitrión (dom0) y mis máquinas virtuales (domU) habilité lo siguiente en xen:

(network-script network-route)
(vif-script vif-route)

Tanto network-script  y vif-script deben ser las únicas configuraciones disponibles (esto es comentar todos los otro network-script y vif-script)

Reiniciamos el servidor Xen:

/etc/init.d/xend restart
/etc/init.d/xendomains restart 

Es muy importante que verifiques si te marca un error, ya que a mi me mandaba un error por un script que no reconocía la interfaz que ibamos a utilizar, así que hice el siguiente cambio en el archivo: /etc/xen/scripts/network-route

dir=$(dirname "$0")

. "$dir/xen-script-common.sh"

evalVariables "$@"

 

#netdev=${netdev:-eth${vifnum}}

netdev=eth0 #definir por defecto la interfaz a utilizar

echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv4/conf/${netdev}/proxy_arp

Básicamente lo que hace el script de Xen es habilitar el ruteo en linux y crear unas reglas de iptables (que tu puedes configurar si quieres personalizar el rendimiento o seguridad de tus máquinas virtuales por medio del anfitrión)

Ya por último debes borrar el puente que hace Xen en la configuración por defecto de bridge (usando el comando brctl)

Configuración de la Imagen

Al crear la imagen. proporciona la IP, el gateway de tu máquina anfitrión (dom0) y la máscara de red correspondiente, en nuestro ejemplo 255.255.0.0, ejemplo:

xen-create-image --hostname=misitio.com --ip=192.168.247.130 --netmask=255.255.0.0 --gateway=192.168.1.1 --passwd

Con esto tus máquinas clientes podrán ser vistas y accesar a internet sin problemas.

Con algo de trabajo y pruebas (y con las buenas herramientas de ServerBeach, que sólo le faltan una vista a la consola para diagnosticar kernel panics) por fin pude instalarlo.

Debian tiene una versión de Xen, pero es la 3.0.3 que para mi gusto es demasiado vieja (se liberó en 2006) y la versión Lenny (testing) tiene la versión 3.2, pero también algo “inestable” a mi gusto para un servidor de batalla.

Como dije después de hacer varias pruebas logré instalar la versión Xen 3.3 utilizando el kernel que viene en Debian preparado para Xen.

Una breve descripción de Xen, es que está separado en varias partes, en primer lugar Xen tiene un kernel modificado para llevar a cabo la virtualización, la ventaja es que la versión 3.3 utiliza la versión 2.6.18 que es la que viene con Debian.

Después la parte “fuerte” de Xen es el denominado hypervisor que es un servidor que se encarga de hacer la virtualización propiamente dicha. Después vienen las máquinas virtuales que utilizan por lo general otro kernel que se denomina domU (y el kernel de la máquina base se denomina dom0).

Pues bien, para lograr esto simplemente primero instalé la imagen del kernel apropiado y compilar solamente el hypervisor de Xen 3.3

En pasos simples:

#Instalar la imagen del kernel con parche para xen
apt-get install linux-image-2.6.18-6-xen-amd64

#Descargar el código fuente de xen
wget http://bits.xensource.com/oss-xen/release/3.3.0/xen-3.3.0.tar.gz
tar zxvf xen-3.3.0.tar.gz
cd xen-3.3.0

#Compilar solamente el hypervisor
make xen
make install-xen

#Compilar los archivos ejecutables como xm y herramientas de red
make tools
make install-tools

#Hacer que Debian cree las entradas correspondientes en los rc.X
#para que cuando el servidor se inicie ejecute los servidores de Xen
update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20

#Hacer que grub reconozca el nuevo kernel con la configuración de Xen 3.3.0
update-grub

Con eso deberían de ver una entrada en el grub como:

title           Xen 3.3.0 / Debian GNU/Linux, kernel 2.6.18-6-xen-amd64
root            (hd0,0)
kernel          /xen-3.3.0.gz
module          /vmlinuz-2.6.18-6-xen-amd64 root=/dev/sda6 ro console=tty0
module          /initrd.img-2.6.18-6-xen-amd64
savedefault

Que debería de bootear con el hypervisor 3.3

Incluyo algunas ligas de sitios (en inglés) que me ayudaron muchísimo para entender algo más de Xen

• http://www.howtoforge.com/debian_etch_xen_3.1_p5 (muy buen documento)
• http://27smiles.com/2008/08/08/setting-up-xen-on-debian-etch-64bit/ (para instalar Xen con las versiones estables de Debian)
• http://www.nabble.com/Xen-3.3-install-from-source-on-centos-5.2-td19761354.html (Otra versión de como compilar Xen, incluye copiar la configuración actual, en el ejemplo de CentOS pero puede ser de Debian, algo que no solucionó mi problema, pero es buena idea)
• http://xen-tools.org/software/xen-tools/releases.html (Herramientas de ayuda para Xen, descárguenla, ya que la versión estable de Debian es vieja y no necesita muchas cosas, si les pide algo chequen la primera liga)

Estoy algo divergente entre si es una buena opción o no

Buena opción:

• El Framework está muy bien hecho como para que valga una certificación
• Tiene tantos componentes que es una buena medida para destacar entre los que han utilizado solamente brevemente el Framework

Mala opción

• Cuesta más que la certificación en PHP ($160 dolares en contra de $125 para la certificación de PHP)
• Lamentablemente la certificación es en la versión 1.5 y la versión estable es la versión 1.6, si bien la versión 1.5 ya tenía muy estandarizado el modelo del Framework, a menos que tengan un periodo largo de liberar versiones (lo cual puede ser malo ya que ahora hay mucho movimiento) en menos de un año seguramente saldran al menos un par de versiones por lo que ¿se va a certificar en cada version? =P

Todo parecía ser un simple problema con la importación de MySQL por los acentos, aunque eso solucionó parcialmente aún tenía un error en la parte medular del sistema, en cuanto abri el archivo que estaba dando el error me arrepentí de hacerlo y mi mente se volcó a recordar hace cinco años o tal vez seis cuando se programaba de esa manera =)

Con ese ejemplo me vino a la mente una frase célebre de mi buen amigo Nexus en esas épocas cuando estaba aprendiendo a programar en PHP, mi geek interno terco siguió programando con las antiquísimas $HTTP_POST_VARS a pesar de que se habían desalentado utilizar esas variables y se reemplazó por las variables tipo: $_POST ó $_GET

Recuerdo que cuando Nexus vio un código mio que tenía el $HTTP_POST_VARS me dijo en un chat con (me parece Carlos Cortez): “Programas a la manera viejita jajajaja”. Claro por orgullo después de eso nunca volví a tocar $HTTP_POST_VARS

Aqui tengo unos consejos para que no solamente sea fácil programar, depurar y para otros leer tu código. También para evitar que PHP siga siendo visto como un lenguaje de “bajo presupuesto” (por aquello que muchos prefieren Java por lo ‘empresarial’)

Tip: PHP dejó de ser un lenguaje de Script hace años

Lo digo en completo tono sarcástico, si bien PHP no se puede compilar no hay razón para meter todo dentro de un solo archivo como print’s con funciones, prácticamente se debe separar de preferencia en un modelo MVC si no puedes hacerlo, entonces al menos hazlo en VE (Vista-Espaguetti donde vas a meter tanto modelo como controlador)

Tip: register_globals está muerto

Por eso me dio miedo abrir el archivo, necesitaba register_globals. Para el que no sepa que es register_globals es simplemente que cuando mandamos parámetros a un script como por ejemplo: prueba.php?variable1=hola&variable2=mundo PHP convierte automáticamente esas dos variables en $variable1 y $variable2 con su respectivo contenido.

Qué fácil, ¿No?. Pues en realidad no, cuando el mundo no se percataba del error fatal de hacer esto, parecía que PHP era tan fácil de programar, vaya no necesitabas ni siquiera  vincular los parámetros.

Poco después un balde de agua fria cayó sobre todos nosotros… el problema es que cualquier tipo con algo de sesos puede simplemente pasar variables y asignar valores de la aplicación. En el caso de una aplicación que no inicializara las variables (el 99% para ser sinceros) podía sufrir porque era fácilmente “hackeada” sin necesidad de hacer mucho.

Por eso rápidamente se eliminó register_globals y se dejó como un parámetro opcional, pero muy opcional. Tanto que en PHP 6 va a desaparecer definitivamente. 

register_globals no ayuda, no hace más rápido el desarrollo; simplemente destruye todo lo bueno que podría tener una aplicación, porque en primer lugar es difícil saber cuales variables son parámetros del usuario y cuales son variables internas. También hace fácil explotar un sistema (creo que ya lo había dicho ).

La solución para esto… reescribe tu aplicación.

Tip: die() está muerto

¿Alguien se ha preguntado porqué existe esta construcción del lenguaje de PHP?, supongo que es un legado de los viejos días cuando PHP era un lenguaje de script.

die() permite simplemente eso: hace que el script muera. Muchos lo hacían para verificar una situación intolerable como al abrir una conexión a una base de datos y que no se pudiera conectar; como no se pueden mostrar datos entonces simplemente le decimos al usuario: “perdon pero aqui nos detenemos” un ejemplo es el siguiente:

<?php
    mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

¿Cuál es el problema?, muy simple la función die funciona tan perfectamente que el script se muere ahi. Por lo que el usuario simplemente verá una pantalla blanca con un texto críptico. En el peor de los casos mostrará una parte de la página y la “cortará” donde se haya ejecutado esta instrucción.

No seas perezoso, utiliza construcciones de if() para separar bloques de instrucciones en vez de suicidarte.
Si aún así quieres hacer un die() o un exit() al menos manda a llamar a una plantilla especial que muestre el error con la mayor parte del mismo estilo de la página que vas a mostrar, te lo agradecerá el usuario.

Tip: include y require es un arma de dos filos

También un legado de aquellos días es que un script luzca como:

<?php include 'cabecera.php'; ?>
<?php print "Hola mundo 'plantilla'; ?>
<?php include 'pie_pagina.php'; ?>

En aquellos días estas eran nuestras plantillas, cabecera.php mostraba el código inicial de HTML y pie_pagina.php cerraba ese código HTML, qué facil, ¿verdad?

Pues no, el problema de este método es que en primer lugar las variables son globales y compartidas, por lo que si haces el código espaguetti anterior es un total NO.

Por ejemplo es fácil sobreescribir variables dentro de un archivo “plantilla” y el error se propaga a las otras “plantillas”.

Otro problema es que hacen difícil seguir un flujo real de plantillas (si no quieres una parte tienes que reescribir todo en lugar de simplemente cambiar por ejemplo la distribución de los objetos en una plantilla general. También es fácil de romper todo el HTML por una etiqueta fuera de lugar

Una vez más, no seas perezoso y utiliza un manejador de plantillas como Smarty

Ahora bien del lado de programación un include() por lo regular es utilizado para incluir pedazos de código tales como funciones, clases, etc. Pero lamentablemente también es utilizado para incluir pedazos de código que tienen el mismo uso que funciones!!

Eso es algo totalmente prohibido, no se porque no utilizas funciones o mejor aún una clase.

Tip: mysql_connect y sus vicios

Un legado también de aquellos días es que se programaba de la siguiente manera:

<?php
include 'configuracion_db.php';
mysql_connect($host, $usuario, $password) or die('No pude conectarme a la base de datos');
?>

donde configuracion_db.php era simplemente:

<?php 
$host = 'localhost';
$usuario = 'mi_usuario';
$password = 'mi_password';
?> 

El primero se incluia prácticamente como cabecera para todas las páginas porque necesitaban acceso a la base de datos, y también se incluia dentro de otros bloques dentro de la misma página.

O peor aún, incluir en cada archivo los parámetros de configuración. Esto último es simplemente un caos y es no saber programar, así que toma un curso de programacion básica en otro lenguaje antes de programar en PHP

Para el primer caso si bien es válido, es simplemente malo debido a que otro script puede fácilmente sobreescribir esas variables (o el mismo script por error). Aunque es utilizado, es muchísimo mejor utilizar un patron de diseño llamado: Singleton

El Singleton es un patron de diseño muy simple, en términos de orientación a objetos es un método estático de una clase que regresa siempre la misma instancia de la clase. Es decir solamente existirá un objeto en todo el sistema y que lo creará ese método estático normalmente llamado: obtenerInstancia()

En lenguaje de funciones es simplemente una función que regresará la misma variable (tendrá la misma dirección de memoria) cada vez que se llame, así que en lugar de hacer el primer ejemplo utiliza este:

<?php
function obtenerConectorMysql() {
     static $conector_mysql = null; 
     if ($conector_mysql == null) {
         //aqui insertar las instrucciones para obtener el host, usuario y password, 
         // por ejemplo de un archivo o simplemente escribirlas aqui
         $conector _mysql = mysql_connect($host, $usuario, $password);
     } 

     return $conector_mysql;
}

Esto simplemente crea la primera vez que se llame el conector_mysql, después simplemente lo regresa por lo que no se crean diferentes instancias, es la misma conexión a MySQL

Si lo quieres hacer mediante clases, puedes utilizarlo algo similar como una llamada a una función estática o “envolverlo” en la clase que tengas para manejar la base de datos.

Tip: La seguridad no es para sitios de comercio o bancos solamente

Mucha gente piensa que debe hacer “seguro” un sitio solamente si va a tener operaciones monetarias. Nada más fuera de la realidad. 

Todos los sitios necesitan seguridad para evitar que los ataques logren su resultado: hacer “explotar” la aplicación.

Evitando los errores más comunes tendrás una aplicación que si bien no es tan segura como la de la CIA (lease con sarcasmo) evitará el 90% de los ataques comunes.

1. Al desarrollar una aplicación, recuerda que el usuario no es de fiar, por lo que todo lo que provenga del usuario puede ser alterado
2. Siempre verifica la información que el usuario envió mediante parámetros. Si es posible restringe mediante un arreglo de valores válidos, si no es posible entonces haz muchas verificaciones, por ejemplo en el caso de un archivo, elimina caracteres peligrosos como: ‘..’ o ‘/’ que pueden hacer que el sistema lea (o incluso escriba) un archivo muy diferente al planeado.
   Esto se hace indispensable si vas a utilizar una función poderosa como include() o acceso al archivo (como fopen() )
3. Nunca pongas datos importantes en una cookie, utiliza sesiones. Si lees datos de una cookie nunca asumas que por ser cookie es dificil de alterar
   Si los datos van a “perdurar” más alla de una sesión, entonces deja en la cookie un identificador único y guárdalo en la base de datos, de esta manera el usuario solo debe proveer su identificador y no otra información que pudiera ser alterada. 
4. Siempre “escapa” las variables que vas a utilizar en una consulta a la base de datos, utiliza funciones como: mysql_escape_string(), si utilizas un framework la mayoría de ellos tienen una función para hacer esto (que terminan llamando a algo similar a la primera función)

Tip: PHP5 no es una opción, es obligatorio >=)

No veas a PHP5 como una “extensión” o una versión más. El propósito de PHP5 es hacer una transición entre el mundo de scripts de código espaguetti a un sistema de clases muy bien separadas.

Aunque PHP5 aún permite programar sin clases y con solo funciones; si tienes la oportunidad no dudes en utilizar PHP5 con clases con todo lo nuevo que trae. La guia de estudio de Certificación Zend es un buen inicio. 

PHP5 tiene un gran potencial y está esperando para ser plenamente utilizado, algunos frameworks ya están utilizando plenamente su potencial, entre ellos Zend Framework que es altamente recomendable.

Último tip: MVC es lo único para web

Si vas a desarrollar una aplicación en PHP que contenga todo lo que una aplicación web contiene (contenido en HTML, bases de datos, procesamiento, etc) simplemente utiliza un framework que tenga un diseño de MVC; los más conocidos son Zend Framework (mi recomendación nuevamente) y CakePHP, también están otros en rápido ascenso como Simfony y Code Igniter

También son de uso popular los CMS como drupal y joomla/mambo, aunque ellos no proveen directamente el modelo MVC si proveen el modelo Vista-Espaguetti por lo que con un poco de trabajo extra puedes lograr algo similar a MVC

En resumen PHP es un lenguaje muy poderoso y con historia; por lo que es fácilmente quedarse con las primeras formas de programar, pero con todos los nuevos desarrollos ahora si se puede empezar a hablar de un PHP a nivel empresarial (ya formalmente )