Añadirlos es muy fácil.

Conlleva solo dos pasos, estos:

1. Crea el archivo que contiene las nuevas Quicktags

Crea donde quieras un fichero, que puedes denominar quicktags.js, y en el añade líneas cómo la siguiente por cada una de las quicktags que puedas querer utilizar actualmente o en un futuro.

edButtons[edButtons.length] = new edButton( 'id', 'Nombre del botón', '[mishortcode]', '[/mishortcode]', 'h', '-1');

La explicación del código, para que puedas personalizarlo sería este:

• id define que se cree un identificador único para el nuevo botón
• Nombre del botón es el texto que aparecerá en el botón
• Lo siguiente es la tag HTML que añadirá tu botón, en el ejemplo un shortcode, con el formato de apertura y el de cierre.
• h especifica una combinación de teclas de acceso rápido, en este caso sería Control+Alt+h
• -1 define si el botón puede cerrarse o no

Una vez añadidas tantas líneas cómo botones puedas querer utilizar algún día guarda los cambios.

2. Crea la función para añadir quicktags

En tu plugin personal o archivo functions.php de tu tema activo añade algo así:

//Añadir quicktag
function mi_quicktag() {
	wp_enqueue_script( 'mishortcode', 'http://misitio.es/quicktags.js', array( 'quicktags' ) );
}

add_action( 'admin_print_scripts', 'mi_quicktag' );

Y vuelves a guardar los cambios.

Cómo podrás comprobar en el código lo verdaderamente relevante es definir claramente en la tercera línea el código al que llama y la ubicación del archivo donde están las quicktags.

fuente: ayudawordpress

MotoPress es un plugin que cambia el modo en que interactúas con WordPress, del todo.

Una vez instalado permite añadir, crear, modificar y mover bloques de contenido de WordPress arrastrando y soltando. No solo puedes añadir, modificar o duplicar una plantilla de contenido sino que puedes cambiar totalmente el aspecto de la web moviendo bloques, mostrar u ocultar partes de la web, manipular widgets y muchísimo más.

Para entender lo que hace y cómo lo hace, revisando la documentación del plugin incorpora nuevos bloques al diseño, que a partir de su instalación se hacen manipulables a voluntad, y ahí está la magia.

Prueba por ti mismo los beneficios de este excelente plugin, aquí te lo dejo

fuente: ayudawordpress.com

Me dirás que una instalación de WordPress puede verse comprometida por culpa de plugins, pero esa es otra cuestión, que además ya hemos tratado hace tiempo.

Recientemente hemos visto historias acerca de un bot que trataba de hacer ataques de fuerza bruta en sitios WordPress, pero debes tener claro que no podía entrar en sitios donde el usuario tenía contraseñas fuertes, tenían la última versión de WordPress y estaban comprometidos con la seguridad de todos los componentes de su instalación.

Pero cómo hay mucho escéptico, lo que no es malo de suyo, vamos a ver si terminamos de aclarar algunas cosas.

Críticas “amistosas”

Durante el verano de 2009 WordPress recibió algunos “toques” de la comunidad de publicación online, debido a cuestiones de seguridad explotadas esos días. Lo que pasaba es que WordPress estaba creciendo enormemente, y recibió algunas críticas, bien y mal intencionadas, que hubo de todo, cuestionando si WordPress era lo suficientemente seguro para los usuarios a los que atraía de manera importante.

Por decirlo de algún modo, lo que se decía era algo así:

“Eh, WordPress, sabemos que eres ambicioso, y eso nos encanta, pero debes asegurar que tu seguridad es a prueba de balas para los usuarios antes de ser tan popular”

Curioso ¿no?, sobre todo cuando en parte venía de usuarios de comunidades de software de publicación con problemas de seguridad sin solucionar hacía años, pero bueno, vamos al tema.

Los desarrolladores del núcleo de WordPress respondieron, y en los siguientes meses se añadieron parches y ajustes de seguridad para afianzar fuera de toda duda que WordPress es uno de los CMS más seguros de Internet. Eso fue hace cuatro años, una eternidad en términos de innovación tecnológica.

El verano de 2009

En unas pocas semanas, en 2009, el equipo del núcleo de WordPress lanzó una serie de 4 parches de seguridad. El equipo cerró de manera rápida y sistemática cualquier factor remanente de inseguridad en el núcleo de WordPress. A finales de ese verano el código base de WordPress empezaba a parecer Fort Knox.

Sin embargo, si tenías alguna instalación en marcha de WordPress en esa época,tuviste que actualizar WordPress bastante a menudo, cada vez que se lanzaba un nuevo parche de seguridad. En total se emitieron seis versiones de WordPress, desde la 2.8.1 el 19 de Julio hasta la 2.8.6 antes de Navidad. Ciertamente fueron un buen montón de actualizaciones. ¿Te acuerdas?

Vale que actualizar WordPress no es difícil, pero actualizaciones cada pocas semanas se hacía pesado. Cada nueva actualización de seguridad implica comprobar compatibilidad de plugins y temas antes de lanzarse, y eso duele a veces. Y lo mismo en cada nueva actualización. Ahora bien, cualquier software solo es seguro en su última versión, así que hay que actualizar siempre a la última versión publicada, que no se te olvide.

Pero vaya, que tener que revisar todo, cada 2 o 3 semanas, en cada sitio que tengas, se hace cansino, y esto no nos tenía contentos, cómo se reconocía en muchos comentarios del blog, y con razón.

En solo 34 días hubo nada menos que 4 actualizaciones de seguridad para WordPress 2.8, y te recuerdo que esto era antes de que tuviésemos herramientas de gestión que nos facilitaran las instalaciones, así que todas las actualizaciones eran manuales.

Vamos, que era un puto infierno y un coñazo.

Y lo peor es que muchos usuarios no actualizaban … y algunos de los sitios de esos usuarios fueron hackeados al funcionar con versiones de WordPress anticuadas (y hablamos solo de unas semanas), lo que nos trae de nuevo la necesidad de tener WordPress actualizado. Así que grábatelo a fuego:

Si estás actualizado estás seguro

Si no estás actualizado eres un objetivo.

El hacking es noticia

En 2009 hubo muchas instalaciones de WordPress, cada vez más, y con toda esta retahíla de actualizaciones fuimos noticia. Hubo una buena cantidad de blogueros e incluso diarios digitales generalistas que ese año hablaron, y mucho, acerca de “los problemas de seguridad de WordPress“, y esto ha quedado en la memoria colectiva de Internet, a pesar de que 4 años en la red es una eternidad en términos de software, pero no es así con la mente humana.

Ahora, cuatro años después, aún no es posible tener un debate sobre WordPress sin que alguien te suelte eso de “Eh, espera ¿es WordPress inseguro?“.

De repente, WordPress tenía una reputación, merecida o no, de ser una plataforma que tenía que estar actualizándose constantemente, y que podría no ser lo suficientemente segura.

La realidad es que ya a finales de 2009 WordPress se había convertido en una plataforma segura y sin problemas para los millones de usuarios que la usábamos, lo mismo para sitios de alto tráfico cómo The New York Times.

La popularidad de WordPress se hacía patente en la ingente cantidad de grandes empresas y organizaciones que migraban a WordPress.

Responsabilidad compartida de los usuarios de WordPress

Los usuarios de WordPress debemos ser responsables de nuestra propia seguridad, de usar contraseñas fuertes y de mantener los plugins y el mismo WordPress actualizado.

Esta responsabilidad debemos asumirla cómo responsabilidad compartida, pues en la mayoría de las ocasiones compartimos alojamiento web con otros usuarios y sitios, que pueden también verse afectados por nuestras malas prácticas.

Suficientemente seguro para ser el más popular

El término “popular” quizás no sea el más acertado, pero a fin de cuentas es verdad y hay que asumirlo. Y es que con 64 millones de instalaciones de WordPress (el 17% de todas las webs están creadas con WordPress), y subiendo, los datos confirman que el partido está ganado. No hay ninguna otra plataforma (Ruby on Rails, Python, etc) que se acerque siquiera a tal nivel de aceptación.

El núcleo de WordPress es lo suficientemente seguro para ese uso masivo, lo que hace todavía más sorprendente que aún haya desarrolladores que sigan con la idea, anticuada y falsa, de una supuesta inseguridad de WordPress.

Es más, con el nivel de implantación actual de WordPress, incluso un 0,0001% de inseguridad sería un problema, pero WordPress sigue creciendo sin problemas y dando servicio a millones de usuarios, administradores y desarrolladores satisfechos.

Las evidencias son claras, así que hay que reabrir el debate de manera activa, blogueando sobre ello, explicando al mundo la realidad de que el núcleo de WordPress es seguro, y que todos los sepan, para cambiar esa falsa memoria colectiva, que sigue coleando desde hace nada menos que 4 años.

WordPress sigue creciendo, mejorando, y convenciendo a cada vez más usuarios, yes una plataforma segura, ágil, potente y sencilla de utilizar y mejorar, y además es software libre.

Así que WordPress merece que también Internet reconozca esa reputación de ser un CMS seguro, ¡difúndelo!, estoy deseando ver enlaces en los comentarios a las entradas de vuestros blogs explicando al mundo que WordPress es seguro.

fuente: ayudawordpress.com

Esta es una versión de seguridad. Esta versión también corrige varios problemas.

El objetivo del Grupo de Desarrollo es continuar proporcionando actualizaciones regulares y frecuentes para la comunidad de Joomla!.

Para esta versión los requisitos del sistema son los siguientes:

PHP 5.3.1

register_globals debe estar apagado (Off)

magic_quotes_gpc debe estar apagado (Off)

Fuente:Joomla

Mucho se ha hablado de que Joomla! inseguro, y lo cierto es que muy pocas veces se han aportado datos que puedan confirmar esas hipótesis. La desinformación muchas veces ha provocado que asumamos como ciertas algunas opiniones de profesionales que no se han molestado en buscar la raíz de los problemas. Si te lo quieres demostrar a ti mismo, en este artículo se especificarán al final diversas acciones que podrás implementar para que Joomla! pueda ser utilizado con toda seguridad.

Por qué no se debe decir que Joomla es inseguro

Partamos del hecho que la inseguridad es una constante de todo sistema informático. Nunca podemos decir que un software es completamente seguro, igual que nadie puede asegurar que esté completamente libre de errores. La inseguridad existe, en Joomla!, igual que en cualquier otro CMS o pieza de software en general. Existen en Internet multitud de sitios basados en Joomla! que son inseguros ¿Pero realmente se puede generalizar y decir que por ello Joomla! es inseguro?

La seguridad o la inseguridad es realmente una responsabilidad de los desarrolladores, que muchas veces no hacemos correctamente nuestro trabajo. Pero no me refiero a la comunidad que realiza el propio CMS, sino más bien a quienes lo utilizamos para construir sitios basados en él. Los desarrolladores muchas veces dejamos huella de nuestro trabajo y con ello a veces quedan piezas de software que pueden comprometer un sistema. El ejemplo más típico, que ocurre en Joomla igual que en otros CMS, es el uso de determinadas extensiones que tienen un problema de seguridad o el uso de versiones antiguas de Joomla que no están actualizadas y que contienen agujeros de seguridad.

Pero hay casos todavía más básicos. Un sistema puede ser tremendamente seguro y sin embargo, escoger una clave corta o predecible lo puede dejar vulnerable. Aunque ojo, no solo debemos escoger claves complejas, sino realizar otras optimizaciones como cambiar los nombres a las tablas, tener cuidado con los permisos de los archivos o directorios, ofuscar las versiones del CMS o los nombres de los archivos que contienen código. Todas esas recomendaciones las revisaremos enseguida.

A veces se critica a Joomla diciendo que al ser software libre cualquiera puede saber los errores de seguridad que tiene, pero eso podría ser un crítica contra todas las herramientas de código abierto y sabemos que no es cierto. Existe una numerosa comunidad detrás que apenas aparece un agujero de seguridad publica nuevas versiones del software para solucionarlo. Nuevamente somos los desarrolladores los que debemos, concienzudamente, actualizar el CMS siempre que aparecen nuevas versiones estables seguras.

Durante el evento de seguridad en Joomla! #joomlaIO también se mencionó una estadística interesante. Solo el 5% de los errores de seguridad de Joomla! se dieron en el “core”, o sea, en la arquitectura básica del CMS. Esto quiere decir que el 95% de los agujeros de seguridad detectados en Joomla! pertenecen a otras piezas de software externas, con complementos como extensiones o plugins, temas, etc. En este sentido se puso énfasis en señalar que habitualmente los desarrolladores instalamostemas “piratas” que realmente tienen caballos de troya con scripts que roban contraseñas u otros datos sensibles. Por ello hay que tener siempre en cuenta descargar complementos o plantillas de fuentes seguras y desconfiar cuando un sitio web ofrece gratuitamente temas gratuitos que son de pago en otros sitios.

Nota: no es nuestra intención entrar en comparaciones sobre la seguridad con otros CMS populares, sean o no de código abierto. Solo decir que el 5% de agujeros en el core de Joomla! contrastan con el 20% de agujeros encontrados en el core de otro popular CMS.

Checklist de seguridad básica en Joomla!

A continuación encontraremos una serie de items fundamentales que tenemos que observar a la hora de implementar Joomla en un ambiente seguro. Es apenas un listado, que a buen seguro servirá de mucha utilidad, sin embargo, si se desea obtener mayores explicaciones, recordamos que está disponible el hangout donde el equipo de #joomlaIO ofreció muchos otros detalles, consejos y guías para implementación de estos items de seguridad.
Primeros pasos / Seguridad en el core de Joomla!:

• Descargar desde joomla.org o sitios de absoluta confianza
• Comprobar que estamos instalando la última versión estable de Joomla!
• Comprobar que no estamos utilizando el nombre de superusuario por defecto (admin)
• No establecer la contraseña de FTP (establecerla constituiría una vulneración de la seguridad)
• Activar el fichero .htaccess en servidores Linux (para ello debemos renombrar el fichero htacess.txt a .htaccess). Podemos ampliar la seguridad con docs.joomla.org Htaccess_examples_(security)
• Habilitar las URLs amigables para los motores de búsqueda (SEF)
• Comprobar que la duración de la sesión no excede de 15 minutos
• Eliminar plantillas que no sean necesarias
• Comprobar que los permisos de directorios están en 755 y los permisos de archivos en 644
• Utilizar un usuario de base de datos para la configuración de Joomla que no tenga acceso externo a la misma

Primeros pasos / Seguridad durante la instalación y mantenimiento de las extensiones Joomla!:

• Realizar un backup de la estructura FTP y la base de datos antes de instalar cualquier extensión. Utilizar Akeeba Backup / Admin Tools
• Descargar extensiones solo de sitios de confianza extensions.joomla.org
• Comprobar que las extensiones que instalamos son la última versión estable disponible
• Eliminar las extensiones que no vayan a ser utilizadas y no formen parte del CORE (conviene revisar manualmente que los directorios y archivos asociados a la extensión se han borrado correctamente)

Configuración del servidor / Directivas de PHP:

• Comprobar que register_globals está desactivada
• Comprobar que allow_url_fopen está desactivada
• Comprobar que allow_url_include está desactivada
• Comprobar que open_basedir está activada y las rutas asociadas (esta directiva limita los archivos que se pueden abrir por PHP al árbol de directorios especificado)
• Comprobar que están desactivadas show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
• Comprobar que safe_mode está desactivado

Configuración del servidor / Estructura de archivos:

• Comprobar que las carpetas del sitio están en 755
• Comprobar que los archivos del sitio están en 644
• Comprobar que no existen ficheros en la carpeta temporal /tmp

Configuración del servidor / Protección de archivos y carpetas críticas:
Para obtener una mejor protección del sitio web en Joomla, es conveniente sacar fuera de la estructura httpdocs el fichero configuration.php , para ello debemos modificar los siguientes archivos:

Motivo:Sacar fuera de la estructura httpdocs el fichero configuration.php y definir la ruta en la constante para que el fichero sea accesible por Joomla!

Ruta de los ficheros a modificar: /includes/defines.php y /administrator/includes/defines.php Línea de código a modificar: define(‘JPATH_CONFIGURATION’, JPATH_ROOT);

Extensiones recomendadas para mejorar la seguridad de Joomla

Hay varias extensiones que nos permiten añadir una capa extra de protección en Joomla! muchas de ellas son muy conocidas, algunas no tanto. Nombramos algunas de ellas con una pequeña descripción.

RSFirewall 
RSFirewall es una extensión que todos deberían usar. Correctamente configurada nos alertará de los intentos de intrusión en el sitio y nos permitirá realizar acciones como la denegación de IPs, o definir las ubicaciones desde la que se podrá acceder al backend, entre muchas otras funciones.

Admin Tools 
Una navaja suiza para la administración del sitio web en Joomla. Verificar y corregir los permisos de carpetas y directorios, proteger el acceso al panel de administración con una contraseña adicional, cambiar el prefijo de la base de datos o realizar su mantenimiento son algunas de las excelentes características de esta extensión. Además es del creador de Akeeba Backup, sin duda toda una garantía de la limpieza de su código y de sus posibilidades.

Akeeba Backup 
Un sitio web al que no asociamos ninguna política de backups es como un barco a la deriva. Es cuestión de tiempo que un fallo nos haga pasar un mal rato. Akeeba es una de esas extensiones que merece la pena pagar sin ningún género de dudas. La versión gratuita ya nos permite la realización de backups, pero es en la versión Pro donde encontramos todo el potencial de la extensión.

Aquí, Akeeba nos permitirá lanzar los backups directamente a diversos servicios de almacenamiento en nube, desvinculando la copia del servidor donde tenemos el sitio web. Creo recordar que su creador (Nicholas Dionysopoulos) en el manual de Akeeba nos indica en tono “jocoso” que una buena copia de seguridad es la que se realiza en una placa tectónica diferente (por si los terremotos).
Algo altamente recomendable es instalar o solicitar que nos instalen en el servidor la extensión MyCript.php, ya que es utilizada por akeeba para encriptar los paquetes de copia de seguridad aportando mayor seguridad.

Encrypt configuration 
A menos que utilicemos un certificado de seguridad SSL, un usuario que se registra en Joomla enviará su contraseña en texto plano a través de la red. Un usuario malintencionado podría aprovechar esta vulnerabilidad y obtener acceso al back-end.
Este plugin es una alternativa a SSL. Se utiliza RSA para cifrar las contraseñas o cualquier otra información que desees en los componentes.
Hay que tener la extensión bcmath. Funciona con nombre de señal, Login JTP Horizontal, PWC sesión, inicio de sesión en línea y módulos VTJ inicio de sesión. Para otras extensiones de Joomla, como Alpha Registro, Community Builder, Core Design Módulo sesión, Yoo sesión, YJ Módulo Login Pop puedes encontrar plugins en www.ratmilwebsolutions.com/downloads/encryption-plugins.html. No hay necesidad de configurar. Sólo tienes que instalar los plugins necesarios.

Conclusión

Creemos que después de estas notas se habrán despejado algunas dudas y mitos sobre la seguridad en Joomla!. Quizás los desarrolladores que critican el popular CMS no lo hacen con mala intención, pero sí por desinformación.

Aquellos profesionales que implementan Joomla son los mayores responsables de crear sistemas seguros, mediante la meticulosa revisión de diversas recomendaciones comentadas anteriormente y el uso de alguna que otra extensión de enorme utilidad. Esperamos que este documento haya resultado de utilidad.

fuente:desarrolloweb

Así que hoy vamos a añadir una dirección más a nuestra lista de sitios donde revisar y aprender más sobre el código fuente de WordPress: phpdoc.

Lo mejor de todo es que puedes navegar por todas las funciones, filtros y hooks de WordPress por versión, incluso en lo que tiene que venir. Una vez dentro del navegador del código encuentras una explicación de para lo que sirve y ejemplos de uso, bastante más fácil de usar que el mismo Codex.

Fuente: AyudaWordpress

Investigadores de seguridad adviertes a los administradores web de una serie de ataques contra las plataformas de publicación WordPress y Joomla.

El Sans Institute asegura haber recibido informes de múltiples intentos de exploit en las plataformas de publicación WordPress y Joomla después de lo cual a los sites comprometidos se les inyectó código que redirigía a sus visitantes a otras páginas web.

Para los expertos los ataques están siendo particularmente interesantes por el método utilizado de intentar explotar páginas web en masa atacando los propios servidores.

John Bambenek, uno de los expertos, explica en un post que lo interesante del caso es que no parece ser un escáner que está explotando una vulnerabilidad, sino una herramienta que básicamente “dispara un racimo de exploits de Joomla y WordPress en un servidor y espera que alguno funcione”.

Sans Institute asegura que los sites comprometidos son utilizados para redireccionar a los usuarios a un site en el que se intenta infectar a los usuarios con un paquete de antivirus falso. Este tipo de acciones a menudo se utilizan para engañar a los usuarios para que paguen cuotas de suscripción y otros costes que son falsos.

Se pide a los administradores y webmaster que actualicen su software con el fin de evitar las infecciones.

Joomla, que a finales de noviembre de este año alcanzó los 36 millones de descargas, es un sistemas de de gestión de contenido gratuito y de código abierto con el que puede publicarse contenido en Internet.

El ataque contra WorlPress es el segundo conocido durante este año. El primero se produjo en enero. Fue la empresa de seguridad M86 Labs quien descubrió el kit Phoenix, utilizado para explotar un fallo en la plataforma WordPress 3.2.1. La compañía estimó en aquel momento que cientos de sites habían sido infectados por el ataque.

Diseñado como un kit automatizado para infectar sistemas, Phoenix permitía a los distribuidores de malware embeber código en las páginas web vulnerables de manera automática. Después intentaban colocar un troyano en todo aquel sistema que intentara acceder a la página web infectada.

fuente :CMS

A modo de recordatorio, vamos a apuntar las novedades de WordPress 3.5 que desde ya puedes empezar a utilizar en tu sitio:

1. Nuevo cargador y gestión de imágenes.
2. Editor de imágenes adjuntas.
3. Iconos planos en el editor visual.
4. Botones cuadrados en vez de redondos (se supone que más modernos).
5. Nuevo tema por defecto Twenty Twelve (Twenty Ten ya no estará en la distribución oficial aunque se podrá descargar independientemente).
6. Escritorio HiDPI para una mejor experiencia con pantallas retina.
7. Toda la zona de administración ahora es adaptable al dispositivo con el que se esté visualizando.
8. Mejoras en el soporte de elementos “incrustables” con oEmbed (Instagram, Slideshare, Soundcloud).
9. Mejoras en multisitio, como que ahora ya se puede instalar en una carpeta.
10. Se cambia el nombre del editor “HTML” a “Texto”
11. Desaparece la gestión de enlaces.
12. XML-RPC activo por defecto(sic).
13. APIs actualizadas (TinyMCE, jQuery, jQuery UI, jCrop, y SimplePie).

Como ves son muchas cosas nuevas, unas buenísimas y otras no tanto, pero todas dignas de mención, así que ¡a probarlo ya mismo!.

Y ahora la pregunta …

¿Vas a actualizar a WordPress 3.5?

fuente:ayudawordpress

Aún así, todavía las webs con Joomla son un porcentaje pequeño, concretamente, casi el 3% del total, según sus cálculos. No obstante, el crecimiento del gestor fue de un 27% durante el mes de noviembre. Así, los desarrolladores están más que contentos.

En este sentido, Paul Orwig, presidente de Source Matter, la organización que lleva el proyecto Joomla comenta:

“Es un momento excitante para Joomla porque ya tenemos casi el 3% de la web. Joomla es una comunidad colaborativa con cerca de 2,7 millones de mensajes en el foro de la comunidad, más de 587.000 miembros y un registro de más de 10.000 extensiones. Felicitamos a todos los que han conseguido y ayudado a conseguir estos números”.

El proyecto de Joomla se puso en marcha en 2005. Desde entonces no ha parado de crecer y ayudar a desarrollar webs de todo el mundo. Pero el fuerte del proyecto es su comunidad. De ella han nacido 1.500 nuevas extensiones desde noviembre 2012. Además, 3.100 portales gubernamentales tienen su web desarrollada a partir de Joomla.

Fuente:Joomla

El equipo de trabajo de Drupal 8 anuncia un retraso en la nueva versión de este sistema de gestión de contenido.

Los máximos responsables del equipo de Drupal 8 han decidido introducir una nueva fase llamada “de finalización de funciones” (Feature Completion Phase) en el ciclo de desarrollo de este CMS que supondrá un retraso en el lanzamiento de su nueva versión cuyos primeros pasos fueron dados en marzo de 2011.

La razón de este retraso es porque todavía hay importantes características para Drupal 8 que están todavía en progreso. Estas novedades incluyen cambios de diseño, un editor WYSIWYG con funciones de edición en línea, soporte para servicios web nativos, mejroa del soporte móvil y de HTML5.

La nueva fase de desarrollo se espera que dure de 1 diciembre 2012 a 18 febrero 2013. Esto significa que la fase code freeze (congelación de código) de Drupal 8 se retrasará tres meses hasta julio de 2013. A continuación, el calendario de lanzamiento prevé varias fases pero sin concretar fechas exacta por lo que no se conoce cuando exactamente será lanzado el nuevo Drupal 8.

Drupal es un software libre desarrollado y mantenido por una activa comunidad de usuarios que destaca por la calidad de su código, respeto por los estándares web y usabilidad. Interesados en sumarse al equipo de trabajo de Drupal 8 pueden acceder a drupal.org.

Por último señalar que sin una confirmación oficial hasta la fecha, varias informaciones apuntan que Internet Explorer 6 y 7 recibirán un soporte limitado en la versión 8 de Drupal.

fuente:desarrolloweb

Respuestas Rápidas a consultas frecuentes

1. Pregunta: Nadie puede ver los nuevos foros que he creado
   Por defecto, los nuevos foros no tienen permisos asignados. Debes asignarles permisos o copiarlos desde otro foro para que puedan ver y acceder a los foros que has creado.
2. Pregunta: Yo tengo permisos totales como administrador. ¿Entonces porque no puedo ver mis nuevos foros?
   Los permisos de Administrador no tienen relación con los permisos de los foros. Tienes que asignarle los permisos correspondientes a ese foro, para que tu o tu grupo de usuarios puedan ver o postear en este nuevo foro que has creado.
3. Pregunta: He configurado los permisos para mis nuevos foros, pero aun no puedo verlos.
   Recuerda de que, además de agregar permisos a cada foro, también debes configurar los permisos para la Categoría “padre” que los contienen (si el nuevo foro que creaste se llama “Consultas” y está dentro de la categoría “General”, debes dar permisos adecuados a esta categoría “General” también).
4. Pregunta: He añadido una nueva categoría de foros, con los permisos adecuados, pero aun no la puedo ver.
   Las categorías no se mostrarán a menos que contengan foros dentro (obviamente con foros que se puedan ver y sean accesibles).
5. Pregunta: ¿Como les puedo permitir a mis moderadores crear posts como “Notas” o “Anuncios”?
   Los permisos para crear este tipo de posts, se encuentran en los permisos de Foros. Si les asignas el rol de “Acceso Total” a ese grupo, dentro de los permisos de ese foro, podrán realizar este tipo de posts. También puedes hacerlo desde la configuración avanzada.
6. Pregunta: He configurado un subforo para que copie los permisos de su foro padre, pero cuando he cambiado los permisos del foro padre, los del subforo no cambian.
   La acción de “Copiar permisos” es una acción, no una configuración permanente. Cuando seleccionas esta opción, esto copia los permisos del otro foro cuando das click al botón “Enviar”. Pero no se copiarán los futuros cambios que hagas, solo se copian en ese momento, a menos que luego de cambiar los permisos del foro “padre”, vuelvas a copiar los permisos, al editar el subforo (en la opción de Administrar foros).
7. Pregunta: He creado un foro privado con un grupo especial el cual tiene los permisos para ver el foro. Pero, ninguno de los usuarios de este grupo puede ver este foro.
   Probablemente has dejado al grupo de “Usuarios registrados” con la configuración de NUNCA para el permiso de poder ver este foro. Como los usuarios de este nuevo grupo (el grupo especial), son también usuarios registrados, al quitarles todos los permisos a los usuarios registrados (con la opción NUNCA), esto prevalece a los permisos que les hayas dado al grupo que creaste. Lo que deberías hacer es eliminar el grupo de usuarios registrados desde la lista de permisos de ese foro, en vez de configurarle los permisos a ese grupo (dejando en NUNCA la opción para ver foros, por ejemplo).

Si luego de leer estas preguntas y respuestas, no te ha quedado como resolver tu problema, lee el resto de la guía, donde se te enseñara básicamente a agregar/editar los permisos del foro que estas editando o del nuevo foro que has creado.

Tipos de Permisos

Dentro de la sección (pestaña) de permisos, hay 4 tipos diferentes de permisos, dentro de los cuales hay globales (que se aplican a todo el foro) y locales (para ciertos foros o usuarios en particular):

• Permisos Globales para Usuarios o Grupos de usuarios: Para por ejemplo, no permitirles cambiar su avatar.
• Permisos Globales para Administradores: Para permitirles administrar foros por ejemplo o para permitirles crear nuevos grupos.
• Permisos Globales y Locales para Moderadores: Para permitirles cerrar temas (permiso local) o banear usuarios (esto es un permiso global)
• Permisos Locales para Foros: Para permitir ver el foro o permitir postear en el.

Por ejemplo, si quieres que uno de tus usuarios no puedan enviar mensajes privados, debes dirigirte a la sección de permisos globales y buscar a ese usuario y editar ese permiso.

Por otra parte, los permisos locales se aplican a ciertos foros. Si le quitas el permiso a alguien para postear en un foro, esto no tendrá efectos en el resto de los foros a los cuales si tiene acceso, solo se aplicara a ese foro en particular.

También puedes configurar moderadores globales o locales. Los moderadores globales puedes moderar todos los foros a los cuales tengan acceso según los permisos que les asignes. En contraste, los moderadores locales solo podrán moderar el numero de foros que tu les selecciones específicamente. Además estos foros locales van a poder tener ciertos roles en ciertos foros. En un foro van a poder borrar mensajes por ejemplo, y en otro, solo editarlos. Los moderadores globales tendrán los mismos permisos para todos los foros.

Configurando los permisos de los foros

Para configurar los permisos del nuevo foro que has creado, debemos recurrir a la categoría “Permisos basados en foros” y seleccionar la opción “Permisos de foros” (todo esto en la pestaña de PERMISOS, por supuesto). Ahí seleccionas el foro y se te mostrara la siguiente pagina.

En esta página se muestran 2 columnas, una para usuarios y otra para seleccionar grupos. Arriba, se ven los usuarios o grupos que actualmente tienen algún tipo de permiso para ingresar al o a los foros seleccionados. Estos los puedes seleccionar y cambiarle los permisos con el botón de Editar permisos, o removerle los permisos con el botón de Eliminar permisos, para que estos grupos o usuarios (los de las listas superiores) no puedan ver el foro y no tengan ningún tipo de acceso a el (aunque lo tengan al pertenecer a otro grupo). Las listas de abajo, te permiten añadir usuarios o grupos que actualmente no poseen permisos configurados en el foro/foros seleccionado/s.

Para añadirle permisos a grupos, selecciona uno o varios de la lista de “Añadir grupos” (lista que esta abajo a la derecha, en la imagen anterior). Para los usuarios es similar, solo que debes tipear sus nicknames manualmente o buscar sus nicks). Al presionar el botón de “Añadir Permisos” luego de elegir el grupo o usuario a añadir, se te llevara a la interface de permisos del foro que seleccionaste para este grupo/usuario en particular.

Por ejemplo, si has creado un nuevo foro, debes agregar desde la lista de abajo (Añadir grupos) al grupo de Administradores, Moderadores, y al grupo de usuarios registrados o a otro grupo que quieras tengan acceso, editando los permisos de cada uno de estos grupos. Si no haces esto, aunque seas administrador, ni siquiera podrás ver el nuevo foro que has creado.

Hay 2 formas para configurar los permisos de estos grupos (o de cada usuario), usando los “Roles de permiso” que son permisos predefinidos, o ser mas especifico usando los “Permisos Avanzados” que te permitirán configurar mas características del foro y ser mas preciso.

Permisos Manuales (Avanzados)

Este es el aspecto mas importante de los permisos, y debes entenderlo bien. Hay 3 diferentes valores que los permisos pueden tener:

• La opción SI, le dará el permiso para ejecutar la acción. A menos que este marcada la opción NUNCA, que prevalece.
• La opción NO, impedirá que se le de el permiso para ejecutar la acción, a menos que este marcado SI.
• La opción NUNCA, deshabilitara completamente el permiso para el usuario. Prevalece sobre SI (explicaremos esto mas abajo).

Estos 3 valores son importantes debido a la posibilidad de que un usuario puede tener más de 1 permiso para una misma opción, al pertenecer a diferentes grupos por ejemplo.

Pongámonos en el caso de que un usuario, pertenece por defecto al grupo de “Usuarios Registrados”, y además, a un grupo llamado “Usuarios VIP” que tú has creado para los usuarios mas dedicados a tu web. Ambos grupos, tienen diferentes permisos para ver ciertos foros. Supongamos, existe un foro llamado “Descargas” el cual quieres que solo este disponible para los usuarios del grupo “Usuarios VIP” y no para que lo vean ni puedan acceder el resto de los usuarios registrados. Por supuesto, colocaras en SI la opción de “Puede ver foros” para el grupo de “Usuarios VIP”, pero NO debes colocar la opción de NUNCA para el grupo de “Usuarios Registrados”. Si al grupo de “Usuarios Registrados” dejas en NUNCA la opción de ver este foro, el grupo de “Usuarios VIP” tampoco podrá ver el foro, pues la opción de NUNCA (que dejaste para usuarios registrados) prevalece sobre la opción SI (que dejaste para los usuarios VIP, y obviamente un usuario VIP pertenece previamente al grupo de usuarios registrados, desde que se registro en tu foro). Por lo tanto, las opciones correctas para “puede ver foros” para ambos grupos, en este foro denominado “Descargas”, son:

SI para el grupo de “Usuarios VIP”
NO para el grupo de “Usuarios Registrados” (en vez de NUNCA).

Otra opción, es sencillamente eliminar al grupo de “Usuarios registrados” de los grupos que tienen acceso al foro (que no aparezcan en la lista de arriba donde aparecen los grupos con algún tipo de permiso). Con esto los usuarios registrados no podrán ver, ni acceder al foro que creaste. Ahora si por ejemplo quieres que puedan ver el foro, pero no enviar mensajes, tienes que hacerlo con los permisos avanzados, como se ha descrito antes, cuidando de no activar la opción NUNCA, para que esto no afecte al grupo que SI quieres que tengan acceso.

Consultas…

Espero con esta pequeña guía queden un poco mas clara las cosas que debes tener en cuenta a la hora de crear un nuevo foro y de como permitir o no permitir cosas a ciertos grupos o usuarios de tu foro.
Recuerda que cualquier consulta, puedes hacerla en nuestros foros, con los debidos datos de Soporte y respetando las Normas.

Fuente: http://www.phpbb.com/support/documentat … ssions.php – Resumido y modificado por Mitch

Extraído de:  phpBB-ES.com

Permisos para foros en phpBB3 (con imágenes)

Comencemos por MediaWiki, el software por excelencia  para desarrollar sitios wikis. Esta herramienta publicada bajo la licencia de software GNU General Public License. se encuentra actualmente en su versión 1.20. A continuación les dejo el enclace para descargarla.

Le toca el turno a phpMyAdmin, la herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web. Este proyecto se encuentra vigente desde 1998 y ya se encuentra en la versión 3.5.4 que acá les dejo:

Para terminar, comparto con la comunidad la versión 7.17 de Drupal.

Estas aplicaciones son facilitados por el centro de Descargas de GUTL.

Mi consejo para evita este tipo de ataques, cada vez mas frecuentes, sería seguir estos pasos:

1. Cambia el prefijo de la base de datos
2. Cambia el nombre de usuario admin por otro distinto y elige una contraseña segura.
3. Añade las siguientes líneas al archivo .htaccess de la carpeta de tu instalación de WordPress:

# proteger contra inyecciones sql
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

4. <a title="seguridad wordpress" href="http://ayudawordpress.com/proteger-wordpress-contra-malware/" target="_blank">Instala un plugin de seguridad</a> para comprobar regularmente WordPress.

fuente:ayudawordpress

Prevista para su lanzamiento en los próximos diez días, esta nueva versión del popular CMS trae entre sus novedades más destacadas el nuevo tema por defecto Twenty Twelve, una mayor facilidad a la hora de subir fotos e insertar imágenes en el cuerpo de los mensajes creados en WordPress, nuevo selector de color, más opciones para instalar plugins desde WordPress.org, además de actualizar el escritorio para soportar las nuevas pantallas Retina de los MacBook Pro de Apple.

Para preparar a la comunidad WordPress para le llegada de esta novedades ha sido liberada una versión candidata (R.C) dirigida a cualquier tester que quiera comprobar la compatibilidad de los últimos cambios con sus proyectos web.

Pese a que esta versión incluye toda la funcionalidad que vamos a poder encontrar en la versión final de WordPress 3.5,  no se recomienda la instalación de esta R.C en páginas que no sean de pruebas.

Si además te interesa aprender a dominar el diseño bajo WordPress y la creación de plantillas te aconsejamos que no dejes de darle un vistazo a una nueva iniciativa de formación tutorizada que el equipo de Escuela.IT está preparando para el próximo día 6 de diciembre.

Interesados en probar WordPress 3.5 tienen la posibilidad de acceder a más información y descarga desdewordpress.org.

fuente:desarrolloweb

Aún estamos empezando a disfrutar WordPress 3.4 y ya casi tenemos fecha para la próxima versión: WordPress 3.5, que en charla de desarrollo del miércoles se estimó para el 5 de diciembre como primera fecha propuesta.

Entre las novedades de WordPress 3.5 que se van apuntando están ya las siguientes:

• Nuevo tema por defecto Twenty Twelve.
• Importantes cambios y mejoras de la interfaz
• Mejoras en el “personalizador” de temas, relativos a los menús y a la gestión de imágenes de cabecera y fondo
• Se eliminará el gestor de enlaces, algo que tiene bastante sentido debido a su poco uso, solo con sentido para el widget de enlaces o alguna plantilla de página. Lo que no sé es porque se sustituirá ni como.
• Modificación del modo de carga de imágenes.
• Cambio radical en la galería, que espero por fin incorpore la inclusión de varias galerías en una misma entrada.

Y de momento poco más, a espera.

Fuente: AyudaWordpress

¿que te parecería acelerar un poco este proceso?

 Me estoy refiriendo a evitar que WordPress tenga que hacer “llamadas” a la base de datos tan típicas como estas:

<?php get_bloginfo('url'); ?>
<?php get_bloginfo('wpurl'); ?>
<?php bloginfo('url'); ?>
<?php bloginfo('home'); ?>
<?php get_bloginfo('stylesheet_directory'); ?>
<?php get_bloginfo('template_directory'); ?>
<?php bloginfo('stylesheet_directory'); ?>
<?php bloginfo('template_directory'); ?>
<?php get_stylesheet_directory(); ?>
<?php get_template_directory() ?>

Si quieres facilitar esas búsquedas a WordPress, y que no tenga que consultar en la base de datos a la hora de hacer cosas tan simples como determinar la URL del sitio, donde está la hoja de estilos o incluso el tema en uso, nada como meterle un meneo al archivo de configuración.

Así que solo tienes que abrir el archivo wp-config.php y añadirle estas líneas:

define('WP_HOME', 'http://ayudawordpress.com'); // blog url
define('WP_SITEURL', 'http://ayudawordpress.com'); // site url
define('TEMPLATEPATH', '/ruta/absoluta/a/wp-content/themes/nombredeltema');
define('STYLESHEETPATH', '/ruta/absoluta/a/wp-content/themes/nombredeltema');

Guardas los cambios y ya lo tienes.

Por supuesto, que no se te olvide cambiar las rutas del ejemplo por las tuyas.

Fuente: AyudaWordpress

Esta constante, llamada relocate es de esas estupendas sorpresas que nos da WordPress cuando creemos que ya lo sabíamos todo.

La función de relocate es ayudarte cuando tengas que migrar de un dominio a otro, de manera que no tengas que cambiar las direcciones del dominio en la base de datos.

El proceso sería el siguiente:

1. Edita el archivo wp-config.php.
2. Después de las declaraciones “define”  (justo antes de la línea que dice ”¡Eso es todo, deja de editar!“), inserta una nueva línea y teclea: define('RELOCATE',true);
3. Guarda los cambios en el archivo wp-config.php.
4. Exporta tu instalación de WordPress y la base de datos.
5. Importa tu instalación de WordPress y la base de datos en el nuevo sitio.
6. Abre un navegador y apunta manualmente a la pantalla de acceso (wp-login.php) del nuevo servidor. Por ejemplo, si tu sitio nuevo está en http://minuevodominio.es teclea http://minuevodominio.es/wp-login.php en la barra de direcciones del navegador.
7. Accede normalmente
8. Mira en la barra de direcciones del navegador para comprobar que estás en el dominio correcto. Si quieres ve a “Ajustes -> Generales” para verificar que las direcciones de WordPress y del sitio son las nuevas. Ante la duda guarda los cambios
9. Cuando hayas realizado estas comprobaciones edita de nuevo el archivo wp-config.php y, o elimina la línea añadida o coméntala (con // delante de la misma) o pon el valor true a false por si en otro momento quieres hacer un relocate.

¿Y esto?

Pues resulta que cuando defines la constante relocate a true la URL del sitio se actualiza automáticamente a la ruta que estés usando para la pantalla de acceso a WordPress. En ese momento modifica el ajuste de URL del sitio y de WordPress.

Nota importante: este truco no cambia todas las referencias de URL al dominio anterior existentes en tus entradas (enlaces internos, enlaces a imágenes, etc), para cambiarlas te recomiendo usar el plugin Search & Replace, que sirve exactamente para reemplazar cadenas en tu base de datos por otras (úsalo con precaución y haz siempre copia de seguridad antes de la base de datos).

Fuente: AyudaWordpress

Nunca está de mal conocer todas las posibilidades que tenemos a nuestro alcance y en determinadas ocasiones puede que nos sea de gran utilidad poder activar el modo mantenimiento en WordPress con el archivo “.maintenance“ utilizado oficialmente en las actualizaciones automáticas de WordPress durante las últimas versiones.

Crea un archivo llamado “maintenance.php“, colócalo en “…wp-content/maintenance.php”  y en el interior del archivo pega el siguiente código:

<?php
$protocol = $_SERVER["SERVER_PROTOCOL"];
if ( 'HTTP/1.1' != $protocol &amp;&amp; 'HTTP/1.0' != $protocol )
$protocol = 'HTTP/1.0';
header( "$protocol 503 Service Unavailable", true, 503 );
header( 'Content-Type: text/html; charset=utf-8' );
?>

Estamos de mantenimiento, vuelve a intentarlo en un momento o visita nuestro Twitter.

<?php die(); ?>

El mensaje puede ser personalizado e incluso integrar adecuadamente código HTML para obtener una página de mantenimiento mucho más currada.

Y por último, para activar el modo mantenimiento crea un archivo llamado “.maintenance” en el directorio raíz de WordPress (junto al archivo wp-config.php) conteniendo el siguiente código;

<?php $upgrading = time(); ?>

Cuando termines de realizar las tareas de mantenimiento solo tienes que eliminar o renombrar el archivo ”.maintenance“ y todo volverá a funcionar correctamente.

Por supuesto, también podemos utilizar otros métodos como las redirecciones en .htaccess, pero “.maintenance” puede que nos sea de utilidad para automatizar algún script o cuando tengamos ciertas limitaciones de acceso/privilegios.

Fuente: AyudaWordpress

Este concepto creció y obtuvo la mayoría de edad con otro, en este caso denominado “blogroll“, mediante el que enlazabas (también) a otros – en este caso – blogs de temática similar, blogs de amigos, etc.

Y así ha sido durante años, también y especialmente en WordPress, que desde que lo conozco ha tenido una sección de enlaces y, cuando aparecieron, un widget para tu “Blogroll“, … hasta hoy.

Y es que el equipo de desarrollo de WordPress ha decidido abandonar la sección de enlaces, y el widget de Blogroll, o Sitios de Interés como tendrás en la traducción al español, a favor de los menús personalizados, que deberían acoger esta utilidad de, mediante enlaces externos, compartir otros sitios de interés o tu blogroll temático.

Si quieres poner una fecha para este “asesinato” premeditado del blogroll, se ejecutará con WordPress 3.5 con toda seguridad.

De hecho, en WordPress.com ya están empezando a eliminar la sección de enlaces, y aunque aún no se ha extendido a todos los sitios puede que mañana ya no encuentres tus enlaces, ni puedas usar el widget para enlazar a tus amigos, así de crudo.

Si no quieres perder tus enlaces, a falta de que los chicos de Automattic incorporen algún widget al efecto (mediante plugin), en WordPress.com tendrás que copiar y pegar tus enlaces en un editor de texto y, a falta de otra cosa, añadir al menú del tema los enlaces que desees. Mi consejo sería que uses el truco de añadir menús sin enlace como superior, y luego añadir tus enlaces personalizados como subordinados de este. Este menú, incluso podrás añadirlo con el widget de “Menú personalizado”, el único sustituto razonable.

Otra opción sería crear una página donde ir añadiendo enlaces, bastante común y disponible como plantilla de página en algunos temas, en realidad bastantes.

Los usuarios de WordPress.org, completo e instalado en servidor propio, tenemos más opciones (un recordatorio más de que la libertad es importante, aunque sea más cómodo usar servicios gestionados), pues hay plugins que nos pueden ayudar como Link manager, un sustituto del gestor de enlaces en forma de plugin para cuando salga WordPress 3.5, o WP render blogroll links, que crea, como hacen muchos temas (otra opción), una página donde “acoger” tus enlaces.

Y, al igual que con WordPress.com, también puedes añadir enlaces externos como elementos de menú o usar una página o widget a este efecto. Al menos por opciones que no quede.

¿Mi opinión?, pues que es un error. Puedo entender que se pretenda liberar la distribución oficial, pero que lo dejen como plugin “heredado”, al igual que los importadores, pero no que se lo carguen. Los webrings/blogrolls han creado lo que hoy conocemos como Web 2.0, pues han sido los inicios de la conversación entre webs, han ejercido la labor de difundir contenidos relacionados y ayudado al posicionamiento en buscadores a blogs nuevos, y todo esto se pierde, o se pervierte, con esta muerte precipitada e innecesaria del blogroll en WordPress.com y WordPress.org.

Si el equipo de desarrollo quiere liberar espacio de la distribución podrían quitar inutilidades como el plugin Hello Dolly, o los widgets que se alimentan de fuentes externas en el Escritorio (Plugins, Noticias de desarrollo, etc) que, además, consumen memoria del servidor desde el minuto cero de la instalación, eliminar widgets inútiles para la mayoría de la gente como el del Calendario, el de Akismet, el de páginas o incluso el de Meta, o incluso unificar la gestión de entradas y páginas, fusionando estas últimas como un tipo de entrada personalizada más. Vamos, que alternativas hay.

Y, bueno, ahora te toca, ¿a ti que te parece esta decisión?

Si tu respuesta es distinta la cuentas en los comentarios.

Fuente: AyudaWordpress