WordPress jako CMS – najczęstsze błędy deweloperów

WordPress jako CMS - błędy deweloperów
Błędy. Nie popełnia ich tylko ten, kto nic nie robi. Każdy deweloper spędził przynajmniej raz w życiu ładnych parę godzin nad szukaniem czegoś, co rozwalało stronę i kiedy doszedł do przyczyny błędu, westchnął: „Niby banał.., ale skąd miałam/em to wiedzieć?”.

Błędy w kodzie są wpisane w zawód dewelopera, ale każdy się pewnie zgodzi, że najlepiej uczyć się na cudzych. Pozwoli to nie tylko zaoszczędzić mnóstwo czasu, ale już na starcie wyrobić sobie dobre nawyki programistyczne, które zaprocentują w przyszłości: zadowoleniem naszym i klienta.

Niżej prezentuję listę grzechów głównych deweloperów używających WordPressa jako CMS, którą utworzyłam na podstawie:

  • najczęściej pojawiających się problemów na polskim oficjalnym forum WordPressa
  • własnych błędów i doświadczeń
  • kompilacji informacji zdobytych podczas czytania innych blogów tematycznych (odnośniki do nich zamieszczam w treści artykułu)
  • wiedzy prezentowanej w Kodeksie WordPressa

Lista najczęstszych błędów deweloperów WordPressa

WordPress błąd dewelopera 1

Użycie polskich znaków diakrytycznych w źródle i niezastosowanie kodowania UTF-8

To raczej błąd początkującego dewelopera, ale częsty. Błąd szybko da o sobie znać w postaci znaczków-robaczków na ekranie, ale bywają sytuacje, kiedy tak nie jest. Sama się o tym przekonałam, kiedy w pliku header.php użyłam odwołania do klikanego logo i pola „alt”, gdzie użyłam polskich znaków w nazwie firmy. No i „dzięki” Internet Explorerowi, który po najechaniu myszą na obrazek wyświetla jego tekst alternatywny, nasze omsknięcie widzi już spora część odwiedzających.

WordPress dobre praktykiJak zapobiegać:

  • Używać właściwego formatowania znaków. Dobrze się sprawdza darmowy Notepad++: wybieramy Format->Koduj w UTF-8 (bez BOM) i przy takich ustawieniach zapisujemy nasz plik.
  • W pliku header.php umieścić linię:
<meta charset="<?php bloginfo( 'charset' ); ?>" />

dzięki której w wygenerowanej stronie zobaczymy:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

WordPress błąd dewelopera 2

Wykonanie motywu na bazie starego, podobnego i pozostawienie w kodzie rzeczy niepotrzebnych

Mało kto pisze kod nowej skórki zupełnie od zera i „z tzw. palca”. Ja też tak robię. Mam jakiś ogólny, okrojony szablonik z podstawowymi plikami, który rozwijam i przerabiam pod nową stronę. Nie ma w tym nic złego, dopóki nie zostawimy w nim śmieci. Już mi się zdarzyło, że dostałam pytanie od klienta: po co jest to dodatkowe okno X pod edycją strony Y? No i powstaje dylemat: mówić prawdę klientowi?

WordPress dobre praktykiJak zapobiegać:

  • Trzymaj porządek w kodzie na bieżąco
  • Nie hołduj zasadzie „najważniejsze byle działało”. Bałagan prędzej czy później da o sobie znać.
  • Po zakończeniu prac wykonaj ogólny przegląd kodu

WordPress błąd dewelopera 3

Odwołanie się w źródle do nazwy domeny lub wpisanej wprost ścieżki do danego pliku

Jeśli WordPress zostanie zainstalowany w głównym katalogu serwera, to odwołanie się do pliku style.css w postaci:

<link href="wp-content/themes/nasz-motyw/style.css" rel="stylesheet" type="text/css" />

zadziała prawidłowo. Do czasu, gdy np. użytkownik zechce zmienię sposób wyświetlania odnośników z postaci:

http://www.costam.pl/?page_id=11 

na bardziej przyjazne i ustawi /%postname%/ w Ustawiania->Bezpośrednie odnośniki.

WordPress dobre praktykiJak zapobiegać:

  • Korzystaj z funkcji bloginfoPrawidłowy zapis odwołania się do pliku style.css za pomocą tej funkcji:
    <link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" />
    

WordPress błąd dewelopera 4

Załączanie plików JavaScript do każdej podstrony

… nawet jeśli skrypt js wykorzystujemy tylko na jednej stronie.

Innym błędem jest nieprawidłowe osadzanie plików biblioteki jQuery, które może prowadzić do kolizji z innymi plikami js, np. tymi dodawanymi przez pluginy lub wykorzystywanymi już przez WordPressa.

WordPress dobre praktykiJak zapobiegać:

Przykłady z poprawnym dodaniem plików js do WordPressa można zobaczyć w tutorialu Jak zintegrować dowolną galerię jQuery z WordPressem:

WordPress błąd dewelopera 5

Wpisanie na sztywno do plików php tytułów bloków, nagłówków itp:

Zaszywanie w kodzie czegokolwiek, co stanowi treść strony jest nieeleganckie. Napisanie motywu w którym wszystko jest parametryzowalne, edytowane z poziomu panelu użytkownika to czasochłonny proces i wyższa szkoła jazdy (trzeba wiedzieć jakie mamy możliwości alternatywne i wgłębić się w tajniki WordPressa). Istnieje jednak cześć napisów, co do których możemy przewidzieć, że użytkowink będzie chciał je sam zmienić. Przykładowo zaszycie w pliku php napisu jak niżej, nie jest najlepszym pomysłem:


<h2>Napisz do mnie</h2>

Kiedy to się zemści:
Kiedy klient zmieni zdanie i powie, że chce, aby ta sekcja nazywała się jednak „Napisz do nas”. Trzeba robić zmiany w kodzie.

WordPress dobre praktykiJak zapobiegać:

WordPress błąd dewelopera 6

Nieznajomość standardów pisania motywu pod WordPressa

Nie jestem zwolenniczką hasła „Procedury są po to, by je łamać”, uważam, że standardy wymyślono, żeby ułatwić ludziom życie. Kodeks WordPressa poświęcił im cały pokaźny rozdział. Warto się z nimi zapoznać, nawet jeśli używamy WordPressa do osadzenia strony stanowiącej CMS.

WordPress dobre praktykiNiektóre wybrane zalecenia Kodeksu dla deweloperów:

Wykorzystując w znaczniku body funkcję body_class() łatwiej wystylizujesz różne części strony, również ułatwisz sobie życie w odnalezieniu się w witrynie za jakiś czas, kiedy klient zleci zmiany, a Ty już zdążyłeś zapomnieć, co jest czym. Dzięki użyciu tej klasy w podglądzie źródła danej podstrony w tagu <body> zobaczysz w oparciu o jaki szablon (plik php) została ona wygenerowana.

  • Podczas przeplatania języka PHP z kodem HTML stosowane wcięcia powinny odzwierciedlać strukturę otaczającego kodu HTML. Zobacz przykład »

WordPress błąd dewelopera 7

Brak strony obsługi błędu 404

W WordPressie nie jest jeszcze tak źle. Dzięki hierarchii szablonów (ang. tempalte hierarchy) w przypadku próby wejścia na stronę, która nie istnieje, zostanie wykorzystany plik index.php. Odwiedzający będzie przynajmniej wiedział, że jest nadal w naszym serwisie. Jednak brak strony 404 jest jednym ze skutecznych sposobów wyproszenia użytkownika z naszej witryny, a tego raczej nie chcemy.

WordPress dobre praktykiJak zapobiegać:

WordPress błąd dewelopera 8

Zamieszanie w kwerendach (ingerencja w podstawową pętlę the_loop)

To temat rzeka (i materiał na osobny artykuł). Bardzo często jednak nieumiejętne poruszanie się w kodzie głównej pętli WordPressa jest przyczyną trudnych do wychwycenia błędów.

Potrzeba wyświetlenia wpisów w inny sposób niż daje nam tradycyjna pętla the_loop zachodzi często. Chcemy wyświetlić np. tylko 5 pierwszych wpisów i pochodzących z danej grupy kategorii. Albo wbić się z czymś dodatkowym w środek tej pętli. W tym celu najczęściej używamy funkcji query_posts lub budując nowe query.

WordPress dobre praktykiO czym powinniśmy pamiętać:

  • nieumiejętnie ingerując w podstawową pętlę możemy utracić jej główny kontekst, a co za tym idzie prawidłowe działania tagów warunkowych
  • wykorzystując query_posts:
    • generujemy nowe zapytanie SQL do bazy (co jest czasochłonne)
    • tracimy dostęp do parametrów, które normalnie otrzymujemy w URL-u (np. nr strony, kategorii)
    • po skończeniu z korzystania z query_posts należy wywołać wp_reset_query();
  • w pętlach wielokrotnie zagnieżdżonych można wykorzystywać funkcję get_posts

WordPress błąd dewelopera 9

Rozwijanie strony w żywym środowisku jeszcze w czasie jej budowy

Odrobina wysiłku włożonego w instalację drugiego WP zaoszczędzi nam sporo frustracji i… wstydu. Przyda się również, kiedy klient zażyczy sobie zmian w przyszłości – będzie możne je przetestować zanim błąd rozłoży stronę, na której mamy już sporo wizyt dziennie.

WordPress dobre praktykiDobre rady:

  • Unikaj poprawek w kodzie „na żywym organizmie”, nawet jeśli jesteś doświadczonym programistą i wydaje Ci się, że wiesz, co robisz i w razie czego szybko opanujesz błąd. Nigdy nie wiadomo, ilu klientów witryny Twojego klienta odwiedziło stronę właśnie w momencie kiedy „się wysypała”.
  • Załóż witrynę testową dla tworzonej lub rozwijanej witryny. Możesz to zrobić:
    • w podkatalogu w domenie klienta
    • w podkatalogu we własnej domenie
    • wykorzystując jakiś darmowy hosting
    • lub po prostu na lokalnym komputerze
  • Jeśli jesteśmy zmuszeniu do budowania strony w domenie docelowej, to przynajmniej na ten czas wyłączmy ją z wyszukiwarek (Ustawienia->Prywatność).
  • W witrynie testowej zablokuj dostęp botom indeksującym. Ochroni to nas przed duplicate content.

WordPress błąd dewelopera 10

Brak testów

„Po co marnować czas na testy przy małej witrynie?”, „Najlepszym testerem i tak jest życie.” Z takim opiniami się spotykam nawet wśród webmasterów z dużym doświadczeniem. Nikt nie poleci Twoich usług kolejnym osobom, jeśli zdążył się przekonać, że to co od Ciebie dostał jest słabej jakości.

WordPress dobre praktykiNiektóre dobre praktyki:

  • Testuj na bieżąco.
  • Jeśli to możliwe zaangażuj do testów kogoś innego. Będąc autorem programu podświadomie chcesz, aby witryna zachowywała się poprawnie. A celem testów jest wytknięcie błędów.
  • Testuj na stronie wypełnionej danymi
  • Korzystaj z deweloperskich narzędzi:
    • Poznaj zalety i możliwości Firebuga
    • Zainstaluj pasek deweloperski dla Firefoksa (mój ulubiony)
    • Zainstaluj DebugBar dla Internet Explorera. Pozwoli on obejrzeć stronę w dowolnej wersji przeglądarki IE na naszym komputerze bez konieczności ich instalowania

WordPress błąd dewelopera 11

Lekceważenie wsparcia dla SEO na poziomie pisania motywu

„Zadbać o SEO w czasie pisania kodów? Przecież od tego są wtyczki.” „WordPress jest i tak idealnie zoptymalizowany pod wyszukiwarki internetowe”. „Największy wpływ na SEO ma przecież content wprowadzany przez użytkownika…”. Tak, to wszystko prawda, ale to na deweloperze spoczywa obowiązek zbudowania odpowiedniej struktury HTML-owej i hierarchii nagłówków.

WordPress dobre praktykiDobre praktyki SEO na poziomie pisania kodu:

Przykład:
Często nagłówek h1 rezerwowany jest dla tytułu witryny zamiast dla tytułów wpisów/stron.

Rada: klikane logo czy tytuł witryny zaprezentuj jako div, a h1 przydziel do wyświetlania tytułów wpisów i stron. Stron konkurujących z nazwą firmy naszego klienta jest raczej niewiele, Google i tak zadba o jej wysoką pozycję po wpisaniu jej nazwy w wyszukiwarce.

WordPress błąd dewelopera 12

Specjalne wytyczne dla użytkownika, żeby strona działała

Klient dzwoni, że coś przestało działać, a on nic nie zrobił, tylko wpisał to i owo. Odpowiadamy:

  • wysypało się, bo użyto tu tagów html-owych , a nie wolno…
  • nic dziwnego, że nie działa – ktoś podał dziwny format daty w formularzu

WordPress dobre praktykiDobre rady:

  • Zadbaj, aby Twoja strona była intuicyjna w edycji dla przeciętnego użytkownika
  • Podczas pisania motywu unikaj wszelkich praktyk, opartych o zasadę: „to będzie działać pod warunkiem…” np:
    • „nie wolno tu wpisywać tego i tego”
    • „trzeba ten fragment zapisać to w bloku div z klasą X”
  • Nie wymuszaj doinstalowania jakiś wtyczek, w celu zlikwidowania błędu

WordPress błąd dewelopera 13

Polsko-angielski miks na stronie

To jeden z grzechów głównych przede wszystkim na blogach, wynikający z nieumiejętności spolszczenia skórki WordPressa. Na stronach opartych o WordPress funkcjonujących jako CMS też to się zdarza, a wynika m.in. z:

  • wykorzystania fragmentów kodu z innych motywów i pozostawienia w nich angielskich wersji komunikatów np:
<?php printf('View all posts by %s'), get_the_author() ); ?>
  • braku wsparcia dla tłumaczenia (pomijanie funkcji _e oraz __ dla wyświetlanych napisów)

WordPress dobre praktykiDobre rady:

  • Konsekwentnie używaj jednego języka
  • Pisanie motywów pod blogi dla ogólnego użytku wymaga oparcia się o język angielski. Wykorzystując WordPressa jako CMS dla polskiej witryny spokojnie można przyjąć jako bazowy język polski.
  • Nie tłumacz się: „Comments”, „Author” i tak wszyscy zrozumieją o co chodzi. Pozostawianie takich angielskich wstawek świadczy o Twojej niedbałości lub niewiedzy.
  • Wyślij czasem mail sam(a) do siebie. Albo wpisz komentarz na stworzonej przez siebie stronie jako użytkownik z zewnątrz. Znam blogi dbające o wykorzystanie języka polskiego w każdym calu swojej witryny, a mimo to wysyłające zawiadomienia o komentarzach, nowościach w języku angielskim.
  • Wyrób sobie nawyk wpisywania wszelkich treści z użyciem funkcji _e i __ (podwójne podkreślenie). Przyda się, kiedy nasz klient zażyczy sobie w przyszłości dostosowanie strony do innych wersji językowych.
  • Dowiedz się co to są pliki po i mo oraz jak działa mechanizm spolszczania skórek »

WordPress Wasze doświadczenia

Jakie błędy Wy kojarzycie?

A z jakimi częstymi błędami deweloperskimi Wy się spotkaliście? Albo jakie były Wasze, które utkwiły Wam w pamięci?

WordPress wpadka
U mnie była to sytuacja pochodząca pod paragraf 12. z powyżej listy. Automatyczne dodawanie paragrafów przez WordPressa naruszało mi elegancki design strony (margines dolny pochodzący z akapitów wyglądał źle pod obrazkami, które zostały gratisowo obleczone w blok <p></p>).

Wyłączyłam więc to autowrappowanie funkcją:

remove_filter('the_content', 'wpautop');

no i powiedziałam klientom, że treść artykułów powinni wprowadzać tylko w trybie HTML-owym a każdy akapit owijać w znaczniki <p></p>. I oni biedni tak się męczyli… Aż pewnego dnia sama byłam zmuszona dodać w ten sposób jeden artykulik. Najpierw trochę poprzeklinałam, a później zadzwoniłam do klientów z propozycją, że chętnie im to zmienię…

Zapraszam do dzielenia się własnymi doświadczeniami.

Inne wpisy o podobnej tematyce:

52 komentarze do “WordPress jako CMS – najczęstsze błędy deweloperów”

  1. Świetny art, jak będę zabierał się, za tworzenie następnej skórki pod WP, to przeczytam tak z 5x i postaram się zastosować powyższe rady.

    scy

  2. Genialne porady. Czytając ten tekst, człowiek zdaje sobie sprawę jak mało tak naprawdę jeszcze umie. To w zasadzie podstawy budowania stron internetowych na wordpressie, a jak łatwo o nich wszystkich zapomnieć.
    Bardzo przyjemnie czytało mi się Twój tekst. Pozdrawiam.

    1. Dziękuję za miły komentarz. Życzę rozwoju pasji i aby hasło „Człowiek zdaje sobie sprawę jak mało tak naprawdę jeszcze umie” już przy kolejnym Twoim WordPressowym projekcie zostało zastąpione „człowiek zdaje sobie sprawę, ile nowego się nauczył” ;-).

  3. przede wszystkim ja bym z grubsza potraktował złą ingerencję w PHP, jeżeli ktoś niezbyt się zna na PHP’ie nie powinien się zbyt panoszyć po edytorze, a już w szczególności nie zmieniać działania funkcji, bo w najlepszym przypadku skończy się to tylko reinstalacją motywu i nową jego konfiguracją. Zdarza się również, że trzeba przeinstalować całego wordpressa, szczególnie przy kombinacjach z bazami danych 🙂

    1. Dzięki za komentarz. Racja, nieumiejętna ingerencja w kod motywu, to proszenie się o kłopoty. Pisząc artykuł podeszłam do tematu z punktu widzenia osoby, która tworzy motyw od zera (lub na bazie istniejącego), ale jak najbardziej zgadzam się z tym, że sytuacja o jakiej piszesz, jest powszechna wśród osób próbujących swoich sił w samodzielnym dostrajaniu gotowych skorek do swoich potrzeb.

    1. Skoro część się pokrywa, to dobrze, w końcu „Great minds think alike” 😉
      Ja też się kilka ciekawych rzeczy dowiedziałam z Twojego artykułu, ale to Ci napiszę więcej w komentarzu pod nim.

  4. Świetny artykuł, choć ja nie tworzę skórek i wiele z podanych przez ciebie informacji to dla mnie novum :). Głównie pracuję na Thesis w ramach, którego dokonuję niezbędnych modyfikacji w kodzie.

    Dziękuję za wzmiankę:-)

    Serdecznie pozdrawiam

    1. Z zupełnie dla mnie niezrozumiałych powodów Twój komentarz automatycznie został zaklasyfikowany jako spam. Właśnie go stamtąd wyłowiłam 🙂

      Miło mi, że nawet spece od WP Twojej ligi mogą skorzystać na prezentowanych tu wpisach.

      Justyna, a czy Thesis można bez problemu dostosować do dowolnego layoutu graficznego czy raczej wszystkie strony oparte o niego wyglądają pod tym kątem podobnie? Jeśli to nie kłopot, to może podałabyś kilka linków do stron działających o Thesis (za wyjątkiem Twojego bloga oczywiście, bo go znam)?

      Pomyślałam teraz, że może nie warto za każdym razem wyważać otwartych drzwi i pisać wszystkiego od nowa, w końcu tworzenia od zera własnego motywu to mnóstwo pracy. Być może właśnie Thesis jest pod tym względem wartym zapoznania się „kompromisem”?

      1. Cześć Aga,

        też nie rozumiem, dlaczego mój komentarz tak został zakwalifikowany…

        Ale cieszę się, że go odspamowałaś 🙂

        Odpowiadając na Twoje pytania: Thesis można śmiało dostosować do praktycznie każdego layoutu graficznego. Można na tym szablonie stworzyć każdy rodzaj strony, pracując w custom_functions.php i custom.css.

        Zobacz przykłady różnych stron zbudowanych na Thesis:
        http://www.thesmania.com/portfolio/
        http://diythemes.com/showcase/

        Thesis jest zdecydowanie wart zgłębienia, tym bardziej, że jest jednym z najlepiej zoptymalizowanych szablonów w zakresie SEO.

        Pozdrawiam serdecznie
        Justyna

        1. Też nie rozumiem, nigdy nie wgłębiałam się w algorytm działania Aksimetu, ale miałam już jeden podobny przypadek: do worka ze spamem wpadł komentarz od Małgosi ze strony http://sekretystronwww.pl/, który spamem zdecydowanie nie był.

          Dzięki za linki. Thesis Gallery Showcase to jest dokładnie to, o co mi chodziło. Zapoznam się z tym jak i z całą ideą i na pewnie za jakiś czas podzielę wrażeniami.

  5. Przyznaję się szczerze, że 9 punkt zdarza mi się łamać bardzo często, ale tylko na swoich własnych blogach 🙂 Kiedyś trzymałem kilka blogów testowych, ale szybko mi się odechciało zabawy z nimi i od ładnych paru lat wszystkie operacje przeprowadzam na żywym organizmie 🙂

    1. Pewnie jesteś doświadczonym WordPressowcem. Z moich obserwacji wynika, że części początkujących programistów korzystających z WP nawet nie przyszło do głowy, że można postawić coś takiego jak środowisko testowe. Dzięki za komentarz.

      P.S. Pinezki do tablicy korkowej dla geeka (artykuł z Twojego bloga) są bombowe!

  6. Świetny artykuł. Ostatnio wzięłam się za pisanie wtyczek, ponieważ byłam przerażona kodami niektórych z nich. Nasuwał się jeden wniosek: ktoś coś napisał, nie mając większego pojęcia jak – ważne, że działało.

    1. Napisanie dobrej wtyczki to prawdziwe wyzwanie. Świadczy choćby o tym liczba kolejnych wersji tych najpopularniejszych. Dzięki za komentarz.

  7. Może nie na temat – ale długo i namiętnie szukałam w sieci i nic nie znalazłam: czy jest jakaś wtyczka umożliwiająca w łatwy i przyjemny sposób dodać do headera np. widget „szukaj”?

    1. Można to zrobić prosto bez wtyczki:
      1. Sprawdź w katalogu z Twoim motywem, czy jest plik searchform.php. Odpowiada on za wyświetlenie formularza „Szukaj” na stronie.
      2. Jeśli jest, to wystarczy, że w dowolnym miejscu na stronie wyświetlisz go za pomocą instrukcji:

      &lt;?php include(TEMPLATEPATH.'/searchform.php'); ?&gt;
      
      1. Pisząc „w dowolnym miejscu na stronie” miałam na myśli wstawienie go do pliku źródłowego odpowiedzialnego za wyświetlania danej części strony, czyli np. header.php albo index.php itd,, a nie w okno edycji strony z poziomu administracyjnego.

  8. Niestety WordPress ma jeden z najgorszych edytorów wizualnych – bardzo łatwo popsuć layout strony przez automatycznie poprzestawiany kod, usunięte puste paragrafy, div’y i iframe’y, brak możliwości wstawiania tabel i dokładnego ustawienia zdjęć (nie mówiąc o wstawianiu linków w podpisach do nich). Jednym słowem bleee!

    Pozostaje CKeditor i wyłączenie WordPressowego filtrowania.

    1. No tak, czasami ja też ponarzekam na edytor WP, ale generalnie jestem zwolenniczką takiego podejścia, żeby w content strony nie wrzucać divów, iframeów itd, a do edycji elememtów specyficznych dla danej witryny wykorzystywać custom fields, custom post types, short codes i tym podobne rzeczy, które dadzą wygodę użytwnikowi i jednocześnie pozwolą na jego spontaniczność w edycji głównej treści bez obawy, że coś zepsuje.

  9. Hej, niezły zestaw błędów, niezły artykuł. Tylko mam wątpliwości odnosnie punktu nr 3. Kiedy ktoś zechce mieć bezpośrednie, przyjazne linki i zmieni to w ustawieniach, to na sztywno wpisana ścieżka do pliku css (oraz inne) wcale nie przestanie działać.

    1. Dzięki za komentarz i właściwie słuszną uwagę. Teraz, jak do tego wróciłam po roku, to też się zdziwiłam, dlaczego w tym konkretnym przypadku odwołania do css miałby przestać działać. Ale pamiętam, że tak się właśnie działo u początkujących programistów, którzy w ten sposób ładowali plik stylów. Jak sobie nie przypomnę przypadków, kiedy tak faktycznie może się stać, to pomyślę nad zmianą tego punktu, żeby podać bardziej sensowny przykład negatywny, jak choćby to, że pluginy mogą nie widzieć w ten sposób dołączanych plików albo pojawią się problemy przy przenoszeniu WP do innego katalogu czy na inną domenę.

  10. „Jeśli jesteśmy zmuszeniu do budowania strony w domenie docelowej, to przynajmniej na ten czas wyłączmy ją z przeglądarek (Ustawienia->Prywatność).”

    Chyba chodzi o wyłączenie dostępu dla robotów wyszukiwarek, a nie „przeglądarek”…

  11. Jejku, drugi dzień siedzę i czytam wpis po wpisie. Wielkie dzięki Ci za informacje w nich zawarte. Najchętniej dopadł bym jakiejś formy live i pytał, pytał i pytał co nie robić używając WP i tworząc bloga. Mało jest tak konkretnych porad w języku PL. Niby WP jaki jest każdy widzi, ale kodeks WP wykorzystuje może kilka procent użytkowników a jeszcze mniej wie o jego istnieniu. Taką listę błędów jak twoja + rozwiązania powinno się umieszczać na osobnej stronie i rozszerzać. Wielki ukłon w Twoją stronę i szczere podziękowania za trud napisania tego i innych wpisów. Trafiasz do mojej czołówki WP blogów-poradników.

    1. Witam Cię Jakubie. Bardzo mnie ucieszył Twój komentarz. Właśnie dzięki takim wpisom jak Twój mam motywację do dalszej pracy nad blogiem.

      Jeśli masz jakieś ciekawe pytania albo pomysł na następny artykuł, to zapraszam bardzo do dopisania się do zakładki Pomysł na tutorial.

      Właśnie zerknęłam na Twój blog i choć jest świeży, to muszę przyznać, że od początku bardzo porządnie prowadzony. Ten blog gdy powstawał, był jednym wielkim bałaganem (i nadal wymaga porządków :-)). Dodałam sobie Twój blog do mojego czytnika RSS.

      1. Pomysłów i pytań mam całą głowę 😀 muszę więc je nieco poukładać. Ten motyw i ta zawartość mojego bloga to kawał czasu testów i pomyłek, ale choć jak sama napisałaś że lepiej się uczyć na cudzych to własnych się nie uniknie. Blog rzeczywiście jest od niedawna, powoli go rozkręcam. Mam nadzieje że z czasem będę mógł również otrzymywać komentarze które dodadzą mi motywacji. Pozdrawiam serdecznie:D

  12. Świetny blog 🙂 Mam na koncie kilka projektów w WP i z każdym kolejnym uczyłem się czegoś nowego. Dzisiaj trafiłem przez przypadek na Twój blog i na pewno przeczytam go od deski do deski. Masz kolejnego stałego bywalca 😉 pozdrawiam

    1. Dzięki Szakal, nie ma bardziej motywujących komentarzy do dalszej pracy nad blogiem jak takie. Jeśli siedzisz w WP, to zapraszam na WordCampa do Gdańska.

      1. Właśnie coś mi się obiło o uszy o takim spotkaniu ale znalazłem tylko informacje o Wordcampie w Poznaniu w zeszłym roku. Gdańsk to niestety zbyt duża odległość, na którą sobie w tej chwili nie mogę pozwolić (mieszkam na południu PL :))

        1. Faktycznie daleko. Będzie relacja na youtube, to nie to samo, ale pierwszego WordCampa właśnie obejrzałam na youtube, też ma to swoje plusy.

  13. Co prawda developerem nie jestem, ale i tak warto przeczytać o rzeczach, które dotykają także mnie – właściciela małego portaliku.

  14. przeskanowalem strone internetowa zrobiona na platformie wordpressa..skrypt wp wyświetlil blad w sciezce katalog domowy/wp-content/themes/twentythirteen/index.php
    do pliku index.php wstawilem linijke kodu
    ini_set(’display_errors’, 'Off’);
    error_reporting(0);
    gdy to zrobiłem wordpress wyświetlił ponownie blad tylko z odwolaniem do sciezki katalog domowy/wp-content/themes/x/index.php. …katalog x jest katalogiem który figuruje na stronie internetowej..
    do pliku index.php wstawiłem ta sama linijke kodu, nie pomoglo..próbowałem z
    @ini_set(’display_errors’,0); czy tez
    //Turn off all error reporting
    error_reporting(0); nie wyszlo..w pliku wp-config zrobiłem to samo, również nie wyszlo, sprawdziłem define(‘WP_DEBUG’, false) – ustawiona na odpowiednia wartość,
    nie mam dostępu do php.ini, htaccess nie wchodzi w rachube, ponieważ zrywa polaczenie z serwerem – próbowałem w htaccess umieścić
    php_flag display_errors Off lub php_value,..
    pytanie, w ktorym miejscu skrypt ponownie wlacza wyswietlanie bledow..? może należy cos zmienic w functions.php motywu x
    a moze Ty wiesz?

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.