Drupal talk

Content translation: Required modules: i18n, translation_table, translation interface enable all the

对Drupal的更新没有采取正确的方法，因些显示一个content的时候会产生”ser warning: Unknown column ‘u.signature_format

I gave a talk recently on Facebook. The talk was meant as an introduction to the concept of Facebook and how it could be used to build communities and enable interaction. While the age of the attendees ranged from mid twenties to seventies, the predominant demographic was those aged fifty and above. This wasn’t a big surprise as the technological revolution has left a number of these people in its wake and even younger ones (myself included) have to constantly keep up with whats new in the realm of technology.

What surprised me most was that quite a number of those attending the talk had already registered Facebook accounts. In fact the majority had an account but did not use it. Their biggest worry was not how to use it (although I hope I was able to show them something new in the talk), but about the possibility of losing or having their identity stolen. It is unfair to deride them for being luddites simply because they have a valid concern which in fact few younger members have. As you get older, you have more to lose than a teenager whose “street cred” only extends as far as the end of the street.

What a lot of them failed to realize is that Facebook offers one of the most customizable privacy settings of any social media platform I have ever used (including MySpace, Ortuk, QQ, Socialtrak, Drupal, etc…). The ability to exclude groups of your “friends” as well as individual friends from viewing parts or all of your profile is what I think is an important function within Facebook. The process I suggested they adopt was the following:

- Don’t put anything on your profile that you don’t want others to see. For instance, I wouldn’t ever consider putting my credit card number or my actual address on Facebook, even if I have the option to block it out.

- Group your friends based on how close you are to them. I don’t mind my best friends seeing everything on my profile and photo album. I have a few FB “friends” solely for the purpose of the FB games I play. These I don’t give any access to anything other than the most basic information about myself.

- Go to Settings -> Privacy in your Facebook account and “customize” access for each of the logical segments of information categorized.

I understand that Facebook will shortly be changing the Privacy Settings page to make it more user friendly. Hopefully this will not remove the granularity of customization that we are now used to.

On the flip side of the equation, I have seen teenagers with FB profiles that are open to everyone and anyone. Basically even without being a friend, you can see everything they have available. This might be a concern in terms of physical and online safety. I think most of them only realize how dangerous this can be when their parents view their profiles….and comment! One of the most amusing sites I have visited recently is http://myparentsjoinedfacebook.com which posts screen captures of parents interacting with their children on Facebook. You wouldn’t believe how fast these kids figured out the Privacy settings after that!

Tong Hsien-Hui

Recently I got a chance to work on GMaps using drupal. GMap and Location modules are very good to integrate GMap with drupal. Views module made my life very easy.

Installing GMap + Views

1. Install views and enable views and views UI module

2. Install GMap and locations module and enable GMap, Location, GMap Location, Node Locations, User Locations, Location Add Another modules

3. Go to admin/settings/gmap page and add the gmap api key, which we can get through http://www.google.com/apis/maps/signup.html and adjust other map settings

4. Go to admin/settings/gmap_location page and adjust the gmap macro settings if needed.

5. Go to content type edit page and adjust the location settings.

6. Add the nodes by specifying some locations.

7. Go to map/node page which will show GMap with node locations marked.

Creating GMap View

Creating of view is normal, just select the view style as GMap. The result of the query values will display as markers on GMap.

GMap Macros

A GMap macro is a text-based way of describing arbitrary GMaps. We can build this macro using GMap Macro Builder module.

1. Enable GMap Macro Builder Module

2. Go to map/macro or click on the Build GMap Macro link in the Navigation to build macro.

3. Audgest the GMap settings, at the down in the Macro text box the text representation of map will be updated.Copy this text and use when ever is needed.

Using GMap Macro

We can use this GMap macro on any node. To display GMap on any node (ex: page) just copy the above GMap macro text and place it in the body text and choose the Input format GMap. To get input format GMap just add one input format like this.

1. Go to admin/settings/filters/add page

2. Type the name of the filter as GMap

3. Choose the GMap macro Expander and save.

I hope this will be helpful for others.

Note: I used Drupal 6.12 version.

1 cái patch bé xíu cho i18n để các block có khả năng thay đổi theo ngôn ngữ khi xem node ở chế độ full-node

--- D:/i18n.module.ori	Sun Jul 05 16:54:22 2009
+++ D:/i18n.module	Sun Jul 05 16:56:17 2009
@@ -512,6 +512,8 @@
       return "$alias.language ='$current'" ;

     case 'node':
+      return "$alias.language ='$current'" ;
+
     case 'translation':
       return "$alias.language ='". i18n_selection_mode('params') ."' OR $alias.language ='' OR $alias.language IS NULL" ;

1 cái patch bé xíu để relevant_content làm việc tốt hơn với i18n

--- D:/relevant_content.module.ori	Sun Jul 05 16:19:47 2009
+++ D:/relevant_content.module	Sun Jul 05 16:06:36 2009
@@ -505,7 +505,7 @@

   // Run the query and loop over the resultset, storing the returned nodes in an array using the Node ID as a key and the 5 fields selected as the values
-  $result = db_query($sql, $values);
+  $result = db_query(db_rewrite_sql($sql), $values);
   $nodes = array();
   while ($row = db_fetch_array($result)) {
     $nodes[$row['nid']] = $row;

drupalsliu posted a photo:

Sent from my iPod

As of this writing it is Independence Day here in the USA. On this day Jack Wallen ruminates on the freedoms that Linux has brought to him and the millions of other users. Do you share in his sentiment? Or are you one of those that espouses "It's just an operating system!"?

Ilman komeita palvelinsoftia tai rsyncattuja peilauksia Drupalista joutuu ottamaan varmuuskopioita käsin. Joskus manuaaliset varmuuskopiot tulevat tarpeeseen muuten hyvin varmistetulla palvelimella, esimerkiksi ennen isojen päivityksien asentamista Drupaliin. Varmuuskopion ottaminen Drupalista tarkoittaa sekä tiedostojärjestelmän että tietokannan huomiointia.

Tiedostojärjestelmä voidaan kopioida FTP:llä, mutta koska Drupalissa on runsaasti tiedostoja ja hakemistoja, komentorivin käyttäminen (ja vaikka käytön opettelu siinä samalla) on reilusti nopeampaa kuin FTP-session seuraaminen. Komentoriviltä tiedostot yhdistetään tar-paketiksi, joka tämän jälkeen pakataan gzipillä. Ennen tätä on kätevä ottaa tietokannasta varmuuskopio ja tallentaa se kansioon, joka liitetään tiedostojärjestelmän kanssa samaan tar-pakettiin. Näin tietokanta pysyy muun varmuuskopion mukana.

Käytännössä olen tullut ottaneeksi pienten päivitysten yhteydessä tietokannan varmuuskopion komentoriviltä, pakanneeksi kaikki tiedostot yhteen ja tallentamalla paketin aktiivisten verkkosivujen kansion juurihakemistoon, josta niitä ei tule vahingossa poistaneeksi tai liittäneeksi osaksi seuraavaa varmuuskopiota. Isojen päivitysten yhteydessä olen ottanut lisäksi tietokannan varmuuskopion phpMyAdminin kautta, koska Drupalin tietokantarakennetta joutuu monesti seuraamaan isojen päivitysten mukana ja seuraaminen ja muutosten tekeminen on helppoa graafisen käyttöliittymän kautta. Samalla kun phpMyAdmin on kerran auki, voi tietokannan tarvittaessa palauttaa tätä kautta ja käyttöoikeusongelma (josta lisää alempana) cPanelin kanssa voidaan ratkaista samalla kertaa.

mysqldump -u username -p mydatabase > tietokanta_dump.sql
#luo SQL-lauseet tietokannan nykytilaan palauttamisesta
tar -cvf kaikki_tiedostot.tar *
#kopioi kaikki hakemiston ja alihakemistojen tiedostot yhdeksi paketiksi
gzip kaikki_tiedostot.tar
#tiivistää paketin
mv kaikki_tiedostot.tar.gz ..
#siirtää varmuuskopion pois julkisesta kansiosta (ellet siirrä/kopioi sitä toiselle palvelimelle, kannattaa tehdä edes tämä jotta varmuuskopio pysyy tallessa)

phpMyAdminissa varmuuskopio tietokannasta otetaan Export-toiminnolla. Valitse tietokanta ja Export-välilehdellä tallenna tietokantaote tiedostoksi, jolloin sen voi ladata omalle työasemalle säilytystä tai edelleenlähettämistä varten.

Varmuuskopion palauttaminen

Drupalin ja moduulien päivityksien mukana tietokantaan lisätään usein uusia tauluja ja tiedostojärjestelmään ilmestyy uusia tiedostoja. Kun varmuuskopiot halutaan palauttaa, on syytä ensin poistaa vanhat tiedot kokonaan ja siirtää kopiot tilalle vasta sitten. Jos varmuuskopiot palauttaa uudemman tietokannan tai hakemistopuun päälle, päivityksistä voi jäädä ylimääräisiä tauluja tai tiedostoja joista voi olla haittaa myöhemmin.

Tiedostojärjestelmän palauttaminen on helppoa. Vanhat pois (tai talteen) ja varmuuskopio tilalle.

rm -rf *
mv ../kaikki_tiedostot.tar.gz .
tar -zxvf kaikki_tiedostot.tar.gz .

Tietokannan palauttaminen on cPanelin valvomassa ympäristössä hieman konstikkaampaa. Kirjaudu cPanelin MySQL-sivulta phpMyAdminiin ja jätä cPanelin MySQL-sivu auki. phpMyAdminin käyttäjällä ei ole oikeutta drop database -lauseeseen, eikä tästä syystä phpMyAdminin rename database -toimintokaan toimi. Tietokanta pitää siis poistaa cPanelin MySQL-sivulta. Kun tietokanta on poistettu, se on luotava tyhjänä (ja tietenkin saman nimisenä) uudelleen, jälleen cPanelin kautta. Tämän jälkeen tietokantaan liitetään sama käyttäjä kuin sillä aiemminkin oli, jonka jälkeen phpMyAdmin on taas toimintakykyinen. Tietokannan varmuuskopion voi palauttaa valitsemalla (tyhjän) tietokannan ja Import. Sivulla on lomake omalla työasemalla olevan kopion lähettämiseen.

Ongelma tietokannan palauttamisessa

phpMyAdminista otettu varmuuskopio ei kuitenkaan ole suoritettavissa cPanelin alaisuudessa toimivasta phpMyAdminista. Syynä on create database -lause, jonka phpMyAdmin lisää Export-toiminnossa tietokantaotteeseen. cPanelissa tätä lausetta ei saa tietokannan käyttäjätilien oikeuksiin. Lausetta ei tässä vaiheessa tarvitakaan, koska loimme aiemmin tyhjän tietokannan cPanelin kautta. Muokataan siis omalla työasemalla olevaa tietokantakopiota.

Jos tiedosto on gzipattu, se pitää ensin purkaa:

gunzip tietokanta_dump.sql.gz

Avaa tiedosto vimillä tai muulla tekstieditorilla ja poista tai kommentoi tiedoston alkupuolella oleva rivi

CREATE DATABASE `mydatabase` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;
USE `username`;

Tallenna tiedosto ja käytä phpMyAdminin Import-toimintoa uudelleen. Tiedoston lähettäminen ja tietokannan kirjoittaminen kestää hetken aikaa. Jos skandien tai euromerkkien ja muiden jenkkien mielestä epästandardien merkkien kanssa on ongelma, tietokannan palauttamista voi kokeilla määrittämällä Import-sivulta käytetyn lokaalin toiseksi.

In meinen Kursen “Betriebliche Informationssysteme/Business Applications” (beide auf Englisch), die durch ein Internet-Blog unterstützt wurden, fanden in der letzten Woche Abschlusspräsentationen der Studenten statt: 13 erstaunliche professionelle blog-basierte Studentenprojekte wurden von den insgesamt 65 Studenten im Verlauf des Semesters erstellt, und umfassen Lernmodule, Info- und Community-Sites.

Die Lernkurve der Studenten war durchweg steil: in drei Monaten mussten die Studenten die folgenden Techniken und Prozesse meistern:

• Projektmanagement in Teams von 4-6 Studenten
• WordPress blogging Software – drei Teams stellten sich sogar den erweiterten Anforderungen von self-hosted blogs auf meinem eigenen Server
• Forschungsfragen formulieren und erarbeiten – in so weit auseinanderliegenden Bereichen wie Bewerbungsstrategien, Saubere Energien, Wahlinformationen 2009, Informationen zu Reisen, Geschlechterorientierung, Poker, Gewaltfreier Kommunikation… u.v.a.m.
• Professionelle Präsentation ihrer Themen und der Autoren auf dem Internet
• Usability-Prüfung und Beziehungsmanagement mit existierenden und potentiellen Lesern der Blogs
• Team- und Gruppendynamik

Trotz des übervollen Semesterplans, den wir diesen jungen Menschen zumuten (unvergleichbar den Erfahrungen, die ich selbst als Student vor 20 Jahren gemacht habe) schafften es alle Studenten, ihre Aufgaben selbstorganisiert, vollständig und professionell zu lösen – ich bin sehr stolz auf ihre Leistungen!

In den meisten Fällen sind die Bloginhalte aktuell, interessant und einzigartig. Viele dieser Blogs könnten leicht wachsen und sogar von kommerziellem Interesse sein, wenn ihre Autorenteams es schaffen, größere Nutzergruppen zu erreichen – eine spannende Herausforderung für diejenigen, die sich ihr stellen mögen.

Alle Studenten beherrschten ihre Software (WordPress) gut – dank der individuellen Blogs, die ebenfalls überwiegend sehr eindrucksvoll ausfielen. Trotzdem war die Meinung der Mehrheit, dass die Teamprojekt-Seiten als Content Management Systeme besser ausgefallen wären – CMS wie Drupal bieten mehr Möglichkeiten, den Content interaktiv zu gestalten, Nutzerdialoge zu führen (z.B. durch Foren), und vorhandene Inhalte zu taggen.

Ein Ende des ersten Erfahrungsabschnitts – aber nur der Beginn einer langen, spannenden Reise!

m birkenkrahe

OSSCube Joins Acquia Gold Partner Program
BigNews.biz (press release)
OSSCube has received substantial and sustained recognition for its Drupal technology solutions, and is fully committed and fully equipped to deliver ...
OSSCube Joins SugarCRM Gold Partner And SugarCRM Authorized ...BigNews.biz (press release)

all 8 news articles »

New Drupal security updates available
CMS Critic
There are two new security updates available for Drupal. One for the 5.x series and one for the 6.x series. These updates are in response to a security ...

and more »

Drupal’s i18n module can translate block contents. To display blocks in multiple languages, yo

In this step, we’ll select which types of content need to be translated. Navigate to /admin/co

Tavoitteena on muuttaa erittäin hitaasti toimivat, kehitysvaiheessa olevat verkkosivut julkaisukuntoon. Alustana sivuilla on Drupal 6, tietokantahaut on toteutettu Viewsillä ja aseteltu nodeihin block-osioihin kirjoitetuilla views_embed_view()-funktioilla. Muita moduleita ovat CCK, Date, ImageField, I18N, ICME ja TinyMCE.

Aloitustilanteessa verkkosivut ovat periaatteessa valmiit ja niillä on jonkin verran sisältöä, joka on pääasiassa tekstiä ja muutamia pieniä kuvia. Sivut on siirretty palvelimelle, jossa ne on tarkoitus siirtää tuotantoon. Sivunlataus kestää keskimäärin uskomattomat 15 sekuntia. Palvelimella muistia riittää ja rasitusaste on lähellä nollaa.

Ensimmäinen ja helpoin tapa nopeuttaa toimintaa on kääntää Drupalin oma välimuisti päälle. Asennuksen yhteydessä tulin kuitenkin ensin tarkistaneeksi MySQL:n konfiguraation, josta puuttui tietokannan välimuisti kokonaan. Asetustiedosto on nimeltään my.cnf ja se löytyy tavallisesti /etc -hakemistosta.

cat /etc/my.cnf

Konfiguraatio näkyy ruudulla. Jos parametrit query_cache_type, query_cache_size tai query_cache_limit puuttuvat, ne kannattaa pikapikaa lisätä. Query_cache_type määrittää, onko tietokannan välimuisti päällä. Arvo 1 on päällä, arvo 0 pois päältä ja arvo 2 on päällä vain silloin kuin suoritukseen tuleva SQL-lauseke ehdottaa välimuistin käyttöä. Perus-Drupalin kanssa arvo 1 on sopiva ja voisi myös sanoa että välttämätön. Query_cache_size on välimuistille varattava koko. Suuruus riippuu sivustoista mutta olen käyttänyt arvoa 40 (MB) ja hyvin on tultu toimeen. Query_cache_limit on arvo megabitteinä, minkä suuruiset haut korkeintaan tallentuvat välimuistiin. Oletusarvona on 1 MB, joka lienee käytössä kirjoittamattakin. Drupalin kanssa 1 MB sopii meille. Lisää/korjaa rivit my.cnf:iin käyttämällä vimiä tai muuta tekstieditoria.

query_cache_type=1
query_cache_limit=1
query_cache_size=40

MySQL:n pitää vielä lukea asetukset uudelleen, jotta muutos astuu voimaan:

/etc/init.d/mysql reload (tai restart jos reload ei toimi)

Testisivumme puolittivat juuri sivunlataukseen kuluvan ajan. 7,5 sekuntia on edelleen kelvoton tulos, joten lisätoimia tarvitaan. Palataan takaisin yleensä ensimmäiseksi suoritettavaan vaiheeseen, eli Drupalin oma välimuisti päälle. Asetus löytyy kohdasta admin/settings/performance tai Administration -> Site configuration -> Performance. Caching modeksi kannattaa yleensä laittaa normal ja kaikki pakkausvaihtoehdot päälle, eli Page compression enabled, Block cache enabled, Optimize CSS files enabled ja Optimize JavaScript files enabled. Huomaa, että tämän jälkeen lähdekoodiin tai blockkeihin tehdyt muutokset eivät välttämättä tule näkyviin ennenkuin tältä samaiselta Performance-sivulta on käyty klikkaamassa Clear cached data -nappia.

Tehdään asetusten tallennus ja uloskirjautuminen, Drupalin pääkäyttäjälle (nid 1) ei koskaan tarjoilla välimuistissa olevia sivuja joten sivujen kokeilu pitää suorittaa anonyyminä käyttäjänä tai muuna sisään kirjautuneena käyttäjänä. Pienen klikkailun jälkeen voidaan todeta, että sivut ovat nopeutuneet, mutta sivunlatausaika vaihtelee edelleen 2,5 sekunnista reilusti yli viiteen sekuntiin.

Boosterit käyttöön

Viisi sekuntia jokaisen sivun aukeamiseen ei todellakaan ole tyydyttävä tulos. Tietokantayhteys on nyt kunnossa ja Drupal käyttää oikopolkuja sivun muodostamiseen. Mitä voimme vielä tehdä?

Flowchart

Ylläoleva kuva on napattu ilman lupaa Drupal.orgista ja muiden tietojen puutteessa sen tekijä lienee Jonah Ellison (linkki lähteeseen).

Kuva havainnollistaa loistavasti, miten Authcache-moduli nopeuttaa sivunlatausta. Sivuista tallennetaan HTML-versiot, jotka ovat valmiina lukua varten. Tällaisen toiminnon tuottavia moduleita on useita. Authcache on siitä erilainen, että tässä on mahdollista suorittaa tietokantahakuja sivunlatauksen jälkeen JavaScriptin avulla. Näin HTML-kopioita voidaan käyttää myös sisäänkirjautuneiden käyttäjien palvelemiseen.

Authcache on kuitenkin melko monimutkainen ottaa käyttöön, joten tässä käytämme yksinkertaista Boost-moduulia. Boost tekee sivujen juurihakemistoon cache-kansion, johon tallentuu HTML-versiot kaikista sisäänkirjautumattomien käyttäjien, tässä tapauksessa kaikkien sivujen käyttäjien ylläpitäjää lukuun ottamatta, avaamista sivuista.

Boostin asennuksessa on muokattava sivujen juurihakemistossa olevaa .htaccess-tiedostoa. Asennus sujuu näin:

1. Lataa ja pura Boost-moduuli modules-kansioon ja ota se käyttöön Drupalin moduulisivulta
2. Luo juurihakemistoon kansio cache ja tämän sisään kansio omadomain.fi
3. Anna cache/ ja cache/omadomain.fi/ -kansioihin sopivat käyttöoikeudet Drupalia pyörittävälle käyttäjänimelle (esimerkiksi chown -R omadomain:omadomain cache ja chmod -R u+rwx cache)
4. Mene Boostin asetuksiin, jotka löytyvät Performance-sivulta
5. Kopioi .htaccess-asetukset leikepöydälle
6. Muokkaa .htaccess-tiedostoa (joka löytyy kohdasta omadomain.fi/.htaccess) ja liitä Boostin asetukset oikeaan kohtaan.
7. Käynnistä Boost sen Drupalin asetussivulta
8. Kirjaudu ulos ja kokeile sivujen toimintaa

Ensimmäinen sivunlatauskerta anonyyminä käyttäjänä ei eroa tavallisesta sivunlatauksesta. Seuraavissa nopeusero tulee näkyviin: sivunlataus kestää keskimäärin 1,4 sekuntia! Tällä vauhdilla sivut voi hyvillä mielin julkaista.

Boostin asennukseen liittyen cronjobin toimivuus pitää vielä tarkistaa. Cron virkistää HTML-versiot sivuista normaalin cron-ajon tahtiin. Boost neuvoo asettamaan /sites/default/settings.php -tiedoston base_url-muuttujalle arvon, jos ongelmia esiintyy.

Being Open About The Open Source Drupal URL Vulnerabilities
pc1news
Having said this, multiple vulnerabilities have been discovered in Drupal. Drupal is a wonderful open source content management platform. ...

and more »

CTI creates site for Lifeshare charity
How Do
The new website has been designed to attract interest and volunteers and uses a Drupal-based platform to enable the charity to develop revenue streams and ...

and more »

Drupalilla tehdyt verkkosivut takkuilevat? Yksinkertaisimmatkin sivut latautuvat todella hitaasti? Sivun välimuisti on päällä ja vauhti paranee, mutta nopeutta pitäisi silti saada lisää?

Drupal on erittäin monikäyttöinen alusta kaikenlaisiin verkkosivuihin. Monipuolisuudesta seuraa tekninen monimutkaisuus ja Drupalilla toteutetut verkkosivut saattavat käyttää vain murto-osaa kaikista ohjelmiston tarjoamista ominaisuuksista. Normaalin sivunlatauksen yhteydessä palvelimella tapahtuu vaikka mitä, joista moni toiminto voisi jäädä tavanomaisen sivunlatauksen kohdalla käyttämättäkin.
Normaalisti palvelimen muisti riittää pyörittämään Drupalia riittävän nopeasti, jotta sivunmuodostuksen vaatima aika pysyy pienenä. Pullonkaulana sivun muodostusajassa on tietokantahaut. Drupal voi käyttää normaalin noden muodostamiseen 20 tietokantahakua, jos tietokantayhteydet eivät ole kunnossa, sivujen muodostaminen voi kestää ikuisuuksia.

Työkaluja nopeuden seuraamiseksi

Nopeuden viilaaminen on parasta aloittaa kellottamalla sivunlatausten kestoja. Vaikka pääasiallisena huolenaiheena on tarkastella sekunnin ja pidempien aikojen hidastumisia, jotka voi havaita silmämääräisestikin, nopeuden mittaaminen siihen tarkoitetuilla ohjelmilla on varmempaa. Joskus hitaushan voi johtua käytetystä työasemasta, jonka takkuilulla ei ole mitään tekemistä sivunlatauden vaatiman ajan kanssa.

Drupalin Devel-moduuli on Drupalin sisäisten toimintojen mittaamiseen käytettävä ohjelma. Develillä saa monenlaista muutakin infortaatiota sivujen muodostumisesta, mutta yksinkertaisimmillaan sillä saa näkyviin sivun rakentamiseen kuluneen ajan. Tämä aika on nimenomaan se aika, joka alkaa Drupal saadessa sivupyynnön ja loppuu Drupalin ilmoittaessa sivunluonnin olevan valmis. Välissä on tavallisesti toistakymmentä tietokantahakua. HTTP-kutsuja ei käsittääkseni tähän aikaan tule.

YSlow on Yahoon kehittämä ilmainen lisäosa niinikään ilmaiseen Firebug-sovellukseen. Devel on hyödyllinen tutkittaessa Drupalin sisäistä toimintaa, mutta varsinaiset tiedot sivunlataukseen kuluneista vaiheista voidaan selvittää vain selaimesta kellottamalla. YSlow on tehty juuri tähän ja lisäksi se osaa neuvoa, millaisia hidastavia tekijöitä kuhunkin sivuun liittyy. YSlow tarvitsee Firebug-ohjelman, joka puolestaan toimii vain Firefoxissa. Ilmaisia kaikki ja saatavissa miltei kaikille alustoille.

Asennuksen jälkeen YSlow ilmestyy Firefoxin oikeaan alalaitaan, josta klikkaamalla ohjelma avaa ikkunan osittain sivun päälle. Ikkunasta voi käynnistää selaimessa parhaillaan auki olevan sivun tarkastamisen. Tarkastuksen jälkeen YSlow antaa sivulle nopeuteen ja tekniseen esteettömyyteen perustuvan arvosanan (numero), arvosanan teknisen toteutuksen laadusta (kirjain) ja listaa puutteet sivunlataukseen vaikuttavista tekijöistä ja neuvoja niiden korjaamiseksi. Valtaosa sivuista saa YSlowilta arvosanan 70…79. Google.fi saa 99, nethack.org 97. 71 tai alle on niin hidas sivu, että surffaaja ehtii jo ärsyyntymään. Hitauden sietäminen on tietenkin suhteellista, mutta tavoitteena pitäisi kaikkien sivujen kohdalla päästä vähintään arvoon 75-80. Kunnollisella palvelimella olevan, pelkkää validia HTML:ää sisältävän sivun tulisi päästä 90 yläpuolelle ilman optimointia.

Toivon, että pystyn kirjoittamaan Drupalin nopeuttamisesta monta artikkelia. Käytössä on tällä hetkellä Drupal 6.12 ja ensi vuonna tilanne tullee muuttumaan Drupal 7:n myötä. Sivunlatauksien nopeuttamiseksi tulee jatkuvasti uusia tekniikoita, kuten äskettäin ymmärtämäni, jännittävän niminen CSS Sprite -menetelmä. Lisää aiheista seuraavassa artikkelissa. Tähän vielä pari hyödyllistä linkkiä:

http://wimleers.com/article/improving-drupals-page-loading-performance
http://2bits.com/articles/tips-on-speeding-up-your-drupal-sites.html

castelo_robert posted a photo:

Mark Baker, MySQL Marketing Manager UK at Drupal For Publications, Sun Microsystems, London 2009

castelo_robert posted a photo:

Mark Baker, MySQL Marketing Manager UK at Drupal For Publications, Sun Microsystems, London 2009