Как настроить плагин, сохраняя возможность обновления

В настоящее время я работаю над серьезным обновлением одного из моих плагинов WordPress.

Плагин позволяет пользователю выбирать из нескольких доступных скинов. Довольно часто меня просят создать собственный скин. Чтобы предотвратить удаление этого скина при обновлении, я должен использовать ловушку WordPress, чтобы отключить автоматические обновления для плагина. Это явно не идеально, так как я бы хотел, чтобы они все еще могли обновлять плагин. Проблема в том, как WordPress обрабатывает обновления - он просто удаляет папку плагина и устанавливает новую версию. Таким образом удаляя файлы, которые на самом деле не были частью старой версии.

В настоящее время единственный способ обойти это - иметь две папки скинов - одну в папке плагинов и одну в папке загрузок - действительно ли это единственный способ, которым я могу предложить это своим пользователям?

Многие плагины используют /wp-content/custom-plugin-folder/для хранения пользовательских плагинов (на ум приходит WPTouch).

Просто используйте константы WP_CONTENT_URLи WP_CONTENT_DIR ^{документы} для проверки существования вашей папки и получения любых доступных скинов.

Следующая статья, хотя и не имеет прямого отношения к этому Вопросу, объясняет важность плагинов / тем для поиска переводов сначала в wp-content/languagesпапке перед загрузкой собственных упакованных .moфайлов. Это стоит прочитать, и, надеюсь, вы примените концепцию в следующем выпуске :)

Как правильно загрузить языковые файлы WordPress, я хотел бы отметить, что важно загружать пользовательские языковые файлы пользователя из WP_LANG_DIR, прежде чем загружать языковые файлы, поставляемые с плагином . Когда несколько mo-файлов загружены для одного домена, будет использован первый найденный перевод. Таким образом, языковые файлы, предоставляемые плагином, будут использоваться в качестве запасного варианта для строк, не переведенных пользователем.
^{http://www.geertdedeckere.be/}

Другой способ состоит в том, чтобы люди добавили свой собственный плагин. Например, код в вашем основном плагине, который получает скины, может выглядеть примерно так:

function get_available_skins() {
    $skins[] = '/includes/default-skin.css';
    $skins[] = '/includes/2012-skin.css';

    return apply_filters( 'get_available_skins', $skins );
}

Затем пользователи могут создать собственный плагин, который стоит рядом с вашим (активируется отдельно, чтобы он не мешал вашему обновлению), который выполняет следующие действия:

add_filter( 'get_available_skins', 'my_custom_skin' );
function my_custom_skin( $skins ) {
    $skins[] = '/my-custom-skin.css';

    return $skins;
}

Это точно так же, как WordPress использует хуки, чтобы сделать себя расширяемым. Не изобретай велосипед.

_{(Очевидно, я не знаю, с каким плагином вы работаете, как выглядит пользовательский скин или как у вас закодированы вещи, поэтому вам придется использовать приведенный выше код просто в качестве модели того, как вы можете реорганизовать ваш собственный код.)}