Feed aggregator

If you have ever spent any time around software development, (especially here in Portland with our amazing open-source community) you'll know that the community takes a great deal of interest in the success of others. With Drupal, I have rarely come across another technology that shares the same sense of nearly parental pride from members of the community.

read more

We are happy to announce that Development Seed is sponsoring Do It With Drupal this year!

read more

Drupal’s module installation system makes it very easy to extend and customise Drupal sites and to disable and re-enable modules quickly and non-destructively. However, the default way Drupal’s treats modules can get in the way during development.

When building your own modules, it’s common for database table structure to change as project needs become clearer, or even for modules to be built in a “front to back” fashion – where the admin screens and the UI interaction skeleton is built before the underlying processing and data storage code is developed (or finalised).

If this is the case, you may find yourself building an install file late in module development and then wondering why Drupal seems to dutifully ignore it.

Despite being counter-intuitive, this behaviour has some clear benefits. Previously installed modules may have attached database tables, and these tables may still hold valid application data. Drupal’s behaviour ensures that these tables aren’t destroyed when the module is disabled. The module can then be re-enabled later without any data destruction.

To get a module to run an install file, or to re-install successfully, you need to do more than just disable and re-enable the module on the module list screen (/admin/build/modules). This is beacuse  Drupal keeps a record of previously installed modules and won’t reinstall them if they are merely disabled and re-enabled.

The trick to getting your new / updated install file to run is to remove the modules entry from the system database tables. If your module has already created one or more tables, and you want the table structure to be altered or rebuilt, you may also need to remove these tables before re-enabling the module.

Once you’ve disabled your module, removed the related entry from the system table and removed any module-related tables, you can re-enable the module and your install file will be run correctly.

With the D7UC Initiative gaining steam and excepting brainstorming ideas, I figured it was a good time to map out my idea for Ubercart and CiviCRM integration. I realize that may cringe and the mention of uniting these two applications, for all their complexities, yet I see it as critically important for many non profit organizations, and I'll explain why.

Many organizations that I have worked with want to take in money in two ways via the web:

read more

Although I am a big fan of Joomla, Drupal seems  OK in many different web solutions.

Joomla is heavy weighted and includes many different features at first, but Drupal is light weighted and you need to improve it until you got what you wanted. I made METU Chemistry web site by using Joomla (1.0.x), you may use the web links to check it. I think Joomla is enough for web sites of schools, departments etc. It gives a lot of customizable content support. Moreover, there is a link of METU Karate, you may see another example of Joomla (1.5.x).

I only created one web site with Drupal, at first it seemed complicated but i was beginning to learn after a while. Drupal was not my first choice, but I needed a CMS with postgresql support, therefore Drupal is the best choice. 43rd International Chemistry Olympiads (IChO43) will be at METU Chem in 2011, you may check its web site created with Drupal. However, lorem ipsum filled nowadays, wait for updates.

As i mentioned, i like Joomla more than Drupal, but Drupal could handle more  complicated jobs if needed, its your decision to use any of them.

So, I’m in the middle of doing an essay I really don’t want to do. We’ll see if this is just procrastination talking but I’m starting to feel like doing a Masters is not what I want to be doing. I want get started on the real stuff I always planned to do after the masters, a year earlier.

I really feel there is a gap for good church website building software that is opensource that could compete with the propriety software such as City and churchinsight. I think that software like that is fine and certainly morally defensible from a Christian standpoint. However, Open Source software and the community around drupal is just so much cooler and imo so much powerful in a community like the church.

Once this essay is in I’ll start blogging a bit more with how things are supposed to go.

Each day this week, Tools of Attraction will present a story from Cassettefrommyex.com, a celebration of lost loves and mixtapes from Jason Bitner, co-creator of Found Magazine. Today's entry comes from Bitner himself — enjoy!

A long-standing issue with the Git mirrors of Drupal's CVS has been fixed thanks to Damien Tournoud.

The problem is that CVS outputs dates in RCS tags in the somewhat nonstandard format 2009/10/19 (ISO 8601 specifies dashes, not slashes as separator). The git-cvsimport tool used for creating the mirrors, however, uses cvsps, that updates the RCS tags to use the correct format (2009-10-19). Adhering to standards is generally a good thing, but in this case it was causing merge conflicts when trying to merge patches created with Git into Drupal (or vice versa).

Damien found a way to resolve the issue, however:

Adding DateFormat=old to the CVSROOT/config file fixes the problem.

Changing this, however, required a reimport of the entire repository. Due to the way Git works with commit-ids being a cryptographic hash of their contents, changing the contents (even if just the RCS tags) means a rewrite of Git history.

So while the new repository contains the same code, you will not be able to merge new changes from it into your current checkouts. Damien will continue both imports for a while, but updates for the old repository with the incompatible date format will be discontinued at a future date.

What is the bottom line then?

The executive summary

1. The Git mirror at git://github.com/drupal/drupal.git has been rewritten with it's RCS tag date format compatible with CVS defaults. Please use this mirror for all your future projects.
2. The Git mirror at git://github.com/mikl/drupal.git will continue to have the CVS-incompatible format, and will, for a time, continue to be updated, so you will be able to use it for a little while longer.
3. There is now no excuse for not using Git for your Drupal core development work. Enjoy.

Finally, I'd like to thank Damien for doing all the hard work. I was maintaining the git-cvsimport process myself for a while, and I do not miss it.

Need an Intranet? Follow these tips and tricks for a pain-free set-up of OpenAtrium, a new Drupal project from Development Seed.

Esto fue la instalación que hice hará un tiempo para uno propio e hice mi propio log:

Está hecho para gente con un nivel medio-alto de conocimientos en linux. (¡AL LORO!)

Iniciamos la instalación de debian 5 (no tiene que coincidir el nombre del dominio con el del grupo de trabajo o la instalación falla)
Creamos las siguientes particiones:

/                  <- root
/home       <- para alojar la web

/usr           <- ftp por si lo queréis montar algun día.
Creamos la clave de root y el usuario de a pie.

Pongo la ip fija editando el fichero de texto ubicado en /etc/network/interfaces

iface eth0 inet static
 address 192.168.1.100 #direccion ip
 netmask 255.255.255.0 # mascara de subred
 gateway 192.168.1.1 # puerta de enlace predetermida (router o modem)

Miro el archivo /etc/resolv.conf y veo que me ha puesto el solo los dns

paquetes a instalar con apt-get install (como root):

php5
php5-mysql
php5-cgi
php5-cli
php5-common
libapache2-mod-php5
mysql-server
mysql-common
mysql-client
apache2
apache2-mpm-prefork
phpmyadmin
phpsysinfo
ssh

(las operaciones no-criticas las intento hacer como usuario normal)

Una vez instalado todo pasamos a lo más duro, configurar.

1. CONFIGURACIÓN DEL APACHE

una  vez instalado el apache queda como ruta principal de la máquina /usr/www de momento la cambio por /home/borja/www.

Donde ”borja” es mi nombre de usuario, cada cual que ponga el suyo.

se puede cambiar desde /etc/apache2/sites-available/default en la opción DocumentRoot

reiniciamos  el apache con apache2ctl restart

hacemos una probatina escribiendo en un navegador con http://nombredelequipo/phpsysinfo  … OK!

2. CONFIGURACIÓN DEL PHP

Añadimos a la configuración del apache la siguiente línea con el comando:

echo “DirectoryIndex index.html index.cgi index.shtml index.pl index.php index.xhtml index.shtml” >> /etc/apache2/apache.conf

compruebo con cat (esto os lo podéis saltar)

3. CONFIGURACIÓN DE MYSQL

Al turrón:

ln -s /var/www/phpmyadmin /home/borja/www/phpmyadmin

entro en http://nombredelequipo/phpmyadmin con usuario root (al instalar mysql-server te pide la contraseña)

compruebo no casca por ningun lado y salgo

vim /etc/phpsysinfo/config.php

y cambio el lenguaje de en a es

compruebo… all green

4. CONFIGURACIÓN DEL FTP
Instalo proftpd, lo ejecuto desde initd en vez de servidor independiente para ahorrar recursos, ya que va a tener pocas (poquisimas) conexiones.

descomento la linea DefaultRoot ~ en /etc/proftpd/proftpd.conf

Con esto conseguimos que no se pueda subir a mas directorios que el asignado para el usuario ( /home/usuario/ ) Si no introducimos esta linea cualquiera que se conecte al servidor FTP podrá subir por los directorios y ver una información que se supone que no debe ver.

etc/init.d/proftpd restart

pruebo con ftp://nombredelequipo y me identifico con un usuario de la máquina … funciona!

5. FINAL STEP: DRUPAL

Éste lo pongo como extra, es la instalación de drupal, un CMS tipo Joomla o Mambo, para crear nuestra propia web.

 wget http://ftp.drupal.org/files/projects/es-6.x-1.x-dev.tar.gz

descomprimo y pongo todos los archivos en home/borja/www/

Nos guardamos los ajustes iniciales y editamos el fichero

cp sites/default/default.settings.php sites/default/settings.php

Creo un usuario llamado borja con todos los privilegios en la base de datos por phpmyadmin para evitar trabajar como root.

y ejecuto

mysqladmin –u borja –p create drupal 

mysql –u borja –p

GRANT ALL PRIVILEGES ON drupal.* TO borja@localhost IDENTIFIED BY <q>micontraseña</q>
Flush privileges;
\q (para salir de MySQL)

edito en /sites/default/settings.php la línea db_url = “mysql://usuario:contraseña@localhost/drupal” por la que corresponda.

Le doy privilegios de escritura para todos con chmod a+w a las carpeta sites/default y al archivo settings.php de esa carpeta.

y escribimos http://nombredelequipo  en el navegador, con esto empieza la instalación automatizada.

Introducimos lo que nos pida y ya tenemos nuestro site montado.

Es un poco perry la guía porque paso de primera a tercera persona todo el rato, pero epic pal cambiarlo ahora.

I've spent a lot of time lately working with the Omega theme, and really trying to get features lined out that I've had planned for some time now. I spoke on many of those desired features during my presentation at DrupalCamp Montreal, and wanted to be able to really get some of those important features integrated prior to DrupalCampNYC coming up in December when I might have the chance to speak again on the Omega theme.

I recently had a quick blog entry on what those feature plans for Omega would be for my own purposes, and to document those features outside of my presentation. I created issues in the issue queue for Omega at Drupal.org, and then posted information on those here. The list of features that I had planned for the theme that relate to this post were:

• Custom Layout Configuration based on node->type (#614412)
• Custom Layout Configuration based  on path (#614416)
• Custom Layout Configuration based on Context (#614422)
• Priority levels for layout overrides (#614438)
• Saving "Grid Templates" (#614440)

After some serious contemplation, and some time spent in Photoshop wireframing the interface to manage these features, it became "clear" to me that what I was wanting to do would be essentially impossible on the theme layer, and would need to be moved out to a module in order to incorporate these features.

The main issue was being able to store & manipulate copies of the theme settings variables in a way that would allow for the most flexibility. As I already have a huge amount of nested fieldsets in the theme-settings.php file in the Omega theme, and still have a ton more to integrate to allow for "full" 960.gs grid management, I really saw no way to cleanly incorporate a ton of addtional code to compensate for node types, contexts & path groups that wouldn't blow up the current theme settings system, and bring Drupal to a grinding halt.

So I spent a day or two of contemplating how to appropriately integrate these features into my theme, a new module was born, called Delta. The Delta Theme Settings API (full name still in flux) is set to handle the things listed above that I want to incorporate to the theme level. The best part of spending some serious time thinking about a proper implementation was that I was able to line out some ideas that actually will make the Delta module valid and useful for ANY theme that uses theme-settings.php to add any functionality to the theme layer.

What is the Delta module?

Delta by definition: (Greek letters in mathmatics)

• a finite difference
• a difference operator
• a symmetric difference
• the difference or change in a given variable

Okay, that's all well and good, but what does some greek crap have to do with the module itself, and how it can help Drupal theming?

Essentially, the Delta module incorporates a few simple concepts regarding overriding the theme settings for a given theme, and provides an interface to manage those overrides. There are 3 main features to the module:

• Overrides
• Theme Settings "Templates"
• Preprocess work to use these overrides in Drupal when conditions are met.

Overrides

The concept of overrides is quite simple. An override is similar to how the context module handles things. An override is a set of conditions to query when loading a page in Drupal that will determine if there is a custom set of theme settings we want to use for that page rather than the default.

An override is essentially a named element with a weight which will allow for priority sorting, a theme, which will tell the system that the override applies to that theme, and then a theme settings template to apply to that override. The conditions that can be queried are the node type of the page, a context that is currently active, or a group of paths that will also trigger the override.

The override management page(s) will look like the following screenshot. Each actively enabled theme will have a page of overrides that apply to that theme. You may have themes enabled where the Delta module does NOT apply, and that will filter the sub-tabs to only present you with options for those themes you wish to manipulate.

This table of overrides is using the Drupal table drag JS to allow quickly reording the overrides. The order of these overrides as they appear on the page is the order in which they would be prioritized when overriding theme settings. If two overrides applied to the same node type, the one that is higher on the list would take priority.

The add override page currently looks like this, and integrates AHAH to provide a list of available templates after selecting the theme which an override applies to:

Theme Settings "Templates"

The theme settings "templates" are where the power of the overrides come in. Each "template" only applies to a single theme, as it needs to reference the currently available theme settings available for that theme. The theme settings template will be essentially a copy of the theme settings available for the theme which can be configured and saved separately. This would allow using different options based on where an override is found to be true and implemented.

The interface for this is still unset, and is on my plate for this week to finish up. The way this needed to be implemented, this module will require the Popups API in order to save/edit these templates in a modal window for usability and to avoid having to click around in many situations to get to a configuration page.

Preprocess integration

This is the final piece of the module which will be the last integration after all of the backend management of overrides and templates are situated.

Here, in preprocess functionality, the Delta module will determine when and where overrides are present, and essentially intercept the default theme settings in the system, and overwrite them with what is available from the Detla API. I have yet to investigate how this information is currently being stored, and/or if it's called on every page, or is cached in the system.

There are still lots of things to figure out on how to make this completely bulletproof, and useful to others besides myself, but I know this functionality has the possiblity to gain some momentum from hard core themers that would be able to leverage the power of this to its full potential.

Final Thoughts

I still have a lot to work out and integrate into the Delta module to make it as good as the concept seems right now. One thing that is important for this is the ability to have exportables of all the settings, and hooks to integreate those in similar ways that we export views, imagecache presets, etc.

Stay tuned for more information as I get more code written for the Delta module, and announce an alpha release soon! I'll be very interested in having some testers that are willing to bang the hell out of the module on some various themes to see how it works outside of my own testing ground.

You are not watching this post, click to start watching

Open Atrium reviewed as a tool for group communication and collaboration

Open Atrium is featured in the December issue of Linux Magazine as a tool that facilitates group communication and collaboration. In the five page article, Marcel Gagné looks at how Open Atrium can be used for these purposes and gives an excellent and very thorough look at the functionality that comes with Open Atrium out of the box.

"Open Atrium is simply beautiful and beautifully simple. As the administrator, you can define one or more groups, invite users, and let them get to work. The groups inhabit spaces where they share information, documents, events, and more. Every person who logs in can access the cool Dashboard tool to monitor group activity at a glance begin."

The article is a great resource for anyone getting started with Open Atrium. In addition to the overview of what Open Atrium can do, Gagné walks through in detail how to install it on your server, how to set up groups, projects, and its other features, how to add users, and how to tweak out your admin settings. And we're excited to see that he found it useful.

Jeff Eaton of Lullabot summarizes support for the new White House website relaunched on Drupal that "brought cheers from the open source community." He continues with "Acquia and Phase2 deliver[ed] a great [Drupal] site [silencing] outdated claims that OSS can't be used on 'Enterprise' level sites..."

For anyone attempting to create a compound field (meaning a single CCK field that is made up of multiple sub-fields) in Drupal, but are lost in a sea of poorly documented hooks and functions so abstracted as to have lost nearly all meaning, like I was for the last two days, I offer you the following module. This is tested to work on an Acquia Drupal 6.14 build with CCK version 6.x-2.5. By “work”, I mean that your form will have a compound field that saves data and is available in your $node object. There are no settings, no validation or sanitizing or views integration. This is provided merely as a starting point for your own custom module.

For your own use, you’ll want to start with these four functions:

• compoundfield_field_settings to declare your database structure;
• compoundfield_process to declare the Form API structure (as you would any other Drupal form);
• theme_compoundfield to theme the form HTML;
• and theme_compoundfield_formatter_default to theme the frontend HTML.

Suggestions, questions, and comments are all welcome. This code is mostly a combination of the link module, Karen Stevenson’s very helpful Lullabot article, and this article by Jennifer Hodgdon.

Download: compoundfield 6.x-1.1

Angie Byron, Jeff Eaton, Nate Haug, Kent Bye, and Jeff Robbins discuss the latest Drupal news and then revisit the Drupal Top 40 podcast, this time with a list of 50+ "must have" Drupal modules. Enjoy this epic 2 hour podcast!

read more

The White House has relaunched its web site - the main portal to the Government's electronic presence - using open source content management system Drupal. This decision isn't without detractors.

Great Software, easy to use, joomla, wordpress, dotnetnuke and blogger Design awesome WordPress Blogs, professional Joomla! and Drupal templates, and cool Website designs in Minutes, You don't need to learn Photoshop, CSS, HTML and other Web technologies to create great looking designs, including images and buttons.

Bloging Tips And Full Free Download : Joomla Templates, Joomla Extensions, Wordpress Themes, Wordpress Plugins, Premium Themes, CMS Drupal, Graphics, Icon, Fons, Wallpaper

The 2009 Open Source CMS market share report was released a couple of weeks ago. The report concludes that WordPress, Joomla! and Drupal maintain a large lead on the rest of the pack, and that they are the dominant players in the market.

Despite the rather lengthy nature of the survey, more than 600 persons completed the question set. The demographic data gathered shows the survey group to be primarily composed of senior IT professionals working in smaller organizations of 1 to 5 people. More than 80% of the participants had heard about Joomla!, Wordpress and Drupal, though most of them were more familiar with Wordpress and Joomla!.

© 2009 Open Source CMS market share report by Water & Stone and CMSWire.

Last year’s report found little to differentiate the three systems, at least in terms of market share. This year it appears that Joomla! gained a lot of market share relative to WordPress and Drupal. For example, the report shows that Joomla! has more books in print than Drupal or WordPress, and that Joomla! is used more than WordPress and Drupal -- at least by the participants in the survey. The results also show that Drupal has the highest abandonment rate of the three, that is, the rate at which systems are tried, then abandoned in favor of another system. The survey concludes that while the race is far from won, it does seem like Joomla! is starting to take the leadership position. On the flip side, the survey participants seems to be more positive about Wordpress and Drupal, than they are about Joomla!. All things combined, the data suggest we should be able to win over many users if we improve the Drupal experience.

© 2009 Open Source CMS market share report by Water & Stone and CMSWire.

All in all an interesting report that matches my perspective on the market. It is great to see Drupal come out strongly, but it also suggests that we have a lot of work to do. I'm very bullish about Drupal's future -- I think Drupal 7 can change the game for Drupal, especially combined with other successes like Whitehouse.gov using Drupal, Drupal being promoted to Gartner's 'visionaries' quadrant, as well as important initiatives as the Drupal.org redesign, Drupal Gardens, Buzzr and more. Exciting times!

Drupal?

Một số câu hỏi về Drupal, ví dụ như:

1. Khi Drupal nâng cấp từ 6 lên 7, liệu có liên quan đến PHP5 và việc PHP5 đã hoàn toàn hỗ trợ OOP?
2. Liệu Drupal có refactor lại để phù hợp với OOP của PHP5.
3. Nếu PHP6 có cái gì đó hơn PHP5, thì Drupal 8 sẽ như thế nào?

Suy đoán của cá nhân tui về Drupal.

1. Drupal có cơ chế riêng của nó, các Hook có thể coi là các Class, các function của Hook có thể coi là method, và các kết quả dạng Array có thể coi là các Object. Việc Drupal sử dụng kết quả dạng Array, vì nó có cơ chế để parse data trong Array ra thành dữ liệu, và cơ chế này là thống nhất với toàn bộ các Hook. Nếu như các framework khác sử dụng Object với một hay nhiều data type, thì với tui, việc chỉ sử dụng Array của Drupal là thông minh, vì nó nhất quán, giúp cho developer không phải nghĩ đến chuyện xử lý dữ liệu như thế nào nữa.
2. Một trong những lợi thế của viết OOP là quản lý được phạm vi sử dụng tài nguyên của biến, cụ thể là mỗi biến sẽ có một data type cụ thể, và việc sử dụng data type nào sẽ phụ thuộc vào đặc trưng, nhu cầu và limitation của data type đó. Có khi nào dụng ý sử dụng Array để lưu trữ dữ liệu là vì tránh phải quản lý việc sử dụng data type nào cho phức tạp?
3. Khi xây dựng module cho Drupal, developer thường suy nghĩ theo hướng viết PHP đơn thuần, có nghĩa là xây dựng function rồi sử dụng. Nhưng việc Drupal có cơ chế cho truy xuất các function trong các module không có nghĩa là ta không suy nghĩ đến việc build ra các Hook tác động với Object mà module được tạo ra để làm việc với nó. Giả sử giả thuyết các function trong Hook là method trong Class là đúng, thì việc sử dụng function như method (theo OOP) sẽ khác với việc truy xuất sử dụng function trong module, và khống chế được hậu quả mà việc dùng sai data type sẽ gây ra.

Thắc mắc:

1. Nếu Drupal coi Hook là Class, thì việc quản lý sự tác động lên các property hoặc method của Hook ra sao? Ví dụ property nào sẽ là private, public, protect? Drupal mà quản lý được mức độ tác động lên property hoặc method của Hook, thì việc bảo mật code của Drupal ở lớp logic là hoàn toàn có thể.
2. Có thể xem cơ chế của Drupal là hướng đối tượng (kiểu Drupal) không?

Note ra để kiểm chứng, mặc dù những gì được viết trên đây là giả định, nhưng phải khẳng định rằng Drupal có concept rất tốt, là một platform được xây dựng sẵn các cơ chế, chứ không phải set of treatment như các framework khác.

Nguồn: ĐỌc từ blog Sếp Ban :p