No i się stało – pojechałem znowu, popedałowałem trochę, i wróciłem. Przejechałem, zgodnie z planem, wybrzeże (tym razem) od zachodu – Międzyzdroje – po wschód – Hel. Wszelkie napotkane automaty do gier muzycznych zostały skrupulatnie spisane, wedle założeń wycieczki, i zostaną równolegle na Krokmanię oraz DDR Poland wywieszone, wraz z mapką rozmieszczenia maszyn.

Uwaga: długie, szczegółowe i pełne anegdotek z podróży. Tak, żebym więcej nie zapomniał, komu o czym opowiadałem… ;P
(more…)

Właśnie na nowo odkrywam uroki poprawiania kodu po kimś. Ot, typowa robota – coś nie działa, weź napraw. Cóż można jednak znaleźć w cudzym kodzie? Panie i panowie, scyzoryki w kieszeń, zaraz będą się same otwierać.

Eksponat pierwszy – pole formularza typu checkbox, zaznaczone, jeśli formularz już był raz wypełniany i wrócił po poprawki:

<?php
$tmp="serwis2";
if ($_POST[$tmp] == "on") {
?>
<td><input type="checkbox" name="serwis2" checked="yes"/>opcja</td>
<?php
} else {
?>
<td><input type="checkbox" name="serwis2"/>opcja</td>
<?php
}
?>

Rozumiem, że

<td><input type="checkbox" name="serwis2" <?php if ($_POST["serwis2"]=="on") { ?/>checked="yes" < ?php } ?>>opcja</td>

… było za skomplikowane. Trzeba było tę zmienną $tmp koniecznie. Co to jest, do licha, jakiś auto-generator PHP?

Eksponat drugi. Zwracanie błędów z funkcji najlepiej robić o tak:

return "brr";

Będzie informatywnie i wyczerpująco.

Eksponat trzeci. Sprawdzanie poprawności formularza. Oczywiście, jest kilka metod – client-side czyli javascriptem i odmówimy przesłania niepoprawnego formularza, albo server-side czyli sprawdzamy jakimś PHPem i odsyłamy do poprawek, albo łącząc te dwie techniki AJAXem. Tu geniusz wynalazł sposób czwarty. Otóż formularz jest – po kolei – sprawdzany javascriptem, generowane są komunikaty o błędach, a następnie… formularz, z tymi komunikatami i statusem błędu przy pomocy javascriptu wmontowanymi w ukryte pola, zostaje i tak posłany na serwer. Tylko po to, by się od niego odbić na pierwszym ifie (no bo jest niepoprawny przecież, jako w nim samym stoi wyraźnie, <input type=”hidden” name=”error” value=”cośtam”> – no i to pole error zostaje wyświetlone użytkownikowi, wraz z formularzem do poprawki. Tylko po kiego czorta w ten sposób?

Poprawka – w przypadku formularz prawidłowo wypełnionego, o zgrozo, nie zostaje on zaakceptowany. Zostaje znów “odrzucony” tylko tym razem zaopatrzony w kawałek javascriptu, który zmienia mu adres docelowy na innego PHPa, po czym formularz automatycznie podsyła.

Ratunku.

Przynajmniej godzinę dłubania straciłem dziś na makabrycznym odkryciu, że WordPress wykorzystuje konfigurowalny prefiks nazwy nie tylko do nazw tabel, ale i do nazw kluczy w tabelach meta-informacji o użytkownikach!

W skrócie: jeżeli masz WordPressa skonfigurowanego na np. domyślny prefiks “wp_”, i przeniesiesz go gdzieś zmieniając sobie prefiks na “blabla_”, to nagle padną wszystkie uprawnienia użytkowników – nawet administrator będzie bezradny jak dziecko. A to dlatego, że WordPress, instalując się, wykorzysta Twój prefiks “wp_” do stworzenia pól “wp_user_roles” w tabeli wp_options, oraz paru podobnych w wp_usermeta. Tak, to jest w zasadzie prefiks w prefiksie, zupełnie bez sensu. Żeby wszystko ruszyło, trzeba zmienić w nowych tabelach blabla_options i blabla_usermeta wszystkie pola zaczynające się na “wp_” na nowe “blabla_”.

Nie mieści mi się w głowie, po kiego grzyba ktoś tak to zrobił…