Używamy zaawansowanych pól niestandardowych w naszej firmie i czasami potrzebujemy użyć krótkiego kodu w naszych niestandardowych polach. W kodzie php używamy następnie do_shortcode funkcje dla tych pól. Nie ma powodu, aby nie używać go dla większości pól, ponieważ może chcieć dodać skróty do pola później.
My ” ponownie używam PHP CodeSniffer z regułą WordPress Coding Standards. Za każdym razem, gdy używamy echo do_shortcode, ostrzeżenie o ucieczce znika. Czy więc bezpiecznie jest po prostu użyć do_shortcode, czy też musimy użyć np. wp_kses_post dodatkowo?
Czy jest jakaś sprawdzona metoda w tym zakresie?
Dziękuję za jakąś radę
Komentarze
- do_shortcode nie służy do ucieczki.
- No dobrze, ale dlaczego Codesniffer nie wyświetla żadnego ostrzeżenia?
- Być może nie wyświetla pokaż ostrzeżenie, ponieważ funkcja renderująca shortcode powinna być odpowiedzialna za oczyszczanie jego danych wyjściowych. Ale do funkcji można przekazać dowolny ciąg i jeśli nie zawiera zarejestrowanych skrótów, to i ' m jestem prawie pewien, że ciąg nie zostanie w ogóle zmodyfikowany. Z pewnością nie jest to ogólna metoda odkażania. Sniffer kodu może zrobić tylko tyle. Przeczytaj tutaj, jak prawidłowo wyczyścić dane. Jest wiele funkcji, z których często korzystam to esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Odpowiedź
Standardy kodowania WordPressa traktują funkcję do_shortcode() jako „funkcję z automatycznymi znakami”. Wydaje się, że zostało to omówione w 2015 r. W tych wydaniach GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
Wyjaśnienie użyte podczas dodawania go do listy brzmiało:
Omówiłem to z obsługą VIP (# 44195). David, po naradzie z innym członkiem zespołu, powiedział, że jest to niepotrzebne, ponieważ robimy ucieczkę w miejscu, w którym emitowany jest kod HTML (w kodzie shortcode).
Ale nie jestem pewien, czy zgadzam się z rozumowaniem. Jeśli użyłeś go w ten sposób:
<?php echo do_shortcode( "[liveperson]" ); ?> Gdzie krótki kod jest zakodowany na stałe, ma to sens, ponieważ jedyną rzeczą do ucieczki jest wyjście shortcode, które powinno być chronione przez wywołanie zwrotne shortcode.
Jednak w twojej sytuacji używasz do_shortcode(), aby umożliwić wykonywanie skrótów w tekście podanym przez użytkownika, z pola niestandardowego. Ten tekst musi zostać zmieniony, ale do_shortcode() nie wprowadza żadnego znaku zmiany znaczenia.
Dlatego bezpiecznym sposobem obsługi takich pól byłoby umieszczenie tekstu za pomocą wp_kses() lub wp_kses_post(), aby usunąć niedozwolone tagi, a następnie następnie umieść je przez do_shortcode(), aby skróty mogły być ex ecuted bez ponownej zmiany znaku ucieczki.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); Nie robi to żadnej różnicy w tym, co sniffer kodu robi / nie zgłasza, ale przynajmniej tekst dostarczony przez użytkownika jest oczyszczony.
Jednym z ograniczeń jest to, że nie będzie działać, jeśli użyjesz esc_html(), ponieważ będzie to kolidować z atrybutami shortcode. To dezynfekcja nie zapobiegnie również wprowadzaniu przez użytkowników niezrównoważonych tagów, które mogłyby wpłynąć na układ, co jest jedną z rzeczy, w których zwykle ucieczka jest pomocna. Aby rozwiązać ten problem, możesz dodać force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );