Cómo desarrollar un sitio drupal en un server local o en un server de testing antes de publicarlo

(Los nombres reales de los sitios han sido cambiados)

Instalé drupal en elephantboarding.com, y está bajo control de versión.

Me actualicé en landonwinters.com/elephantboarding después de haber cometido la installation en megafishoil.com.

Pero landonwinters.com/elephantboarding se ve raro, como si no tuviera el tema pnetworkingeterminado configurado correctamente, no tiene tema. Sin embargo, tiene un lugar para iniciar session, y dice www.elephantboarding.com en la parte superior.

Supongo que tiene algo que ver con la database … pero sería genial si Landonwinters.com/elephantboarding fuera un espejo de megafishoil.com, y si pudiera hacer cambios en landonwinters.com/elephantboarding sin ver esos cambios en elephantboarding.com hasta que me svn actualizado.

Perdón por newbness, y gracias de antemano por cualquier ayuda!

Ah, y tengo un server local, aunque no sé cómo svn checkout a mi propia computadora …

Sí, es posible: ejecuto un sitio de drupal en http://www.blah.net y uno de desarrollo / testing en http://dev.blah.net . Ambos usan el mismo código, revisado de un repository de svn compartido, y ambos usan la misma database.

Esto funciona bien para mí, basado en las siguientes condiciones:

La línea de su settings.php que define $ base_url necesita ser comentada.

La línea que define $ cookie_domain necesita ser reemplazada por una condicional en el nombre del server, para evitar que inicios de session se vuelvan locos:

if(preg_match('/dev/i', $_SERVER['SERVER_NAME'])) { $cookie_domain = 'dev.blah.net'; } else { $cookie_domain = 'www.blah.net'; } 

Aunque todo esto está bien para mí, es porque mis routes se correlacionan exactamente de la misma manera (las aplicaciones drupal se ubican ambas en la raíz del dominio). Originalmente tenía http://www.blah.net/dev, pero eso se rompió porque los paths ya no funcionan.

Soo, la solución es asegurarse de que las routes se mapeen. ¿Es posible que tenga suficiente acceso para implementar Apache VirtualHost en el sitio que desea probar? De ser así, puede agregar una input de host virtual como esta:

 <VirtualHost dev.blah.net:80> ServerName dev.blah.net ServerAlias blah.net DirectoryIndex index.php #change this to the path to the drupal install DocumentRoot /www/htdocs/ <Directory "/www/htdocs"> ## Allow CGI and Symbolic Links Options +FollowSymLinks +ExecCGI # NOTE - The FileInfo override allows rewrites to work in htaccess files AllowOverride All Order allow,deny Allow from all </Directory> </VirtualHost> 

Otra nota es que si bien puede mantener templates separadas y files físicos sin ningún problema, si cambia la configuration a través del panel de administración, esa configuration se almacena en la database, por lo que tendrá efecto en todas las instalaciones que comparten la database. Los bloques son un ejemplo típico de este problema, ya que están almacenados en la database.

Básicamente no puedes tener dos sets diferentes de mapeos de ruta para drupal (sin embargo, es posible que puedas hacer algunas reescrituras de apache locas, pero eso sería muy complicado). La respuesta de virtualhost es probablemente la solución less dolorosa, siempre que tenga suficiente acceso.

Tuve un problema similar después de copyr una installation de Drupal, incluida la database.

En cuanto al tema, si utilizó el module de color, entonces el file debe ser recreado en su nueva installation.

Simplemente vaya a la página de configuration del tema, asegúrese de que los colors sean los que desee, click Guardar configuration y Drupal creará el file correcto para los colors, y el tema pasará de ser completamente perdido a funcionar perfectamente bien.