WPBG.org

Новини, събития, уроци за WordPress

Блог

Трябва ли да изтриете неизползваните плъгини/добавки от WordPress?

Posted on by Svetoslav Marinov

Краткият отговор е – Да, но не веднага.

В статията ще използвам термините:

плъгин/приставка/добавка/plugin, което представлява допулнителен модул, който се инсталира в WordPress, който добавя допълнителна функционалност в WordPress.

Може да се изкушите да изтриете някои от добавките, които може да изглеждат неизползвани, но е по-добре първо да ги деактивирате и да изчакате седмица или две, за да видите дали някоя част от вашия сайт ще спре да работи.

След като сайтът е разработен, обикновено след това почти не се пипа. Няма документация или описание кой плъгин за какво е бил ползван.

Точно поради тази причина е лесно да забравите за какво се използва даден плъгин.

Всеки плъгин добавя някакъв вид функционалност. Това е тяхната цел да надграждат функционалност върху WordPress.

Даден плъгин може би е използван като кратък код (shortcode) или да извикате някои функции на плъгина във файла functions.php на вашата тема, напр. от плъгина Advanced Custom Fields (ACF) функцията get_field().

Ако правите някое от нещата по-горе и деактивирате или изтриете плъгина, някои страници ще показват кратките кодове (напр. [some_plugin id=1234]), а в по-лошия случай сайтът вероятно ще спре да работи или ще покаже странна грешка.

Причината е, че WordPress съвсем логично не зарежда изцяло деактивираните плъгини. Те в повечето случаи не зареждат библиотеките си.

След 1-2 седмици, ако всичко е наред, можете да изтриете неизползваните плугини.

В идеалния случай е добре ползвате WordPress Sandbox услуга като WPSandbox или qSandbox, така може безопасно да правите тези промени и тестове без да рискувате да счупите сайта си. Това е критично, особено ако това е сайт за електронна търговия, където хората посещават сайта и правят поръчки.

Могат ли неактивните плъгини да изложат вашия WordPress сайт на атаки?

Обикновено не, защото деактивираните плъгините не се зареждат напълно, но това зависи от това как е написан всеки от тях. Тъй като част от кода все пак ще се зареди има известен риск. Ако приставката изпълнява някои действия, независимо дали е активна или не от основния файл на приставката и в този код има уязвимост, това ще направи и вашия сайт уязвим.

Неактивните приставки ще забавят ли вашия WordPress сайт?

Може би си задавате този въпрос и той е доста основателен. Да и не.

Отново, деактивираните добавки се зареждат само частично. WordPress чете основния файл на плъгина и това е всичко. Ако плъгинът прави допълнителни неща или проверява за валиден лиценз, тогава ще има въздействие върху производителността.

Как да изтрия неизползваните добавки?

Добре. Изчакахте известно време и сега е време за малко разчистване.

Отидете на: WP-Admin > Plugins (сайт site.com/wp-admin/plugins.php)

Под всеки деактивиран плъгин има бутон за изтриване. Трябва да щракнете върху него и да потвърдите и това е. Процесът на изтриване трябва да е доста бърз.

ако сте фен на WP-CLI, можете да изпълните тази команда (през SSH)

wp plugin uninstall --deactivate copy-delete-posts

Какъв шрифт да ползвате за своя WordPress сайт?

Posted on by helper

Можете да пробвате следните шрифтове. Ето как изтеглеждат те.

без достъп

Какво да направите, когато не можете да влезнете администрацията на WordPress

Posted on by helper

Вчера един от сайтовете ми не се държеше правилно. Бях сигурен на 200%, че паролата ми е правилна. Пробвах няколко пъти без успех. Даже си мислех да променя паролата през  командния ред. Потребителския профил, с който бях влязъл, имаше роля на редактор, но страницата за добавяне на нова статия изглеждаше сякаш текущата роля е на subscriber или contributor.

Оказа се, че на този сървър му е свършило дисковото пространство.

Това го видях като изписах на съвръва (linux) df -h и си показа 100% ползваемост.

Изтрих е няколко големи файла и успях да вляза в WordPress администрацията.

Ако дори и след освобождаване на пространство пак не можете да влезнете можете да пробвате с друг мой продукт с отворен код: Swiss Army Knife for WordPress (SAK4WP). С SAK4WP  можете да направите доста неща свързани с WordPress и едно от тях е да влезнете с определен потребител, дори и без да знаете паролата му, независимо дали е администратор или не.

Трябва само да качите един файл в директорията, където е WordPress през FTP или файлов мениджър.
Силно препоръчително е да изтриете файла след като сте си получили достъп до аднистрацията на WordPress.
В инструмента има бутон за самоунищожение.

code

Как да използваме WordPress.org API за търсене на добавки и теми

Posted on by helper

Знаете ли, че WordPress.org има JSON API, който можете да използвате, за да търсите WordPress поличите информация плъгини и теми?

Както винаги е добре да започнем със “защо”.

Какво бихме правили с данните от този API?

 

В моя случай имах нужда да вградя подсказки (auto suggest) за WordPress теми и плъгини. Един от бизнесите ми е qSandbox. Това е WordPress платформа за тестови сайтове, чрез която всеки може да си създаде тестов WordPress сайт или да импортира (изисква платен план) съществуващ такъв за секунди и да тества плъгини/теми или да разработва нова версия на сайта си.

В един от екраните има кутийка, в който хората могат да въведат информация и инсталират  плъгини или теми.
Инсталацията може да бъде направена като се зададе връзка частична връзка (WordPress slug) (orbisius-support-tickets) или директна връзка към zip файл за сваляне – https://downloads.wordpress.org/plugin/orbisius-support-tickets.zip

С тази функционалност целта ми беше да улесня моите клиенти, за да не трябва да търсят из компютъра си. Дори спестената секунда е добре.

Демо как съм използвал API на WordPress.org

demo-how-use-wordpress-org-api-search-plugins-themes-p62

Първата реализация беше доста неефективна, но частично работише. Търсенето беше лошо, тъй като търсенето се извършваше само по линк (в WP термин slug). За да стигна до списъка с темите и плъгините, трябваше да анализирам SVN хранилището. Дори създадох програмка, която да свали всички readme файлове от всеки плъгин (над 50,000!). Това си беше времеемеко и консумиращо ресурси, както моите, така и тези на WordPress.org.

Радвам се, че WordPress.org има API и реализацията беше доста лесна.

Ако вашата реализация е в контекста на WordPress, можете да проверите как WordPress използва своя API. Потърсете в кода на WordPress функциите plugins_api() и themes_api().

 

В моя случай ми трябваха само определен брой полета, които да бъдат върнати от API. Който е работил в WordPress.org API е осъзнал нещо готино, че не всички програмисти се нуждаят от всички полета. Така че wordPress.org API има параметър за полета, който можете да използвате, за да укажете кои полета да се върнат от API и кои не. Това води до по-бързи запитвания и отговор, тъй като ще се връщат и прехвърлят по-малко данни през интернет. Ще използвам тази идея в един от следващите ми REST API услуги.

 

код

Можете да намерите най-актуалната версия на кода на тази връзка.

https://github.com/orbisius/sample_wporg_api_client

 

 

Резултат

Това е, което АPI на WordPress.org върща на базата на търсените ключови думи.
Как и за какво ще използвате API на WordPress.org?

Как да коригираме PHP Warning: Declaration of … should be compatible with …. при WordPress разширенията/темите

Posted on by helper

Често срещаният проблем: PHP Warning:  Declaration of … should be compatible with ….  може да бъде лесно решен.

Ще се сблъскате с тази грешка, когато вашата хостинг компания прави обновявания на най-новата версия на PHP – 7. От една страна това е чудесно, защото ще разполагате с последния вариант на скриптовия език, но от друга – тази промяна носи със себе си и нежелани грешки.

Така изглежда wp-cli съобщението преди да бъде стопирана грешката.

И така след като вече е отстранена.

Друг недостатък на тази ситуация е, че въз основа на настройките за докладване на грешки, php може да покаже тези предупредителни съобщения на вашите потребители или във вашите log in файлове. Не е добра идея да изчерпваме свободното пространството заради подобни предупреждения. Също така потискането на всички известия ще затрудни същинското отстраняването на проблема, когато се наложи.

Има няколко опции как да поправите грешката.

Решения #1

Единият от начините за премахване на това php предупреждение е, като проверите кода и установите от къде идва известието. Уведомленията могат да произлизат от приставки или теми, съдържащи PHP класове.  Явно е настъпила промяна, която php 7 не възприема. Това е така, защото някои от параметрите не съвпадат с тези на техния родителски клас или обратното. Затова нагласете параметрите, така че да съответстват. Това решение е дългосрочно, ако имате пълен контрол върху кода.

Решение #2

Пренебрегвайте предупреждението и го отхвърляйте. Наистина е досадно и трудоемко да се прегледат и коригират всички файлове, свързани с WordPress разширения или теми. Всъщност подобна процедура на практика е и безсмислена, защото новата актуализация ще премине през вашите промени. Този подход се препоръчва за момента, когато разработчиците поправят кода си през следващите месеци.

Можете да използвате този код в първия включен файл. Той обикновено е конфигурационен файл. В случая на WordPress имате опция да го добавите към wp-config.php (веднага след отварянето на php tag: <? Php или файла functions.php.

Ако желаете да инсталирате приставка, разгледайте плъгина на  Orbisius Warning Suppressor.

Сходни търсения:

  • Как да премахнем PHP Warning: Declaration of … should be compatible with ….
  • Как да отстраня PHP Warning: Declaration of … should be compatible with ….
  • Как да стопираме PHP Warning: Declaration of … should be compatible with ….

 

Може ли WordPress да се ползва заедно със статичен сайт?

Posted on by Svetoslav Marinov

В повечето случаи – Да. В най-често срещаната настройка на WordPress – с permalinks чрез .htaccess) ще се зареди само ако файлът или директорията не съществуват. Това означава, че статичните файлове ще си се зареждат нормално.

Има малко изключения. Повечето от файловете в WordPress имат префикса wp-, което е добре, но .htaccess и index.php бих били презаписани ако WordPress бъде инсталиран в същата директория както е статичния сайт.