Obecnie pracuję nad modułem, który wymaga biblioteki PHP innej firmy, która jest w zasadzie pojedynczą klasą PHP. Zwykle umieszczałbym go w podkatalogu include / i dodaje
files[] = includes/Foo.php
do mojego pliku .info i pozwól, aby auto-moduł ładujący klasy Drupal 7 zrobił to, co robię $foo = new Foo()
.
Mam jednak pozwolenie na upublicznienie tego modułu i wolę nie dołączać biblioteki z modułem. Zdaję sobie sprawę z komplikacji związanych z licencjonowaniem, ale ze względu na to pytanie chciałbym je zignorować.
Podobne pytanie brzmi: jak dołączyć bibliotekę PHP? , ale tak naprawdę nie sądzę, że to odpowiada na mój dylemat.
To odpowiedzi na to pytanie w zasadzie powiedzieć użyć API bibliotek , ale każdy pojedynczy moduł, który znalazłem, że używa tego właśnie robi libraries_get_path()
, aby uzyskać basePath (i zawiera ścieżkę awaryjnej, gdy nie jest dostępny), a następnie robi require
lub include
niektóre sprawdzanie błędów (lub nie). Wszyscy robią coś takiego:
if (!class_exists('Foo')) {
$path = function_exists('libraries_get_path') ?
libraries_get_path('foo') : 'sites/all/libraries/foo';
if (!include($path . '/Foo.php')) {
// handle this error
}
}
W tym przypadku interfejs API bibliotek naprawdę nic nie robi. Nie widzę korzyści z używania tego, w porównaniu ze starą metodą proszenia użytkowników o pobranie kopii i umieszczenie jej w samym folderze modułu. A, jest jeszcze kwestia, że deweloper moduł nadal musi ręcznie zrobić obciążenie z include
/require
. Na przykład moduł Facebooka po prostu ładuje bibliotekę do hook_init
a moduł HTML Purifier ma wewnętrzną funkcję sprawdzania i ładowania za każdym razem, gdy biblioteka jest potrzebna.
Może to być powszechna praktyka, ale nie wydaje się najlepsza praktyką.
Czy mój moduł powinien przejąć inicjatywę i zadeklarować hook_libraries_info
, żebym mógł z niej skorzystać libraries_load('foo')
? To też wydaje się dziwne.
if (libraries_load($name)) {..}
jest uniknięcie WSOD w przypadku braku biblioteki.