Az 5.x Drupalhoz nincs még acidfree modul!

Általánosságban elmondható, hogy mindig az install/install.txt/readme fájlokat kell elolvasni. Pl a 4.7-es acidfree csomagban a readme fájlban a következő van:

1. install the filemanager module from the drupal modules page and set it up
(this includes creating the table, setting paths, creating directories, etc.
on the admin/settings/filemanager page)

2. untar acidfree directory into your modules directory
3. enable the acidfree module on the admin modules page
4. go to http://yoursite.dom/acidfree/test (or
http://yoursite.dom/?q=acidfree/test) to check your install and settings.
Follow any instructions it offers.
5. create albums and content!!

vagyis:
1 installáld a filemanager modult, hogy hogyan az ott van leírva ;)
2. másold az egész cuccot a modules könyvtárba
3. kapcsold be az acidfree modult. (ez az amit nem tudsz megtenni, ha 5.x-es Drupal-t használsz, ugyanis nincs portolva az acidfree 5.x-es Drupalra, tehát meg se kíséreld telepíteni, amíg ki nem jön az 5.x Drupalra való verzió!)
4. irány a az ...acidfee/test cím
5. csinálj albumokat.

pp

Nehéz kérdés, mert a teljesítmény függ a telepített moduloktól, valamint attól is, hogy az ember be van jelentkezve, vagy sem.

A kérdés az, hogy van-e olyan modul, ami extrém módon terheli a rendszert. Egy rosszul megírt algoritmus ilyenkor "csodákat művelhet". Tudok mondani 3 algoritmust, ami ugyan azt csinálja de a futási idő n függvényében a következő képen alakul: 2^n, C*n, C

Ez 10 elemnél rendre: 1024, C*10, C
1000 elemnél rendre: beláthatatlanul nagy szám nagyságrendileg 10^100, C*1000, C
A C egy tetszőleges pozitív 1-nél nagyobb szám. Amint látható az első megoldás már viszonylag kis elemszámnál is kvázi végtelen futásidőt jelent, míg a második és a harmadik nem.

Az ilyen hibás algoritmusokat igyekeznek elkerülni a Drupal-ban, de ez nem jelent garanciát arra, hogy minden modulban ugyan ezt teszik.

A node-ok és a tábla sorok számától meg egyértelműen függ az, hogy mennyi idő alatt kapod meg az eredményt, ezért is bontották szét a cache táblát több táblára, hisz régen csak egy tábla volt és ez eléggé terhelte a rendszert. Az se véletlen, hogy az adatbázis oszlopokra indexeket és elsődleges kulcsokat illik definiálni. (az előző példához hasonló eredmények miatt.)

Lebegjen szemünk előtt mindig a Légrádi féle felismerés:

Bármilyen gyors gépre lehet lassú programot írni

pp

Van erre egy szép mondás, a tíz milliárd légyről...Merthogy ennyi légy nem tévedhet.

Imádom ezt a hozzáállást, ezért dagasztja minden fejlesztő kényszeresen a sza**. Még jó, hogy egy Google képes meglépni azt, amit a fejlesztők nem (persze, van különbség). Nyilván egyről a kettőre nem ignorálhatja az ember az IE-t, én azért mégis mindenkinek tolmácsolom folyamatosan, hogy az IE maga a dögrovás. A saját érdekem is, hogy minél kevesebbet használják, de még a felhasználó is mosolyogva áll fel a géptől, ha úgy lát egy oldalt, ahogy azt valójában megtervezték.

A Microsoft technikai támogató csapata szerint itt az ideje, hogy a webfejlesztők és rendszergazdák megkezdjék oldalaik és honlapjaik felkészítését az Internet Explorer következő kiadására. A weblapok frissítésére azért van szükség, mert az Internet Explorer 8 szakítva - a Microsoft eddigi hagyományaival - a visszafelé-kompabilitás helyett inkább a szabványkövetést részesíti majd előnyben, így a nem várt módon fog jeleníteni számos, a böngésző korábbi verzióira optimalizált oldalt.

Készítsük fel oldalainkat IE8-ra, ez meg az évezred vicce, mint új fícsör.

Mostanában becsúszik egy-egy off. Elnézéseteket kérem érte.