Warning: Cannot modify header information – headers already sent by (output started at

Trabajando con Php, cuando hacemos un session_start() , o utilizamos un comando header , en ocasiones nos encontramos con errores de este tipo:

Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by (output started at

Warning: Cannot modify header information – headers already sent by (output started at

Estos errores aparecen cuando antes de utilizar estos comandos, se ha realizado alguna escritura desde la página php. Esta escritura, no tiene que realizarse exclusivamente mediante un comando echo o similar. Basta con que la etiqueta de inicio del código php ( <? ), no se encuentre en la primera línea, ya que el servidor web interpreta que debe enviar caracteres en blanco.

Así, para solventar esta incidencia, deberemos verificar que la própiea página que llama al session_start o al header , o cualquier include anterior , no sólo no están lanzando un echo, sinó que no tenga líneas vacías o con contenido fuera de etiquetas php.

Pierdo las variables de Session Php

Ha sido complicado descubrir lo que estaba pasando, ya que era difícil reproducir el comportamiento.
El síntoma: se perdía el contenido de las variables de Session.

El motivo: por un bug de php , cuando se hace una redirección a otra página mediante header(‘location: otraPagina.php’);  las variables de Session que estaban en la página que hace la redirección pierden su valor, con las consecuencias que ello provoca.

La solución: Ignorar las variables de Session, y gestionar éstas, nosotros mismos mediante un fichero por Session, utilizando el session_id() , para almacenar las variables justo antes de la redirección, para cargarlas de nuevo del fichero, una vez que lleguemos a la página de destino de la redirección.

Codificación de caracteres en paginas php

Recientemente he estado desarrollando una web corporativa en Polaco, y me he tenido que romper la cabeza para descubrir porqué los caracteres no aparecían correctamente en el explorador web.

Haciendo 4 búsquedas en internet, rápidamente veo lo que está sucediendo.

Se tiene que añadir el tag <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″> dentro del header de la página html.

Además, cuando se accede a la base de datos mySql, se tiene que acceder al contenido del campo, anteponiendo la siguiente instrucción:

mysql_query(“SET NAMES ‘utf8′”) or die();

El campo que contiene el contenido en idioma polaco, deberá tener como Column Charset = utf8 , y como Column Collate = utf8_polish_ci

Con esto, en el servidor local de desarrollo que corre con Xampp, todo funcionaba Ok.

Pero cuando subía el código al servidor de hosting de PiensaSolutions, el formato del texto no aparecía correctamente. Parece que el servidor, asigna una codificación directamente, por lo que el charset asignado en la cabecera de la página html, es ignorado por el explorador web.

La solución: En la página php, se tiene que añadir el header(‘Content-Type: text/html; charset=UTF-8′);

Protección de código PHP

Cuando utilizamos PHP como entorno de trabajo para nuestros proyectos web, contamos con múltiples ventajas, como son el amplio uso por la comunidad de webmasters, su sencillez, y el barato precio que hay que pagar para adquirir una licencia.
 
Por otra parte, una de las mayores desventajas que presenta, es la vulnerabilidad de la privacidad del código creado.
Como lenguaje interpretado y no compilado, basta con acceder al fichero php para poder ver su contenido, por lo que la propiedad intelectual de nuestro trabajo está totalmente a la vista.
 
Esto nos sitúa en una posición de total dependencia de la honestidad de los administradores de nuestro hosting, ya que pueden acceder y acceden libremente, al contenido de sus servidores, ya que el servicio de hosting es un alquiler de espacio.

Hay varios productos que permiten encryptar mediante una pseudo compilación, el contenido php, como Zend pero para poder utilizarlo, se debe tener instalado en el servidor web, algo imposible si el servicio de hospedaje no permite realizar instalaciones, y únicamente podemos gestionar a partir de un panel de control.
 
Una alternativa es difuminar el código. Lanzar un proceso previo a la subida de los ficheros a un servidor web, que modifique la posición del código, así como el nombre de las variables y funciones, para que lo haga ilegible, pero que el compilador si que lo pueda interpretar. GridinSoft, dispone de un producto de este tipo.
 

Como última alternativa, podemos confiar plenamente en los administradores del servidor web, y que el servidor dónde están almacenados nuestros ficheros, no sufriran un ataque y nos roben nuestro código.