Intereting Posts

Устранение конфликтов имен плагинов с WP updater

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

Я пытаюсь выяснить, что именно нужно изменить, чтобы это не происходило в будущем. В рассматриваемом плагине не было особо уникального идентификатора в именах каталогов / основных файлов; Представьте, что это так:

foo/foo.php 

Поэтому, если в репозитории уже есть плагин «Foo», понятно, почему WP будет путать их.

Мое понимание в прошлом заключалось в том, что избежать этого было, поместив уникальный идентификатор в эти имена, например:

 client-foo/client-foo.php 

Полагаю, что добавление бита «клиент» – это способ уменьшить вероятность столкновения, сделав плагин определенным для одного сайта WordPress, который его запускал.

Однако даже после переименования файлов я обнаружил, что программа обновления по-прежнему путала плагин с плагином «foo» в репозитории.

Затем я попытался изменить поле «Имя» в заголовке метаданных плагина, начиная с

 Plugin Name: Foo 

в

 Plugin Name: Foo (Client) 

И это, казалось, устранило столкновение; обновитель больше не помечен как соответствующий публичному плагину.

Так что теперь я смущен. Неужели это единственное, что проверяет обновление, чтобы избежать столкновений, это поле метаданных имени плагина? Это кажется очень хрупким по сравнению с тем, как я думал, что он это делает (сравнивая имена файлов), по крайней мере, со мной.

Во всяком случае, я не смог найти окончательное слово о том, какую информацию использует программа обновления, чтобы сделать эту проверку, и пока я нашел этот ранее заданный вопрос, нить ответа не выйдет и сказать «вот как это работает. " Поэтому я подумал, что спрошу.

Способ использования WordPress для поиска плагина в репозитории не является общедоступным AFAIK.

Согласно ответу Отто, который вы связали, он включает заголовок url ​​плагина вместе с именем плагина.

BTW, удалите плагин из списка плагинов для обновления, это лучший способ гарантировать, что эта проблема не повторится: если метод сопоставления не является общедоступным, вы не можете знать, будет ли он изменяться в будущем.

Поскольку логика, используемая для обновлений из официальных репозиториев, является нечеткой и точной информацией, хранится в секрете – невозможно надежно уклониться от нее, просто манипулируя деталями.

На данный момент единственной надежной практикой является отфильтровать данные из набора, отправленного для проверки обновлений. Даже это очень неудобно и должно выполняться на уровне запросов HTTP API. Одна из связанных проблем заключается в том, что если плагин исключает себя, он не может сделать это, когда он неактивен и по-прежнему рискует быть уничтоженным обновлением в этом случае.

Лично я написал для этого помощника Update Blocker . На более серьезных сайтах я бы рекомендовал полностью убить обновления и управлять сайтом с помощью Composer.

В то время как проект WP в целом согласен с тем, что это проблема (которая длилась буквально в течение нескольких лет ), билет, предлагающий флаг отказа от заголовка, был приостановлен на некоторое время, требуя обновлений на сайте сайта WordPress. См. Билет № 32101 в основном трейлере .