Drupal 7: Rozwiązanie problemu "Nie działa wysyłanie emaili dla formularzy Webform"

Wcześniej zainstalowałem moduły "Mail System", "Mime Mail" i "HTML Mail", aby portal mógł wysyłać mejle w formacie HTML. Chodziło mi głównie o mejle Drupal Commerce, gdzie w potwierdzeniu zamówienia chciałem mieć tabelkę z produktami. Jeszcze wcześniej miałem zainstalowany moduł SMTP Authentication Support, dlatego aby to działało należało w Mail System skonfigurować nową klasę MimeMailSystem__SmtpMailSystem, którą ustawiłem dla wszystkich klas:
Site-wide default
HTML Mail module
Mime Mail module

Następnie zainstalowałem moduł Webform, aby dodać do strony swój formularz kontaktowy.
Jak się okazało formularz za nic nie chciał wysyłać mejli.

Dzięki rozwiązaniu opisanemu na forum Drupala udało się to naprawić (wpis #109):
https://drupal.org/comment/6811066#comment-6811066

Musiałem dodać nową konfigurację dla klasy Webform module i mejle zaczęły się wysyłać:

Bardzo ważne, aby pozostawić puste pole dla klucza. Początkowo podałem jaki klucz (zamazana konfiguracja) i mejle się nie wysyłały. W ustawieniach adresów e-mail w webform w sekcji "E-mail header details" wszystkie trzy podałem jako Własne (E-mail subject, E-mail from address, E-mail from name). Nie wiem, czy to miało znaczenie.
Na wszelki wypadek w głównej konfiguracji Webform settings pozostawiłem puste pole "From name". Gdzieś czytałem, że to też może być źródło problemów.

Drupal Commerce: Własny atrybut zamówienia (moduł Commerce Fieldgroup Panes)

Polecam moduł rozszerzający zamówienie (order). Nowy atrybut może być używany podczas procesu zamawiania (checkout) i wykorzystywany w widokach.

Moduł Commerce Fieldgroup Panes (drupal.org):
https://drupal.org/project/commerce_fieldgroup_panes

Tutorial:
http://commerceguys.com/blog/commerce-module-tuesday-commerce-fieldgroup-panes-screencast

Drupal Commerce: tłumaczenie dla "Order total", "Billing information" i innych

Powszechny problem Drupal Commerce polega na tym, że nie można przetłumaczyć niektórych  etykiet (pól). Pół biedy jeszcze z formularzami - tutaj można napisać hak. Gorzej np. z podglądem zamówień. Po wielu dniach poszukiwać znalazłem rozwiązanie.

Najpierw natknąłem się na wątek:
http://www.drupalcommerce.org/discussions/2730/how-translate-order-total-checkout

Który doprowadził mnie do satysfakcjonującego rozwiązania:
https://drupal.org/node/1451132#comment-5984944

Błąd podczas update'u Drupala (Failed: DatabaseSchemaObjectExistsException)

Podczas aktualizacji Drupala (update.php) spotkałem się z błędem:
 
The following updates returned messages

dblog module

Update #7002
Failed: DatabaseSchemaObjectExistsException:
Nie mogłem utworzyć indeksu <em class="placeholder">severity</em> dla tabeli <em class="placeholder">watchdog</em>:
indeks już istnieje. w DatabaseSchema_mysql->addIndex() (linia 437 z /var/www/html/includes/database/mysql/schema.inc).

Na szczęście znalazłem prosty sposób na naprawienie tego błędu. Oto procedura, którą znalazłem w Internecie i która pomogła

The watchdog table is created by the optional core dblog module's dblog.install file. If the watchdog table becomes corrupted and cannot be repaired with phpMyAdmin or MySQL's command line utilities (it happens) you can easily recreate the watchdog table by cycling installation of the dblog module, as follows:
1) put site in offline mode (admin/settings/site-maintenance)
2) disable the dblog module (admin/build/modules)
3) uninstall the dblog module (admin/build/modules/uninstall)
4) re-enable the dblog module (admin/build/modules)
5) run /update.php to check for errors, and
6) put site in on-line mode (admin/settings/site-maintenance).
If desired, use phpMyAdmin or MySQL command line utilities to verify the watchdog table has been recreated.

Auto-uzupełniany filtr dla widoku

Dla widoków (Views) można tworzyć filtry, które będą pokazywane użytkownikom. Robi się to w sekcji widoku Filter Criteria:

Aby taki filtr stał się widoczny należy zaznaczyć checkbox "Expose this filters to visitors, to allow them to change it". Warto również zainstalować dodatkowy moduł Views Autocomplete Filters (zobacz tutorial). Dzięki niemu pole filtra będzie podpowiadać użytkownikom, co mogą wpisać.

Działa to bardzo dobrze. Polecam szczególnie do filtrowania danych dla dużych tabel.

Filtr ostatecznie wygląda tak:

Moduł Glossify versus Taxonomy tooltip w Drupalu 7

Dostałem ostatnio wymaganie, aby na stronie wykonanej w Drupalu 7 trudne pojęcia i terminy w treści były jakoś specjalnie oznaczone, ich wyjaśnienie pokazywało się w "dymku", a ponadto mają być zebrane wszystkie w jednym miejscu. Tym miejscem miał być tzw. glosariusz.

Aby rozwiązać to zadanie najpierw spróbowałem poszukać gotowego modułu. Natknąłem się na porównanie kilku takich modułów:

https://drupal.org/node/266511

Według mnie interesujące wydawały się:

https://drupal.org/project/glossify

https://drupal.org/project/lexicon

Zainstalowałem glossify i utworzyłem własną kategorię pojęć (taxonomy) z listą terminów, którą podczepiłem do swojego filtru z edytorem CKEditor. Zadziałało bez problemów. Okazało się jednak, że wyjaśnienia (tooltip'y) są pokazywane za pomocą standardowego atrybutu html title. Moje opisy miały być długie, więc takie rozwiązanie wydało mi się zbyt proste. Odinstalowałem więc glossify i zacząłem szukać czegoś podobnego dalej.

Wreszcie znalazłem inny ciekawy moduł Taxonomy tooltip:
https://drupal.org/project/taxonomy_tooltip
Szczegółowy opis użycia można znaleźć tutaj:
http://webwash.net/tutorials/using-taxonomy-tooltip-module-drupal-7

Od razu mnie ucieszyło, że mogę skorzystać z już wcześniej utworzonej kategorii pojęć.
Ponadto działanie modułu oparte jest na pluginie jQuery o nazwie jQuery Tooltip.
Dymki można więc ostylować i umieścić w nich dużo treści.
Glosariusz można natomiast wykonać za pomocą zwykłych widoków (Views) prezentując odpowiednio kategorię pojęć.

Niepoprawna kolejność komunikatów walidacji podczas rejestracji (Sort before element validation Patch)

Istnieje błąd w Drupalu polegający na tym, że komunikaty po walidacji formularza niekoniecznie są pokazywane w dobrej kolejności. Przykładowo, jeśli w formularzu rejestracji użytkownika dodamy kilka dodatkowych pól i zmienimy ich kolejność wyświetlania to komunikaty walidacji nie będą właściwie posortowane. Niestety jest to błąd rdzenia Drupala (konkretnie w pliku /includes/form.inc) i wymaga zastosowania Patch'a.

Patch: https://qa.drupal.org/pifr/test/388683

Instalacja Patch'a może polegać na prostej edycji pliku form.inc
(przykład ręcznej instalacji innego patcha: http://www.ostraining.com/blog/drupal/patches/)

W pliku form.inc zamieniamy te 2 linijki:

-  // Recurse through all children.
-  foreach (element_children($elements) as $key) {

na tych 6 linijek:

+  // Recurse through all children, sorting the elements so that the order of
+  // error messages displayed to the user matches the order of elements in
+  // the form. Use a copy of $elements so that it is not modified by the
+  // sorting itself.
+  $elements_copy = $elements;
+  foreach (element_children($elements_copy, TRUE) as $key) {

a dalej następuje kod:

     if (isset($elements[$key]) && $elements[$key]) {
       _form_validate($elements[$key], $form_state);
     }