[Mini] Czym jest i jak działa plik .gitkeep?

Być może miałeś okazję zobaczyć taki plik w kilku repozytoriach Git i zastanawiałeś się czym on jest. Podstawowa znajomość angielskiego pozwala stwierdzić, że będzie on czymś w rodzaju pliku .gitignore - wewnętrznym plikiem przekazującym jakieś informacje gitowi.

Rolą pliku .gitkeep jest spowodowanie aby dany folder był wysłany do repozytorium nawet gdy nie zawiera żadnych innych plików - git bowiem pomija puste foldery przy commitowaniu. Teraz uwaga: plik nie jest w żaden sposób częścią standardu - jest to nazwa umowna - plik na dobrą sprawę może być dowolnym innym (pustym bądź nie) plikiem, jest on potrzebny aby Git uwzględnił zawierający go folder w repozytorium. Wprowadzenie jakiejś określonej nazwy pozwala po prostu zorientować się czym jest plik, po samej jego nazwie.

Tak więc podsumowując jakby ktoś nie zrozumiał: folder pusty nie jest "widziany" przez Gita, tak więc dodaje się do takich folderów puste pliki o dowolnych nazwach, żeby zmienić to zachowanie. Kilka osób umówiło się natomiast, że .gitkeep to dobra nazwa, bo nawiązuje konwencją do .gitignore - faktycznego pliku konfiguracyjnego no i mówi nam nazwą o co w pliku chodzi.

[WordPress] Pobieranie ilości i treści zapytań oraz czasu generowania strony

Często zachodzi potrzeba sprawdzenia tego, jak wygląda czas generowania naszej strony lub ile generuje ona zapytań do bazy danych. Pomijając tutaj użycie profilerów (choćby ze względu na brak dostępności na większości hostingów) pokażę jak uzyskać takie informacje w skrypcie WordPress.

Pobieranie ilości zapytań
Aby uzyskać ilość zapytań wykonanych do bazy przez WordPressa należy skorzystać z funkcji get_num_queries() - zwraca ona liczbę tylko liczbę wykonanych zapytań. Przykład użycia pokażę na końcu wpisu.

Pobieranie listy zapytań
Pobranie samej treści wykonanych zapytań jest już lekko trudniejsze. Należy zacząć od zdefiniowania jednej stałej w pliku wp-config.php. Gdzieś w nim (można to zrobić np. po stałej WP_DEBUG) należy umieścić następujący zapis.
<pre class="brush:php">define('SAVEQUERIES', true);
W tym momencie WordPress zacznie logować informacje na temat wszystkich wykonanych przez siebie zapytań. Aby je wyświetlić możemy użyć kodu oferowanego przez oficjalną dokumentację WP:

<?php
if (current_user_can('administrator')){
  global $wpdb;
  echo "<pre>";
  print_r($wpdb->queries);
  echo "</pre>";
}
?>

Zasada działania jest prosta: jeżeli dany użytkownik ma uprawnienia administratora, to pokaże się dump tablicy wielowymiarowej zawierającej informację o zapytaniu. Na każde zapytanie składają się trzy klucze. Pierwszy określa treść zapytania, drugi: czas jego wykonania, a trzeci mówi o tym jak po kolei wyglądała droga do wykonania tego zapytania (dołączane pliki i wywoływane funkcji).

Jeżeli jednak, tak jak ja, nie potrzebujecie aż tak szczegółowych informacji o każdym zapytaniu, możecie użyć takiego kodu:

<?php
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";
?>

Ten kod pokazuje jedynie treść wykonanych zapytań. Uwaga: ja używam tego kodu do wsadzenia tej informacji w HTML-owy komentarz. Jeżeli chcecie wyświetlić to na stronie, to pamiętajcie o zamianie nowej linii na br. Oczywiście można dodać sprawdzanie uprawień użytkownika, aby takie informacje udostępnić tylko dla administratorów (to wskazane posunięcie!).

Pobieranie czasu generowania strony
Do pobrania czasu generowania strony opartej na WP służy funkcja timer_stop(). Przyjmuje ona dwa parametry, pierwszy określa czy wartość ma być wyświetlona (1), czy zwrócona (0; ustawienie domyślne). Drugi określa zaś precyzję, czyli ilość cyfr po przecinku w czasie generowania (domyślnie 3). Przykład użycia za chwilkę.

Sprawdzanie ilości użytej pamięci
Tutaj skorzystamy już z wbudowanej w PHP funkcji memory_get_usage(). Zwraca ona wynik w bajtach, tak więc dla lepszej czytelności zatroszczymy się o przeliczenie na megabajty.

<?php echo number_format(memory_get_usage()/1024/1024, 2); ?>

Drugi parametr funkcji number_format() także określa liczbę miejsc po przecinku.

Kompletny przykład
Oto przykładowa implementacja powyżej pokazanych rozwiązań.

<!--
Zapytania: <?php echo get_num_queries();
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";  ?>
Czas generowania: <?php timer_stop(1, 2); ?>s
Użyta pamięć: <?php  echo number_format(memory_get_usage()/1024/1024, 2); ?>MB
-->

I to by było na tyle. Mam nadzieję, że przedstawione rozwiązanie do czegoś się Wam przydało. Pamiętajcie też, że po skończonym debugu lepiej jest usunąć stałą SAVEQUERIES z konfiguracji lub przestawić ją na false, gdyż włączenie opcji logowania zapytań zwiększa zużycie zasobów.

[PHP] Wyłączanie komunikatów notice

Problem stary jak świat. Po odpaleniu aplikacji (często na innym serwerze) wyskakuje szereg komunikatów typu notice (podkreślmy od razu bardzo ważną rzecz: notice to nie błąd). W tym wypadku przedstawiane są dwie szkoły: jedna mówi, że aplikacja nie powinna generować żadnych komunikatów, a druga uznaje, że skoro notice błędem nie jest, to może wystąpić, bo to tylko informacja dla programisty. Niezależnie od tego, którą z nich wyznajemy, ukrycie notice (jak i  błędów) jest konieczne w środowisku produkcyjnym, ze względów bezpieczeństwa.

Wykonanie tego zadania sprowadza się do dodania jednej linijki gdzieś na początku pliku PHP.

<?php
error_reporting(E_ALL ^ E_NOTICE);

To sposób jednorazowy/doraźny. Jeżeli chcemy załatwić sprawę na stałe i mamy taką możliwość to po prostu edytujemy plik php.ini i tak jak wyżej zmieniamy wartość dyrektywy error_reporting na E_ALL ^ E_NOTICE.

PS: Wiem, ze problem jest oklepany, ale będzie gdzie odsyłać kolejnych ludzi mówiących o "błędach notice".

Jak (dobrze) umieścić komunikat o cookies

Sobak, jako wybitny specjalista w dziedzinach accessability, usability i innych –ity ma dla Was najnowszą super-wypasioną poradę przydatną w dzisiejszych czasach. Będzie ona dotyczyć… cookies. Małych, niewinnych ciasteczek, które od maja tego roku zostały skazane na bycie piętnowanymi przez Unię Europejską miłościwie nam panującą.

Mam ja krótkie pytanie: dlaczego prawie nikt nie umieścił komunikatu o cookies na dole strony bez fixed? Najczęściej widuję strony, które taki komunikat mają przyczepiony na górze. Dosyć rzadko dzieje się tak, że po przewinięciu w dół komunikat zostaje na górze (czyli po prostu nie ma fixed). Wiele stron zdecydowało się umieścić taki komunikat na dole, jednak w takim rozwiązaniu mamy permanentnie ucięte kilkanaście pixeli z dołu strony.

Natomiast zestaw, do którego chciałbym Was przekonać, czyli informacja umieszczona na dole strony i nie przylepiona do dołu ekranu na fixed, mimo że zdaje mi się najlepszy, widziałem raptem na kilku stronach WWW (choćby Google/Youtube czy Forumweb). Dlaczego takie rozwiązanie jest wg mnie najlepszym wyjściem? Przede wszystkim nie zabieramy na stałe przestrzeni z ekranu. Komunikaty z fixed rezerwują sobie nieraz wiele przestrzeni i dopóki użytkownik ich nie zamknie będą wędrować z nami podczas czytania strony. Komunikat umieszczony na dole może być przeczytany przez użytkownika po zobaczeniu tego, po co przyszedł na stronę. To przecież nie informacja o ciasteczkach jest dla niego najważniejsza.

Dlaczego więc webmasterzy tak bardzo upodobali sobie inne formy? Zwięzłą i bardzo ciekawą analizę przedstawił logeen na Forumweb.pl. W skrócie: jako pierwsze komunikat o cookies wprowadziły witryny rządowe. Webmasterzy, a raczej ich zleceniodawcy pod natłokiem całego szumu jaki wywołała zmiana prawa uznali strony rządowe za dobry wzorzec i gwarancję zgodności ze znowelizowaną ustawą ("to nie może być złe bo tak robi strona prezydenta/premiera etc").

Tymczasem przedstawione przeze mnie rozwiązane w żaden sposób nie narusza ustawy Prawo Telekomunikacyjne. Ustawa o samym komunikacie mówi jedynie, że ma być on jednoznaczny, bezpośredni i zrozumiały dla użytkownika.

abonent lub użytkownik końcowy zostanie uprzednio jednoznacznie i bezpośrednio poinformowany, w sposób łatwy i zrozumiały

W związku z tym porada na dziś będzie taka: nie marnujcie miejsca na monitorach Waszych czytelników, nie marnujcie ich uwagi na czytanie tego samego komunikatu po raz kolejny. Odpowiednia wzmianka w stopce spokojnie wystarczy.

Spotify – nowe ograniczenia w pakiecie Free

Dziś dostałem następującą wiadomość email od Spotify:

(...)
Chcielibyśmy Cię poinformować, że w dniu 12 sierpnia 2013 r. zostały wprowadzone zmiany Ogólnych Warunków Umownych Korzystania z Serwisu Spotify, w szczególności odnoszące się do Bezpłatnej Usługi. Możesz zapoznać się z nowymi Ogólnymi Warunkami Serwisu Spotify.
(...)

Logo Spotify

Po zajrzeniu do podlinkowanego regulaminu potwierdziłem swoje przypuszczenia. Serwis wprowadził kolejne limitacje dla darmowego pakietu. Przechodząc od razu do sedna, po udaniu się do odpowiedniego punktu FAQ możemy ujrzeć następującą informację:

Nieograniczone odtwarzanie strumieniowe przez 6 pierwszych miesięcy
Gdy utworzysz swoje konto Spotify, przez sześć pierwszych miesięcy będziesz mieć możliwość nieograniczonego przesyłania strumieniowego muzyki w ramach konta Spotify Free. Po tych sześciu pierwszych miesiącach pojawią się pewne ograniczenia czasu odtwarzania.

Ile muzyki można odtwarzać strumieniowo
Zaczynając od 10 godzin, Twoje konto będzie otrzymywać co tydzień przydział 2,5 godziny odtwarzania strumieniowego. Niewykorzystany czas w danymi tygodniu jest sumowany. W ten sposób czas odtwarzania strumieniowego może być sumowany do maksymalnie 10 godzin.

Czas odtwarzania strumieniowego jest co tydzień dodawany do Twojego konta – tego samego dnia tygodnia, w którym zostało utworzone Twoje konto Spotify, mniej więcej o tej samej porze dnia.

Analizując szybko podane informacje: limity dotkną nas po 6 miesiącach od założenia konta. Będziemy mogli słuchać do 2,5h muzyki tygodniowo (limit nie dotyczy oczywiście muzyki znajdującej się lokalnie na naszym komputerze, a jedynie dodanej do Spotify). Niewykorzystany czas będzie sumowany (aby wykorzystać go później), przy czym jego ilość nie może przekroczyć 10h.

Nie sądzę aby mnie osobiście dotknęły nowe zmiany. Spotify wykorzystuję głównie do poznawania nowych zespołów lub szybkiego przejrzenia i przesłuchania dyskografii danego artysty. Niewątpliwie jednak, dla osób, które używają usługi Spotify jako głównego źródła muzyki na swoim komputerze owe limity będą dosyć dotkliwe (limit 2,5h nie wystarczył by mi na jeden dzień, nie mówiąc o tygodniu, po prostu większość słuchanej muzyki biorę z innych źródeł niż Spotify).

Co sądzicie o wprowadzonych regulacjach? Nie jest to przypadkiem strzał w stopę? Wydaje mi się, że wiele osób w obliczu limitów po prostu porzuci tę usługę i potrzebne im utwory pobierze na dysk, a jako źródło utworów do jednorazowego przesłuchania zacznie wykorzystać choćby YouTube.

It’s alive!

Tak tak, nadal żyję, choć patrząc na to jak długo się tutaj nic nie działo, można było pomyśleć inaczej. Niestety, tak łatwo się świat Sobaka nie pozbędzie, więc po prawie czterech miesiącach (sic!) bez wpisu, czas na mały-wielki powrót. Zdaję sobie sprawę, że pewnie część z Was wyrzuciła mnie już z czytników RSS (o ile kiedyś w jakimś byłem :D), ale mam nadzieję, że mimo tego wszystkiego ktoś będzie chciał czytać moje wypociny.

Jak widać, każdemu, nawet mi, może znudzić się nic nie robienie. W związku z tym doszedłem do wniosku, że czas trochę odkurzyć na moim blogu. Standardowo, przy takim „powrocie” (wolę nie liczyć ile ich już było) poprawiłem kilka zalegających rzeczy.

Zabrałem się za poprawienie różnych rzeczy powiązanych z theme strony. Zależało mi głównie na poprawie generowanego kodu HTML i to się częściowo udało. Nie jest jeszcze dobrze, bo pewne rzeczy są trudne w modyfikacji ze względu na to jak generuje je WordPress, na kilka innych nie miałem pomysłu lub wiedzy jak je rozwiązać (bardzo możliwe, że dało by się to zrobić optymalniej i np. pozbyć się jeszcze kilku divów). Mimo wszystko udało się pozbyć naprawdę sporej części zbędnego kodu HTML i CSS (rozmiar tego [wliczając minifikację] zmniejszył się o połowę) oraz poprawić semantykę. Użycie HTML5 zostało rozszerzone poza samo doctype, które było w theme od początku (między innymi poprzez użycie atrybutu placeholder zamiast JS-owych zamienników).

Przy okazji poprawiania wyżej wspomnianych rzeczy okazało się jednak, że kod PHP szablonu dał mi okazję do poprawienia wielu rzeczy. Theme Mystique został oparty na frameworku przeznaczonym do tworzenia właśnie szablonów pod WordPressa - Atom. Jedną rzecz mogę o tym skrypcie powiedzieć na pewno - niesamowita kobyła. Okazało się, że sama konstrukcja wspomnianego frameworka miała duży wpływ na wydajność strony. Wystarczy chyba wspomnieć, że po w miarę drobnych modyfikacjach, w niektórych miejscach udało mi się zmniejszyć ilość zapytań SQL o 50%. Świadomie pozbyłem się bardzo wielu możliwości theme, z których nie planuję korzystać, tak aby poprawić katastrofalną (serio katastrofalną) wydajność mojej instalacji WordPressa.

Przy okazji pozbyłem się też nieużywanej już wtyczki do śledzenia błędów 404.  Wtyczka nie widziała problemu w zostawieniu swoich tabel w bazie po odinstalowaniu. W jednej leżało 14 tysięcy rekordów, w drugiej 9 tysięcy – i kto to teraz posprząta? Doliczmy do tego 23 tysiące rekordów od kolejnej wtyczki, która zapomniała zabrać swoje zabawki z piaskownicy przy odinstalowywaniu i mamy już całkiem pokaźną (oczywiście jak na moją skalę) część bazy danych.

Może jest to mało zauważalne, ale istotnego odświeżenia doczekała się organizacja treści na blogu. Ponownie otagowałem i skategoryzowałem wszystkie wpisy. Kategorie nie powinny być już aż tak ogólne, z kolei ilość tagów została ograniczona ponad dwukrotnie, tak, aby faktycznie grupowały one podobne treści (zmiany widać zresztą nawet wizualnie na samej chmurze tagów).

W związku z przeprowadzonymi sporymi porządkami zwracam się z prośbą do czytelników mojego bloga (o ile jeszcze ktoś taki pozostał po tej czteromiesięcznej niezapowiedzianej przerwie). Jeżeli ktoś z Was widzi coś, co powinno zostać poprawione, to będę wdzięczny za zgłoszenie, czy to w komentarzu do tego wpisu, czy też przez kontakt. Starałem się poprawić to, o czym przypominaliście mi od dawna, ale mam świadomość, że mogłem o czymś zapomnieć.

Przepraszam za tak długą nieplanowaną przerwę i liczę na to, że ktoś jeszcze zamierza czytać przyszłe wpisy :)

IronCMS2 beta3 i informacje

Zgodnie z ostatnimi zapowiedziami projekt CMS-a (wbrew pozorom) nie został porzucony. Poza wydaniem kolejnej bety, która naprawia poprzednio znalezione błędy i dodaje trochę nowych funkcjonalności chciałem wyjaśnić kilka kwestii natury organizacyjnej.

Po pierwsze, coś co może Was lekko zasmucić (choć, serio, nie powinno :D). Z powodu moich niezbyt wyrafinowanych umiejętności i pewnych specyficznych wymagań jakie postawiłem przed systemem, a także uwarunkowań licencyjnych związanych z szablonem, CMS nie zostanie na razie wydany publicznie.
Po drugie: ponownie nadszedł czas na podziękowanie grupie świetnych testerów i kolegów, którzy pomagają mi w realizacji całego tego przedsięwzięcia. Podziękowania lecą , alfabetycznie, do:

Jeżeli o kimś zapomniałem to proszę bić :D W tej wersji ponownie poprawiono ponad 50 zgłoszeń odnośnie błędów i funkcjonalności. Jeżeli ktoś z Was chciałby dołączyć do grona testerów, to proszę o skorzystanie z zakładki "Kontakt".

Mam nadzieję, że kolejna wersja będzie już stabilna, wtedy na pewno przedstawię więcej informacji.
Pozdrawiam :)

[Minecraft] Jak wyłączyć griefing endermanów i eksplozje creeperów?

Tematem dzisiejszej krótkiej porady będzie Minecraft - popularna gra sandboksowa. Pokażę, jak w prosty sposób można wyłączyć wszelki griefing wykonywany przez moby. Wlicza się w to:

  • niszczenie bloków poprzez eksplozje creeperów, ghastów i witherów
  • podnoszenie bloków przez endermany
  • wyłamywnanie drzwi przez zombie

Swego czasu stworzyłem plugin MobsControl, który realizował powyższe zadania, ale od Minecrafta w wersji 1.4.2 wyłączenie powyższych zachowań jest możliwe przez wykonanie jednej komendy.

Multiplayer
Wykonanie komendy wymaga uprawnień operatora. Z konsoli serwera lub wykonaj następującą komendę:
/gamerule mobGriefing false

Singleplayer
Wykonanie tej czynności w trybie singleplayer wymaga włączenia cheats (oszustwa) przy tworzeniu świata. Inaczej nie będzie możliwe wykonanie komendy. Komenda tak jak powyżej:
/gamerule mobGriefing false

Uwagi na koniec
Rozróżniana jest wielkość znaków! Jeśli chcemy przywrócić ustawienia domyślne to po prostu zmieniamy false na true i wykonujemy komendę raz jeszcze.

Informacja – status projektów

W związku z kolejną długą przerwą od wpisów, myślę, że tym z Was, którzy czytują mnie jakoś w miarę regularnie (są tacy? :P) należy się kilka wyjaśnień. Przyczyn takiego stanu rzeczy jest kilka, jedną na pewno jest fakt, że ostatnio ciężej jest mi się zmotywować i opisać jakiś temat na blogu - tak zwana prokrastynacja. Ponadto od kilku tygodni pracuję z kolegą nad kolejnym projektem - mam nadzieję pochwalić się nim już niedługo.
Chciałem jednak jednoznacznie przedstawić, jak wygląda sprawa kilku moich wcześniejszych "projektów", ponieważ już kilka osób się mnie o to pytało.

Sobak's Blog
Blog jak najbardziej jest kontynuowany. Nie planuję go zamykać czy coś w tym stylu. Obecny deficyt nowych wpisów, mam nadzieję, będzie tymczasowy. Co więcej, z blogiem (a raczej ogólnie stroną) łącze pewne przyszłe plany, które siłą rzeczy wiążą się z kolejnym projektem...

IronCMS 2
Przestój prac rzeczywiście występuje, publiczne informacje o postępie zatrzymały się na drugiej becie. Mimo tego, jest on dla mnie ważnym projektem i cały czas planuję go dokończyć. Aktualnie po prostu wskoczył na drugie miejsce w kolejce - za projekt, o którym wspomniałem na początku notki.

BrzydkiKod
Planowałem większą rewolucję wraz z uruchomieniem nowej wersji strony, ale ostatnio natknąłem się na projekt nospora - pr0.nospor.pl, który całkowicie wyczerpuje formułę pomysłu, który zacząłem realizować. W związku z tym, myślę że nie ma obecnie szans na kontynuację tej inicjatywy - jeśli już, to po prostu podeślę ze zbiorów coś do "konkurencji".

XNova/Blackout
Ktoś to jeszcze pamięta? ;) Ja praktycznie zapomniałem, ale pewna osoba mi przypomniała, więc warto rzecz wyjaśnić. Sprawa obecnie wygląda tak: projekt tego typu może zostać zrealizowany, jednak nie będzie to na pewno przeróbka XNovy, tylko coś pisanego od zera (bardzo możliwe, że z wykorzystaniem części rozwiązań z dostępnych silników). Trzeba jednak pamiętać że to co mam w kolejce spokojnie wystarczy mi na długi czas.

Zakładka projekty
Projekty jako zbiór doczekały się już kilku przeprowadzek. Swego czasu istniał dla nich osobny skrypt, potem zostały zwykłymi podstronami w WordPressie. Na nowej stronie moduł projektów będzie integralną częścią systemu, jednak będzie cechował się specyficznymi możliwościami, innymi od zwykłych podstron i dostosowanymi do wymagań. Krótko mówiąc: staram się połączyć zalety obu rozwiązań.

Jeśli chodzi o zawartość zakładki to część ze skryptów zostanie zakończona na obecnym etapie. Inne natomiast (główne klasy PHP) będą stale aktualizowane, bo zdaję sobie sprawę, że kurz już na nich osiadł no i jakość kodu nie jest najlepsza, dużo się w nim od tamtego czasu pozmieniało.

Jeśli ktoś z Was chce, abym wyjaśnił jeszcze jakąś kwestię o której zapomniałem to piszcie w komentarzach :)

[WordPress] Usuwanie zbędnego kodu HTML (WLW, RSD, generator)

Każdy, kto korzystał z WordPressa i ma w zwyczaju patrzeć jak jego strona wygląda "pod maską", z pewnością zauważył, że tytułowy CMS nie generuje najlepszego jakościowo kodu. Wynika to głównie z jego rozszerzalności i uniwersalności, ale nie oznacza to, że w prosty sposób nie możemy pozbyć się części nadmiarowego kodu HTML i CSS.

Usuwanie odwołania do RSD (Really Simple Discovery)
Mowa o następującym kodzie w nagłówku strony:

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://example.com/xmlrpc.php?rsd" />

Jest on używany przez klienty protokołu XML-RPC, np. <a href="Windows">http://en.wikipedia.org/wiki/Windows_Live_Writer">Windows Live Writer. Jeżeli nie używasz go lub wspomniane nazwy po prostu nic Ci nie mówią, prawdopodobnie możesz bez obaw usunąć ten kod ze swojej sekcji head.

Jak to zrobić? To bardzo proste, dzięki wbudowanemu w WordPressa systemowi akcji, który pozwala także na ich usuwanie. Najlepszym sposobem będzie dodanie następującego kodu na koniec pliku functions.php w katalogu Twojego szablonu (wp-content/themes/Twoj_Theme/functions.php). Jeżeli plik o tej nazwie nie istnieje we wspomnianej lokalizacji, należy go utworzyć i wstawić poniższy kod w jego treść:

<?php
remove_action('wp_head', 'rsd_link');

Usuwanie odwołania do WLW (Windows Live Writer)
Odpowiada za niego następujący kod HTML w nagłówku bloga:

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://example.com/wp-includes/wlwmanifest.xml" />

Jego przeznaczenie jest takie jak powyższego, co widać dokładnie po nazwie :) Jeśli chcesz go usunąć, to analogicznie do functions.php w katalogu Twojego szablonu (więcej wyżej) dodaj kod:

remove_action('wp_head', 'wlwmanifest_link');

Usuwanie wersji WordPressa (meta generator)
Mówię oczywiście o tym:

<meta name="generator" content="WordPress X.X.X" />

Ten kod jest najprawdopodobniej zbędny. Skorzystać z niego będą prawdopodobnie tylko roboty przeszukujące sieć pod kątem starych wersji WordPressa, które będą podatne na ataki. Nic nie stoi więc na przeszkodzie, aby i jego usunąć. Na koniec wspomnianego pliku functions.php dodajemy kod:

remove_action('wp_head', 'wp_generator');

Linki relacyjne i nawigacyjne do wpisów
Wiele blogów generuje kod na kształt poniższego:

<link rel='index' title='Strona główna' href='http://example.com' />
<link rel='start' title='Pierwszy wpis' href='http://example.com/pierwszy-wpis/' />
<link rel='prev' title='Post poprzedni' href='http://example.com/post-poprzedni/' />
<link rel='next' title='Post następny' href='http://example.com/post-nastepny/' />

Na początku warto zaznaczyć, że ten kod może być często przydatny, korzystają z niego niektóre przeglądarki, aby ułatwić nawigację pomiędzy kolejnymi artykułami na stronie (np. Opera). Jeśli jednak uważasz, że takie rozwiązanie jest Ci niepotrzebne, możesz je usunąć dodając do functions.php:

remove_action('wp_head', 'start_post_rel_link'); // Odniesienie do pierwszego wpisu
remove_action('wp_head', 'index_rel_link'); // Odniesienie do strony głównej
remove_action('wp_head', 'adjacent_posts_rel_link'); // Odniesienia do postów sąsiednich (poprzedni, następny)

Cały plik functions.php
Czyli opcja dla leniwych

<?php
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
remove_action('wp_head', 'wp_generator');
remove_action('wp_head', 'start_post_rel_link');
remove_action('wp_head', 'index_rel_link');
remove_action('wp_head', 'adjacent_posts_rel_link');

Wyjaśnienie na koniec
Możesz też sobie zadać pytanie: dlaczego nie usunąć podanych fragmentów wprost z kodu WordPressa zamiast używać funkcji remove_action()? Odpowiedź jest bardzo prosta: przedstawione wyżej rozwiązanie nie narusza w żaden sposób rdzenia skryptu, w związku z czym zmiany nie zostaną utracone np. przy aktualizacji. Umożliwia też ono łatwe cofnięcie zmian - wystarczy usunąć odpowiednie wywołanie funkcji remove_action()

Mam nadzieję, że przedstawiona krótka porada przyda się Wam. Zawsze to zaoszczędzone kilka bajtów transferu :)