Blogs

backups with screen and ncftp

Do you have a BIG database (or databases) in your server as a result of months and years of working? It use to be a hell to download the sql right? One solution is to get a backup ftp in your hosting provider. They are cheap, and the are going to save you a lot of time.

The trick, do the mysql backup maintenance things. Then, it's time to download your ENORMOUS .sql, but not directly to your computer.

First install screen, a usefull app to launch any console script or commad, and be able to let running while even you close your local computer.

Secondly, install ncftp, a wonderful ftp client (i love it).

And, lastly, some magic. Execute:

 

  1. screen
  2. put the file on the  ftp: ncftpput -v -R -u USER -p PASS FTPHOST [DIRECTORYWHERECOPY] [FILE(S)TOCOPY]

 

If file is too big, you can close your terminal with [CONTROL]A+D keys. But, we'll speak in another post about screen.

categorias: 

Drupal slow when saving nodes (content, comments, admin ...)

Drupal slow when saving nodes (content, comments, admin ...)? Maybe the problem is really simple, try to deactivate some modules that you don't use. It is common to test modules that you finally don't use in your production server. Search for them and deactivate, they take a lot of memory, even if you think you are not using them.

 

 

 

varnish in Drupal howto

Installing Varnish is really simple and easy to perform, and is very unlikely to give you problems with your server that any other more complex methods could give you, like using light servers or so. Probably you cannot compare both performances, but to start improving you Drupal server is a good point from where start.

Let's go:

1. Install Varnish. In Ubuntu / Debian is as easy as:

sudo apt-get install varnish

2. Install Varnish module in your Drupal:

http://drupal.org/project/varnish

Be sure not to make the START=no mistake.

3. Start your Varnish server: sudo /etc/init.d/varnish start

Go to admin/settings/varnish in your Drupal and select enabled.

4. Copy the Varnish Control Key which you´ll find in /etc/varnish/secret (you'll need to be root or read with "sudo vim /etc/varnish/secret").

5. Enjoy :-)

Varnish error: Not starting HTTP accelerator varnishd

Tipical mistake installing varnish accelerator:

* Not starting HTTP accelerator varnishd

Solution? so simple, edit /etc/default/varnish and look for the line:

START=no

change to

START=yes

and restart:

* Starting HTTP accelerator varnishd 

Nice :-)

 

 

Buscar un fichero (recursivamente) en linux / *ix

seguro que más de una vez os habéis encontrado con este "problema". La solución, muy fácil, aunque seguro que usando el camino que probablemente habíais escogido no.

Olvida ls, para este problema necesitas la potencia de find:

find . -name 'nombreFichero.extension'

ejemplo:

find . -name 'fichero.php'

o bien, con "wildcards"

find . -name '*.php'

De nada ;-)

categorias: 

eliminar una fila en una base de datos

 

DELETE FROM `bbdd`.`table` WHERE `crucero`.`agencia` = "AGENCIA";

 

categorias: 

Crear una nueva tabla en una base de datos con Symfony2

 

Añadimos una nueva entidad en CruiseHunter/CrucerosBundle/Entity/Naviera.php

actualizamos los datos:

- php app/console doctrine:generate:entities CruiseHunter/CrucerosBundle/Entity/Naviera

 

- php app/console doctrine:generate:entities CruiseHunter/CrucerosBundle/Entity/Naviera

 

Cuidado. si creamos el fichero en minúsculas, al hacer el doctrine:generate nos va a generar uno en mayúsculas, y nos dará el dichoso error de que no se puede crear dos veces una clase con el mismo nombre.

Más datos importantes, la cabecera con ORM es importante para generar la tabla automáticamente en nuestra base de datos:

 

/**

 * CruiseHunter\CrucerosBundle\Entity\Naviera

 * @ORM\Table(name="naviera")

 * @ORM\Entity

 */

class Naviera

{

 

 

y, por último, debemos tener una variable key, tipo id:

 

    /**

     * @ORM\Id

     * @ORM\Column(type="integer")

     * @ORM\GeneratedValue(strategy="AUTO")

     */

    private $id;

 

 

Hasta aquí todo. Sólo nos queda generar la base de datos:

 

- php app/console doctrine:schema:update --force

Esto último lo que hace es revisar nuestro Entity, y comprobar que campos llevan un @ORM con un \Column asociado. Justamente este campo es el que el comando update usará para crear el campo en la base de datos. 

Por ejemplo:

 

    /**

     * @var string $descripcion

     * @ORM\Column(type="string",length=200)

     * 

     */

    private $descripcion;

    /**

     * @var string $barco

     * @ORM\Column(type="string",length=100)

     */

    private $barco;

    /**

     * @var string $enlace

     * @ORM\Column(type="string",length=200)

     */

    private $enlace;

 

Symfony2: warning open_basedir restriction in effect

Error al subir una aplicación al sevidor en el que va a estar en producción:

symfony ErrorException: Warning: file_exists(): open_basedir restriction in effect

Después de estrujarme mucho los sesos, hize un

rm -rf app/cache/* 

y "evoilá" :-).

Después pueden salir algunos errores como:

UnexpectedValueException: The stream or file "/var/www/vhosts/*/app/logs/prod.log" could not be opened; it may be invalid or not writable.

lo que simplemente se arregla corrigiendo con los permisos adecuados los directorios que nos indique el propio mensaje, en este caso el directorio de logs:

chmod a+rw -R logs/

 

Drupal: rendimiento

Drupal es fantástico, es rápido levantar una aplicación con él, es muy muy flexible... casi como un framework de programación en si mismo... Quien diga que no se puede hacer algo en Drupal es simplemente porque no conoce la herramienta o porque no sabe programar sobre ella.

El problema? Es muy pesado... Esta es la única razón por la que algunos proyectos los estoy haciendo en Symfony :-(.

Se que se puede optimizar, montar un proxy cache, tirar de servidores ligeros como httplight, cherokee, ... pero si aplicas esos conocimientos sobre un script o un framework de programación puro, obviamente la aplicación irá mucho más rápida, será mucho "menos pesada" que la montada sobre Drupal.

En general, si puedes elegir, tienes presupuesto y recursos y el proyecto es "grande", atacalo con Symfony, Cakephp, RubyonRails (fantástico), ... En caso contrario, Drupal me ha salvado la vida en muchas ocasiones :-).

Hace unos años, allá por mis últimos años de universidad, un profesor al que aprecio estaba trabajando sobre un proyecto en el que trataban de realizar mediciones tan exactas como el tiempo que tarda en cargarse una etiqueta html, una img, .... sensible? Lo siguiente.

Con windows aquello era un baile, mediciones que debían ser de milisegundos variaban dependiendo de cuando las lanzaras hasta en segundos... solución? Me puse manos a la obra, instalamos una distribución de Linux con un kernel compilado a medida sin a penas módulos... y volvió a realizar las mediciones.

Windows tiene mucha "basura" corriendo en segundo plano. Cosas que usas a diario, otras no tan a diario... Ojalá Drupal fuera como Linux :-(.

Drupal: available variables in a concrete place, web, ...

Tipycal scenario. Imagine you need to know which variables yo need in a concret place of your site, say /blog, a node or a view. Very easy, simple add a block, for example at your foot if available in your theme, with php input availabe, and this code:

<?php  print '<pre>';  var_dump(get_defined_vars());  print '</pre>';?>

Now, make it only available for your role, for example, and place it where you prefer (foot for example).