Dziś będzie o tym, jak dodać do strony na WordPressie informacje o dacie ostatniej aktualizacji, i to w taki sposób, by data ta była zaciągana automatycznie, bez potrzeby ręcznego wypełniania jakiś dodatkowych pól – WordPress i tak przechowuje w bazie danych tego typu informacje.
Spis treści w artykule
Data ostatniej aktualizacji wpisu w WordPressie
Z racji tego, że sporo wpisów, które ukazują się na stronie Webinsider.pl to poradniki techniczne, a więc często data, która określa kiedy powstały dane treści ma szczególne znaczenie, bo chyba każdemu zależy, by prezentowane rozwiązanie nie okazało się tylko „niepotrzebną stratą czasu”.
Dlatego przy niektórych wpisów możecie trafić nie tylko na datę powstania wpisu, ale i datę ostatniej aktualizacji, dzięki czemu od razu wiadomo, czy prezentowane treści były w jakiś sposób aktualizowane, co daje większą szansę, że zadziałają rozwiązania z wpisów teoretycznie opublikowanych nawet kilka lat temu (dzięki aktualizacji treści):
Cała operacja sprowadza się do wykorzystania duetu w postaci motywu potomnego i kilkunastu linijek kodu w pliku functions.php:
function webinsider_wp_last_modified_post_date( $the_date ) {
if ( get_post_type() === 'post' ) {
$post_time = get_post_time( 'd.m.Y', 'His' );
$post_modified_time = get_post_modified_time( 'd.m.Y', 'His' );
if ( $post_modified_time !== $post_time ) {
$date = sprintf( __( esc_html( get_post_time( 'd.m.Y' ) ) . ' (aktualizacja %s)' ), esc_html( get_post_modified_time( 'd.m.Y' ) ) );
}
else {
$date = sprintf( __( esc_html( get_post_time( 'd.m.Y' ) ) ) );
}
return $date;
} else {
return $the_date;
}
}
add_action( 'get_the_date', 'webinsider_wp_last_modified_post_date' );
add_action( 'get_the_time', 'webinsider_wp_last_modified_post_date' );
Powyższy kod sprawdza, czy data publikacji wpisu jest różna od daty ostatniej modyfikacji, i jeśli tak jest, to wtedy oprócz daty publikacji doda fragment odpowiedzialny za wyświetlenie informacji o dacie ostatniej aktualizacji (daty wyświetlane są w formacie 17.03.2017).
Oczywiście można go zmodyfikować, tak by porównywał również czas, ale moim zdaniem to generuje tylko niepotrzebne zamieszanie, bo wystarczy nawet w chwilę po publikacji zmienić jakąś literówkę, czy jakieś ustawienia dotyczące wpisu i już będziemy mieli dodatkową informację o aktualizacji. Stąd – moim zdaniem – porównywanie dat jest sensowniejszym rozwiązaniem.
Kilka dodatkowych modyfikacji
W komentarzach pojawiło się kilka pytań dotyczących modyfikacji tego kodu, dlatego uznałem, że warto też przy okazji odpowiadania na te komentarze zaktualizować artykuł, bo może nie każdy czyta komentarze.
Data aktualizacji również dla stron
By wyświetlić datę aktualizacji również dla stron, należy zmodyfikować linijkę z warunkiem „if” w powyższym kodzie:
if ( ( get_post_type() === 'post' ) || ( get_post_type() === 'page' ) ) {
Więcej informacji na ten temat znajdziecie w WordPress Codex (Function Reference/get post types).
Zmiana języka dla daty
Z racji tego, że mamy tu obsługę formatowania daty zgodną z PHP, to nic nie stoi na przeszkodzie, by zmienić format np. na „10 października 2018”. Przynajmniej w teorii wystarczy zamienić „d.m.Y” np. na „j F Y”:
get_post_modified_time( 'j F Y' )
Problem w tym, że spowoduje to wyświetlanie słownych składników daty w języku angielskim, niezależnie od ustawień regionalnych w WordPressie.
By wyświetlać te elementy zgodnie z językiem ustawionym w WordPressie, należy przekazać do funkcji dodatkowe parametry:
get_post_modified_time( 'j F Y', false, null, true )
Modyfikację wystarczy przeprowadzić w linijkach z „sprintf”.
- Zero Trust od Cloudflare, czyli prosty i bezpieczny sposób na dostęp do lokalnych zasobów z zewnątrz, bez publicznego adresu IP i otwierania portów na routerze - 1970-01-01
- Home Assistant i integracja z IMGW-PIB, czyli tworzymy automatyzację z powiadomieniami bazując na sensorach zagrożenie i alarm powodziowy - 1970-01-01
- Home Assistant 2024.9 i kolejne przydatne nowości w widoku „sekcje”, dzięki którym jeszcze lepiej można dopasować wygląd - 1970-01-01
Poco tu wzmianka o childen-theme? Czy chodzi tylko o to, iż definiujemy swoje funkcje w szablonie?
Tą informację poza tym można jeszcze rozbudować o:
– jak sortować wpisy po dacie modyfikacji – z tym spotkałem się gdzie w sieci.
– jak republikować wpisy po modyfikacji (rss itp)
O motywach potomnych wspominam chyba każdorazowo przy tego typu wpisach, bo z doświadczenia wiem, że często modyfikacje standardowego motywu robione są bezpośrednio, co oczywiście będzie działać, ale wraz z aktualizacją danego motywu wszystkie one przepadną. A miałem przypadki, gdy dostawałem prośbę o „jakaś modyfikację” i okazywało się, że wprawdzie „motyw bazowy” ma jakieś przeróbki, to osoba/firma zajmująca się WordPressem zawodowo nie wpadła na to by skorzystać z motywów potomnych, zamiast tego albo klient dostawał informacje by nie aktualizować motywu lub był on wyłączony (zablokowany) z procesu aktualizacji. Alternatywnie – a nawet w niektórych przypadka będzie to lepsze rozwiązanie – można przygotować własną wtyczkę (lub kilka), w której będziemy zapisywać niektóre modyfikacje (niektóre, bo nie wszystko da się w ten sposób zrobić/obejść, a przynajmniej nie tak łatwo jak korzystając z motywy potomnego).
Co do „rozbudować o”, to staram się nie mieszać tematów, choćby dlatego, by w tytule wpisu zmieścić informację o tym, co w treści… Co do sortowania po dacie aktualizacji – jest to możliwe i specjalnie dla Ciebie zaraz dodam jakiś kod tego typu.
Jeśli chodzi o RSS to na najbliższe dni mam zaplanowany wpis na temat modyfikacji RSSa w WordPressie, choć nie mogę na razie napisać/obiecać co w nim ostatecznie się znajdzie, bo chcę wybrać tylko kilka moim zdaniem najważniejszych modyfikacji, czyli w większości takich, które sam stosuje (np. na Webinsider.pl).
ad.1 Ja do takich przypadków wykorzystuję wtyczkę Snippets.
ad.2 I popieram takie rozwiązanie, tylko jak już tworzysz jakiś B o oparciu o A (nadchniony wpisem A, zmuszony w komentarzach pod wpisem A itp) to oprócz linkowania B do A, przydała by się wzmianka w A o B – potem łatwiej takie rzeczy szukać będąc już na stronie. Nie wszyscy trafiają tu z google, albo przynajmniej nie z zapytania który do końca rozwiązuje wpis A.
ad.2 Nie aktualne, nie zauważyłem ramki :)
1. Można, choć sam staram się tam gdzie da się coś zrobić w prosty sposób samodzielnie nie korzystać z dodatkowych wtyczek (zwłaszcza na stronach klientów, bo swoje strony czasem traktuje jako poligon doświadczalny ;-)).
No i mam wrażenie, że motywy potomne jednak dają większe możliwości, jak choćby modyfikacja plików bazowego motywu (np. by wstawić dodatkowy sidebar lub menu), czy własny szablon strony (np. by w prosty sposób monitorować status strony/WordPressa).
Do tego dochodzi też edycja stylów (style.css), nawet jeśli sporo motywów posiada dedykowane pola „tego typu” w konfiguracji, oraz mimo tego, że sam WordPress (chyba od wersji 4.7) również dorobił się takiego modułu w oknie/narzędziu personalizacji.
2. W planach mam kilka rozwiązań, które dodatkowo pogrupują podobne/powiązane wpisy w paczki, a teraz staram się je albo wewnętrznie linkować (w treści), albo w formie dodatkowych ramek „zobacz też”. Oczywiście nie zawsze się to udaje, bo w tej chwili opublikowanych wpisów jest coś ok 1200, do tego jakieś 200 w „czyśćcu” i kolejne 200-300 w formie notatek (głównie w Trello, choć nie tylko), a całość jest rozłożona na przestrzeni już kilku lat, stąd czasem może mi umknąć, że jest jakiś powiązany temat (ale nie tym razem ;-)). I chyba na razie radzę sobie z tym całkiem nieźle, a dodatkowo pod każdym wpisem są 2-3 różne mechanizmy „podobne wpisy”, choć przyznam, że działają one… różnie… ;-)
I tam od razu zmuszony – ogólnie mam swój harmonogram tematów do opracowania, ale staram się też reagować na bieżące wydarzenia, w tym komentarze czy zapytania od użytkowników. Stąd czasem pojawi się jakiś nowy pomysł na wpis (i bardzo dobrze, dziękować :-)), a czasem jakiś temat „tylko” przeskoczy w Trello o kilka(dziesiąt) pozycji do góry.
A w sumie, teraz mi wpadł taki pomysł, a po części ad. 3.
Jak można „okiełzać” RSS, to pytanie, czy można okiełzać też komentarze? Tak by w czasie aktualizacji wpisu, pojawił się automatyczny komentarze z informacją o aktualizacji – takie info dla tych co śledzą/subskrybują komentarze do wpisu.
Oczywiście, to nie musi być automat, a raczej coś w formie checboxa koło przycisku „Zaktualizuj”
[ _ ] Umieść informacje o aktualizacji wpisu w komentarzach.
[ _ ] Umieść informacje o aktualizacji wpisu w kanale RSS
Nigdy tego nie stosowałem, ale… może to dobry pomysł na artykuł (lub nawet wtyczkę ;-)). Zobaczę po weekendzie (Warszawski Festiwal Piwa wczoraj się zakończył, nie wszyscy rozjechali się już po domach ;-)).
Dobry temat! Plasuję :)
Bardzo dziękuję za wpis. Dzięki temu nie musiałem dodawać kolejnego pluginu :-)
Zastanawiam się tylko jak zmienić, aby tekst AKTUALIZACJA nie był drukowanymi napisany a małymi literami? W kodzie podanym przez autora jest z małej ale u mnie na stronie wyświetla drukowanymi. Jakieś sugestie?
I jeszcze jedno: jak zrobić tak samo dla zwykłych podstron aby dodało datę ich aktualizacji?
Pewnie trzeba by wskazać, że funkcja ma się wykonywać również dla dodatkowego typu „postów”:
Więcej informacji na ten temat znajdziesz w WordPress Codex (Function Reference/get post types).
Działa wyśmienicie! Jeszcze tylko takie pytanie o datę: jak zmienię rodzaj wyświetlanej daty na j F Y, to zamiast po Polsku nazwę miesiąca wpisuje po angielsku (strona ustawiona po polsku). Czy mam coś dodać jeszcze do kodu aby było po polsku?
Zmień:
np. na:
W efekcie czego otrzymasz coś w stylu "11 października 2017" (język daty będzie pobrany z ustawień WP).
A po co jest to „true, null, true” ??
To są wartości dla kolejnych parametrów, które przekazujemy do funkcji. Choć w tym przypadku reszta to trochę jakby „zapełniacze”, bo interesuje nas głównie/zwłaszcza ostatnie „true”, czyli „$translate”:
Cytując dalej Codex:
Dla czasu (godzina) lokalnego w powyższym przykładzie zmieniamy pierwsze "true" na "falce", czyli:
Pytanie, czy pierwsze „true” nie powinno być „false” czyli w domyślnej wartości. Bo z tego co ja rozumiem zapis z Codex’a spowoduje to iż data zostanie zapisanie w czasie Zulu czyli UTC+0, a nie w czasie serwera – dla PL odpowiednio UTC+1 i UTC+2.
Tak, masz rację, bo podałem po prostu fragment (cytat) z Codexa (z linkiem), bez ingerencji w kod. Ale może faktycznie, uzupełnię ten komentarz o info, gdyby ktoś zdecydował się skorzystać bezpośrednio z tego kodu a nie „inspirować” się nim.
Prawdopodobnie w CSSie motywu dla tego elementu masz ustawione:
Co powoduje zmianę liter na duże. Możesz albo zmienić to dla całości (globalnie, w motywie), lub ubrać "aktualizacja" np. w "span" z klasą, dla której ustawisz:
Choć wtedy (gdy dodatkowa klasa dla elementu) będziesz musiał zrezygnować z "esc_html".
Czy data aktualizacji będzie pobierana przez Google?
Jest normalnie widoczna przez robota indeksującego, bo jest generowana przez PHP, a nie JS. Inna kwestia, co Google z tą datą zrobi dalej. Jeśli Ci zależy na tym, by Google brało ją pod uwagę, to pewnie w jakieś schema można ją ubrać.