Drupal Blogs, Pictures, and more on WordPress

The fiber optics connections to Asia(Seacom and TEAMS) finally arrived in Kenya. Question is, what technologies are used by the websites that receive the highest hits? I decided to do some digging, and here is a quick snapshot of the results based on Alexa:

Site Server Side Lang. CMS CSS Javascript Daily Nation - - YAML framework Mootools
plugin_js @Home Portal Kenya PHP Joomla - Mootools Standard Media PHP - Dynamic Drive DHTML code library - Capital FM PHP - - Prototype
Scriptaculous
Mioplanet News Ticker
Google Maps integration PataUza PHP - - - Safaricom PHP - - - Haiya PHP Drupal - jQuery

Clearly, PHP currently rules on the server side, possibly because of its cost implications and the availability of quality CMS with which it easily integrates. I expect to see more of ASP and Ruby based sites as the developer community grows.

Exploitation of available Javascript utilities is limited, with jQuery and Mootools being used to add a few effects for the menus. I would expect more sites to have AJAX to enrich the user experience using such libraries as Ext Js or even Prototype.js.

As far as the duel between Adobe Flex and Microsoft Silverlight is concerned, no front runners have emerged so far.

Many ‘Old-School’ companies cling to the — of intellectual property like a security blanket. In the digital age, consumers are sick of it and have all the tools available to get what they want for free when they want it. That’s why it just makes sense to ‘give away’ software to the people that want it. There’s always the consumer who wants more, therefore the Upgrade model will always work.

For those who don’t know, open source software is the tech industry’s real version of the free trial. It allows consumers and businesses to use software that a company creates for free through a general public license (http://ping.fm/rYmnK). That means anyone who wants to can use the product for their own personal or commercial use. The business model usually attached to it is that a company offers a free version of its software and provides paid upgrade options that include more features. Usually the free version has all you’ll ever need to create a great website or program, but every now and then the upgrades are REALLY COOL!

I use open-source software on a regular basis for my business. We create website based on open-source software like Joomla!, WordPress, and Drupal all the time because it SAVES CLIENTS MONEY!! It’s easier for me to sell a client on a $5,000 website that uses much of the same technology as thousands of other websites out there than to create a completely custom app every time (would cost well over $30,000 for even the cheapest of sites).

Not only can I get more bang for my clients’ bucks, but I can also provide them with low cost security and usability upgrades in the future without spending my company resources to build them. It allows us to focus on what makes us valuable to consumers and focus on web design and marketing. Leave the software development to the, well, software developers!

I’ve only described why it works for me (selfish I know). There are many reasons why it can work for the software developers as well. Let’s talk awareness – give something away for free and people find out. They post it all around the web, blogs and news sites pick it up and talk about it. It can even show up on Tech TV shows, the local news, and huge conferences attended by many of the industry’s elite. People love the ‘generosity’ of developers who offer open source, and the more demanding consumer will always pay for the upgrade.

As a business model it makes sense for the developer, the re-seller, and ultimately the end user. It saves money for the latter two and provides good will (and free marketing) for the former. With the amazing amount of choices in the market today, it just makes sense to let the product speak for itself. After all, “if you build it [and give it away for free] they will come”!

Ghi lại để nhớ cái tội ngu cả buổi chiều ngồi đọc code để tìm ra cái điều mà nó đã được mô tả trong hướng dẫn sử dụng của nó. Ngu vãi!!!!

1. Dùng module Pathauto

2. Bật tính năng Transliterate prior to creating alias

3. Hiệu chỉnh nội dung tập tin i18n-ascii.txt chứa trong thư mục module pathauto – thêm vào các nguyên âm mang dấu tiếng Việt

——– bắt đầu ———

à = “a”
á = “a”
ả = “a”
ã = “a”
ạ = “a”

ă = “a”
ằ = “a”
ắ = “a”
ẳ = “a”
ẵ = “a”
ặ = “a”

â = “a”
ầ = “a”
ấ = “a”
ẩ = “a”
ẫ = “a”
ậ = “a”

À = “a”
Á = “a”
Ả = “a”
à = “a”
Ạ = “a”

Ă = “a”
Ằ = “a”
Ắ = “a”
Ẳ = “a”
Ẵ = “a”
Ặ = “a”

 = “a”
Ầ = “a”
Ấ = “a”
Ẩ = “a”
Ẫ = “a”
Ậ = “a”

đ = “d”
Đ = “d”

è = “e”
é = “e”
ẻ = “e”
ẽ = “e”
ẹ = “e”

ê = “e”
ề = “e”
ế = “e”
ể = “e”
ễ = “e”
ệ = “e”

È = “e”
É = “e”
Ẻ = “e”
Ẽ = “e”
Ẹ = “e”

Ê = “e”
Ề = “e”
Ế = “e”
Ể = “e”
Ễ = “e”
Ệ = “e”

ì = “i”
í = “i”
ỉ = “i”
ĩ = “i”
ị = “i”

Ì = “i”
Í = “i”
Ỉ = “i”
Ĩ = “i”
Ị = “i”

ò = “o”
ó = “o”
ỏ = “o”
õ = “o”
ọ = “o”

ô = “o”
ồ = “o”
ố = “o”
ổ = “o”
ỗ = “o”
ộ = “o”

ơ = “o”
ờ = “o”
ớ = “o”
ở = “o”
ỡ = “o”
ợ = “o”

Ò = “o”
Ó = “o”
Ỏ = “o”
Õ = “o”
Ọ = “o”

Ô = “o”
Ồ = “o”
Ố = “o”
Ổ = “o”
Ỗ = “o”
Ộ = “o”

Ơ = “o”
Ờ = “o”
Ớ = “o”
Ở = “o”
Ỡ = “o”
Ợ = “o”

ù = “u”
ú = “u”
ủ = “u”
ũ = “u”
ụ = “u”

ư = “u”
ừ = “u”
ứ = “u”
ử = “u”
ữ = “u”
ự = “u”

Ù = “u”
Ú = “u”
Ủ = “u”
Ũ = “u”
Ụ = “u”

Ư = “u”
Ừ = “u”
Ứ = “u”
Ử = “u”
Ữ = “u”
Ự = “u”

ỳ = “y”
ý = “y”
ỷ = “y”
ỹ = “y”
ỵ = “y”

Y = “y”
Ỳ = “y”
Ý = “y”
Ỷ = “y”
Ỹ = “y”
Ỵ = “y”

———————– kết thúc ———————–

I maintain a drupal codebase that hosts multiple sites. I’ve been shamefully lax in getting regular backups of those files and databases, until today. Here is a pretty basic bash script that will create a bzip2 archive of the drupal codebase (including site-specific dirs), and then create mysqldump exports of each site’s database and gzip those files. This particular script requires that the drupal install directory be named “drupal”, but you can change this easily enough to suit your needs.

This does require a ~/.drupalsites file that contains the needed database login info (suggest chmod 600). Like I said, nothing too clever.

#!/bin/bash
DATESTAMP=`date +%Y%m%d`
SITESFILE=${HOME}/.drupalsites
# SITESFILE contents are in the following format:
# SITENAME:DBNAME:DBUSER:DBPASSWD
DRUPALDIR=/path/to/drupal
BACKUPDIR=${HOME}/backups/${DATESTAMP}

mkdir -p ${BACKUPDIR}

# Backup the drupal codebase
echo -n "Backing up ${DRUPALDIR} ... "
cd ${DRUPALDIR}/../
tar -cjpf ${BACKUPDIR}/drupal_${DATESTAMP}.tar.bz2 drupal
echo "Done."

cd ${BACKUPDIR}

# Backup MySQL Databases
cat $SITESFILE | while read line; do
        #echo $line
        line=(${line//:/ })
        echo -n "Backing up MySQL db ${line[1]} ... "
        DUMPFILE=${line[0]}_${DATESTAMP}.sql
        mysqldump -u ${line[2]} -p${line[3]} ${line[1]} > ${DUMPFILE}
        gzip ${DUMPFILE}
        echo "Done."
done

echo "Backup completed, all files are in ${BACKUPDIR}."

This script runs fine from cron, I have it scheduled for a weekly run. I then plan to rsync this to my home server for an offsite copy, even though the hosting service provides backups as well.

PHPTemplate : <?php print $whatever; ?>

Smarty: <li>{$link}</li>

Người viết CSS ko cần biết PHPTemplate, sử dụng Smarty đòi hỏi người viết CSS phải biết Smarty cơ bản vì:

Sau khi biên dịch Theme sẽ tạo ra 1 file trong thư mục drupal/theme/engine/smarty/template_c . File đó sẽ có tên *.tpl.php. Vì vậy, đòi hỏi người làm CSS phải biết các tag(thẻ) trả về trong file *.tpl.php từ đó mới định nghĩa được file *.css cho Theme



Hace unos días me vi en la necesidad de exportar desde mi servidor local al servidor de desarrollo on-line (dado que el trabajo es en equipo) un sitio desarrollado con el gestor de contenidos Drupal , para continuar el trabajo en grupo desde un único servidor, evitando así que el sitio evolucione de forma dispar en el servidor local de cada miembro del equipo de desarrollo. Investigando en la red he encontrado poca información y muy dispersa, de forma que me pareció útil ponerla toda junta en un único post.

1. La base de datos

Lo primero que necesitaremos será exportar la base de datos de nuestro servidor local. Lo podemos hacer con phpMyAdmin. Seleccionamos la base de datos de nuestro Drupal en el servidor local, hacemos click en la pestaña “Exportar”. En la pantalla que se nos muestra hemos de asegurarnos que la casilla de verificación de “Datos” esté marcada y hemos de marcar también la casilla de verificación “Enviar (genera un archivo descargable)”, así podremos almacenarlo como un archivo con la extensión “.sql”.

Una vez hemos exportado la base de datos de nuestro servidor local, hemos de importarla en nuestro servidor de destino (ya sea de desarrollo o de producción). Para ello utilizaremos nuestro gestor de base de datos, en nuestro caso será otra vez phpMyAdmin. Primero creamos la base de datos con el nombre que queramos, y una vez creada ya podemos importar el archivo .sql que generamos en la exportación anterior. Una vez realizado esto, ya tenemos nuestra base de datos de Drupal en nuestro servidor de destino.

2. Estructura de directorios

Una vez tenemos la base de datos, hemos de exportar la estructura de directorio que conforma el Drupal desde nuestro servidor local a nuestro servidor de destino. Para ello bien podemos hacerlo comprimiendo todo el sitio en un archivo .zip o sin comprimir con el tiempo de transferencia que eso conlleva. En cualquiera de los dos casos, como resultado final hemos de tener el directorio descomprimido en el directorio de publicación de nuestro servidor de destino (htmlpublic, public, /var/www/, o como se llame en nuestro servidor…). Hemos de asegurarnos que el directorio sites/default de nuestro Drupal tenga permisos de escritura por parte del servidor web.

3. Configuración del servidor web

Si intentamos acceder al sitio Drupal en nuestro nuevo servidor, es posible que podamos ver la página de inicio sin problemas, pero desde que intentamos navegar por él veremos que las secciones no son accesibles. Esto se debe a que no está configurado adecuadamente el servidor web, dado que Drupal por defecto utiliza la url limpia (es decir, los parámetros pasados por url no se ven de la forma ?variable=valor&variable2=valor2, sino de la forma /variable/valor). Por lo tanto, hemos de configurar nuestro servidor para que permita el uso de urls limpias. En estas líneas explicaremos cómo configurarlo en caso de que tengamos acceso a los archivos de configuración del servidor con permisos de administrador. Para ello accedemos con permisos de edición al archivo:

/etc/apache2/sites-available/default

En este archivo, hemos de sustituir en el siguiente código:

Options Indexes FollowSymLinks MultiViewsAllowOverride NoneOrder allow,denyallow from all

La línea

AllowOverride None

ha de ser sustituida por

AllowOverride All

De esta forma nuestro servidor ya podrá reconocer las url limpias. Una vez salvados los cambios, reiniciamos el servidor web y nuestra exportación estaría concluida. A partir de ahora podremos utilizar nuestro sitio Drupal sin problemas y con todas las garantías de que no evolucione de forma independiente en el servidor local de cada desarrollador del equipo.

Drupal é um Sistema de Gerenciamento de Conteúdo (CMS, de Content Management System) rápido e com muitos recursos. Já vem com módulos para criação de Blog, Fórum de discussão, matérias (com feeds RSS criados automaticamente) e páginas de internet. Ainda é possível criar sites de comércio eletrônico, classificados, bate-papo, wikis, leitores de RSS e muitas outras ferramentas, bastando apenas usar as dezenas de módulos gratuitos disponibilizados no sítio. Temas para mudar o visual e traduções também estão disponíveis gratuitamente pela comunidade.

A ferramenta Drupal é escrita em PHP e funciona em qualquer sistema operacional (Windows, Linux, entre outros) e servidores web (Apache, IIS).

 

O nome Drupal deriva da palavra “druppel” do holandês, que significa cair (“drop” em inglês). O criador Dries Buytaert pensou no cair da chuva, gotas. Dries na verdade queria a palavra “dorp” (“vila” em holandês, numa referência a comunidade de usuários), mas quando foi procurar o domínio, digitou errado e achou que soava melhor ainda. O projeto começou em 2000. O mascote azul em forma de gota chama-se Drupalicon.

DOWNLOAD:

http://ftp.drupal.org/files/projects/drupal-6.3.tar.gz

DEMO:

Portal: http://www.opensourcecms.com/cms/drupal/

Administrador: http://www.opensourcecms.com/cms/drupal/admin.html
Usuário: admin
Senha: demo

Módulos:

O core do Drupal foi bem projetado com um sistema de ganchos conhecido como hooks, ou callbacks, que permite que módulos insiram funcionalidades dentro do Drupal.

Módulos incluídos no core do Drupal liberam usuário para:

* Criar, revisar e categorizar conteúdo
* Buscar conteúdo
* Postar comentários
* Participar de fóruns
* Votar em enquetes
* Trabalhar em colaboração escrevendo projetos
* Criar e visualizar páginas de perfil pessoal
* Comunicar entre si ou com outros administrados de websites
* Mudar o visual do site através do gerenciador de temas
* Construir menus de navegação de vários níveis
* Usuários do mesmo site podem navegar com seus idiomas locais
* Prove leitor de notícias RSS feeds
* Registrar e gerenciar contas de usuários
* Criar granularmente regras para usuários dando permissão para funcionalidades específicas do site
* Usar regras de acesso para proibir acessos específicos através dos usuários, emails, e endereços IPs.
* Prove estatísticas e relatórios para administração
* Gerenciamento de cache e throttling, técnica utilizada para desabilitar recursos quando o site estiver com alto tráfego
* Construir específicas regras para filtros de conteúdo
* Sistema de URL amigável que permite lembrar facilmente (ex: “www.mysite.com/products” melhor que “www.mysite.com/?q=node/432)

O Drupal possui centenas de módulos gratuitos escritos pela própria comunidade, como:

* e-commerce systems
* Workflow features
* Photo galleries
* Organic groups
* Google sitemaps
* Amazon Items
* Mailing list management
* Integration with CVS

 

Fonte: Plugmasters

If your web site contain a huge number of pages and corresponding level of difficulty in keeping track of all of them, your organization rely on constant and regular web site changes, often with several people working on it and your web site contributors lack sufficient knowledge in HTML and also you need to editorially review each new page before publication. When you are using a CMS will save a lot of time, hassle and money in the long run.

A Content Management System, or CMS for short, is a collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer based. Or in other word, CMS is an administrative software system that allows its users, often unskilled in HTML and web development, to update, edit and create new pages on their website.

In a CMS data can be defined as almost anything – documents, movies, pictures, phone number, scientific data, etc. CMSs are frequently used for storing, controlling, revising, and publishing documentation. Content that is controlled is industry-specific. (Entertainment content differs from the design of a fighter jet). There are various terms for systems (related processes) that do this. Examples include: Web Content Management, Digital Asset Management, Digital Records Management, Electronic Content Management (and others). Synchronization of intermediate steps, and collation into a final product are common goals of each.
Basic of a CMS

A typical CMS works like these; a web design layout is designed and developed. Usually this entails a logo/banner at the top, standard navigation menus across the top, down the left side, and/or at the foot of the page, and a ‘blank’ area where content is inserted, this layout format is then converted into a master template for all subsequent pages. During the process of this conversion, the CMS admin backend is integrated and tested. Web content producers are given access and instructions on how to add text and images to web pages automatically. Most CMS are usually very intuitive and easy to operate. and each generated page is saved onto a database, for future editing or deletion. More elaborate CMS can perform unique functions (such as archiving, built-in search engines, and mod rewrites), but basic functionality is still related to easy creation and editing of web pages.

Types of CMS

• Proprietary CMS
  These systems are usually very expensive to purchase such as the $500,000 and up Vignette system. These high end systems however come loaded with full features and usually have excellent customer and technical support. Common uses of these systems involve very large organizations with departments that require unique functionality.
• Open source
  These systems are typically free and relatively easy to install. Some of the better known open source systems include Mambo and Drupal. Because of its open source nature however, you will find a dearth of customer and technical support, however there exists a huge following and forums dedicated to the popular systems. Customization capabilities vary from system to system. Be sure to do all the necessary research before deciding on one.
• Custom CMS
  These types of systems are usually preferred as they allow you to develop from scratch, your preferred functionality. Debugging is also less of an issue as your web developer, having written the codes, can easily isolate and fix problems. Bear in mind there are literally hundreds of CMS to choose from. Ranging in costs from free to over $500,000. What you do need to do, is firstly figuring out exactly what functionality your organization needs, your development budget and finally find a system that suits those needs best.The downside to installing a CMS is of course, the amount of web development needed initially. While you are able to obtain free open source CMS programs, you still need to hire someone experienced and capable enough to integrate it correctly. This initial expense however, is usually a necessary evil and is justified as you avoid the need of hiring or outsourcing your webmastering needs down the road.

Ultimately a CMS is meant to make life easier, not creating new rigid standards that require stop gap hacks or workaround solutions.

copas from Globaltor – About Content Management System And Relation With Your Business Needs

Attendees: Tony, Will, Yu-Ching and Danny

Issue:

1. Tony talked to Duran Goodyear from UArts Communications Office. They are working on an University level digital assets archive program. Possible collaboration opportunity with them. Perhaps using ID dept. as the first test group!
2. Will and Jeff (MID 2) are building an onsite ‘project work server’ system based upon a web-based creative community resources project of Will MID graduate thesis “OKWagon” using Drupal, a web-based content management platform. Drupal can be a possible platform to build our archive system, and further incorporated in OKWagon.
3. Yu-Ching asked whether we should include PDF’s or just images to our archive. We shall find out after our meeting with Duran about their project.

To Do:

1. Faculty charrette: Sit down and go through all material to decide what to keep and what to toss.
2. Conduct interview/survey for faculty and students to find out what service they want the archive system to provide.
3. Start digitize the slides.

Next Meeting:

12/3/2009 1pm @ ID faculty Office with Sara McDonald (Library) and Duran Goodyear (Communications)