Category: Programación

Algo a probar cuando PHPmailer no funciona

Intentando configurar el envío de correos mediante PHPmailer la conexión se establecía pero no hacía nada más, fallando un tiempo después.

Al cambiar el tipo de seguridad de tls por ssl ha funcionado perfectamente.

No tengo ni idea de por qué, supongo que debe ser algo propio de cada servidor de correo, pero si alguna vez te encuentras con un error y ya has verificado que todos los datos de puertos, contraseñas, etc. están bien prueba, a ver si te lo resuelve.

Solucionar error “the input device is not a TTY” al ejecutar comandos desde PHP

Al ejecutar desde PHP un comando que requiere una terminal nos encontraremos este error. Una forma de solucionarlo (¡gracias ChatGPT!) es utilizar el comando script:

script -q -c 'comando_a_ejecutar' /dev/null

-q es el modo silencioso y para evitar que se redirija la salida a un fichero usamos el /dev/null final.

Error en orden de carga de extensiones al usar OpenSwoole en PHP

Si al instalar la extensión de PECL OpenSwoole nos aparece este error:

PHP Warning: PHP Startup: Unable to load dynamic library 'openswoole.so' (tried: /usr/lib/php/20230831/openswoole.so (/usr/lib/php/20230831/openswoole.so: undefined symbol: socket_ce)) in Unknown on line 0

es porque hemos añadido la línea extension=openswoole.so en el fichero php.ini, y esto hace que intente cargar la extensión de OpenSwoole antes de tener cargadas otras de las que depende (como sockets o curl, dependiendo de las opciones que hayamos indicado al instalar OpenSwoole).

La solución es quitar esa línea del fichero php.ini, y llevárnosla como un fichero a la carpeta conf.d, por ejemplo /etc/php/8.3/cli/conf.d/30-openswoole.ini.

Aquí la clave es que ese número inicial (30 en este ejemplo) sea superior al que tienen los ficheros que cargan las extensiones necesarias (en mi caso eran 20-curl.ini y 20-sockets.ini).

Axios: Quitar cabecera “Content-Type” en subidas multipart a S3

Cuando tenemos que subir ficheros grandes a S3 en varias partes las peticiones PUT no deben llevar la cabecera “Content-Type”, pero Axios la pone por defecto y esto genera un error 403.

Para que Axios no añada esta cabecera hay que indicarlo expresamente usando el valor false:

headers: { "Content-Type": false }

Usar un paquete de Composer de forma local

Para probar con código PHP que irá en el futuro en un paquete de Composer podemos incluirlo en nuestra aplicación de esta forma:

  • Creamos un repositorio de Github para el paquete (esto es obligatorio para poderlo subir a Packagist).
  • Supongamos que nuestro paquete se llama karontek/bcons y que el repositorio está en /home/koas/bcons. En el fichero composer.json de la aplicación donde queramos usar ese paquete añadiremos:
"repositories": [
  {
    "type": "path",
    "url": "/home/koas/bcons"
  }
]

"require": {
  "karontek/bcons": "dev-main"
}

Virtualhost de Apache para SPA de Vue y API con PHP

<VirtualHost *:9080>
    # Vue.js Single Page Application
    DocumentRoot /var/www/app/dist
    <Directory "/var/www/app/dist">
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted

        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.html [L]
    </Directory>

    # PHP API
    Alias "/api" "/var/www/app/api"
    <Directory "/var/www/app/api">
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^ index.php [L]
    </Directory>
</VirtualHost>

En un caso como este todas las peticiones a la API van a dominio.com/api/XXXXX

Usar nginx como proxy durante el desarrollo de aplicaciones con Vue

Estoy desarrollando bcons y el entorno de desarrollo de la aplicación web es el típico de Vue3 con Vite que abre un puerto para poderse conectar y que haga el refresco automático etc. En mi caso accedía con esta URL: http://bcons.local:4321

Pues bien, la API se ejecuta desde http://bcons.local/api y me estaba volviendo loco porque no había forma de crear las cookies desde el PHP de la API. Aunque en teoría el puerto no afecta a las cookies no conseguía que el navegador creara la cookie.

La solución es configurar nginx para que las peticiones al puerto 80 se redirijan al puerto 4321 que es donde Vite está sirviendo la app. Así quedaría el bloque de configuración (incluyendo la regla para que las peticiones a las API se ejecuten correctamente):

upstream devapp {
    server bcons.local:4321;
}

server {
  listen 80;
  listen [::]:80;
  proxy_hide_header X-Frame-Options;

  server_name bcons.local www.bcons.local;
  root /home/koas/Server/htdocs/bcons;
  index index.php index.html;

  location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
  }

  location /api/ {
     try_files $uri $uri/ /api/index.php?$query_string;
  }

  location / {
    proxy_pass http://devapp;
  }
}

Ahora accedo a la app de desarrollo a través de http://bcons.local (sin necesidad de especificar el puerto) y la cookie se crea sin problema.