Piotr GRD

Po pierwsze: Nie można poprzestać na "diagnozie" (cudzysłów konieczny), że "Firefox wykrył, że serwer przekierowuje żądanie tego zasobu w sposób uniemożliwiający jego ukończenie". Należy prześledzić wszystkie nagłówki, wszystkie kolejne (przynajmniej ze dwa trzy) przekierowania, to potrafi dużo powiedzieć o tym co się dokładnie dzieje, jaka to dokładnie pętla. Po drugie: Ja stawiałbym w pierwszej kolejności na to, że .htaccess przekierowuje na https, a skrypt sklepu na zwykłe http i tak w kółko. Sprawdzana była w ogóle konfiguracja sklepu w tym względzie? Jeśli jest w skrypcie sklepu taka opcja, to najpierw przestawić sklep na https i jeśli działać będzie, dopiero wtedy dołożyć wymuszone przekierowanie w .htaccess (choć może nie będzie trzeba, bo skrypt sklepu wszystkim się zajmie).

Nie. Rekord A ma kierować na adres IP serwera, z którego serwowana jest Twoja strona, a NIE na adresy IP serwerów DNS. Zajrzyj więc do strefy DNS na swoim hostingu i skopiuj je (rekordy A/AAAA dla domeny głównej, subdomeny 'www' i ewentualnie innych subdomen, których używasz) stamtąd, albo w inny sposób zdobądź adres IP serwera, który serwuje Twoją stronę (powinien być w panelu kontrolnym hostingu, zapytaj obsługi, albo użyj DiG i odpytaj DNSy hostingu o swoją domenę).

Nie każdy szablon zawiera plik loop.php, szablony mają najróżniejszą strukturę plików. Cała ta "pętla / loop" może być zawarta w samym "index.php" szablonu, albo w zupełnie innym pliku, gdzie zaczynać się będzie od czegoś takiego jak "while (have_posts())". Spójrzcie chociażby na domyślne szablony: taki "twentyten" ma wspomnianą pętlę właśnie w pliku "loop.php", ale już "twentyeleven" zaczyna i kończy pętlę w "index.php", a cały środek pętli zawarty jest w "content.php" i wielu plikach "content-***.php". Ale tak, skorzystać należałoby w odpowiednim miejscu z "the_excerpt()" lub "get_the_excerpt()", w zależności od tego, czy po prostu wyświetlamy w danym szablonie zawartość tak jak domyślnie jest przygotowana przez Wordpressa, czy też jeszcze jakoś ją dodatkowo "obrabiamy". Zacznij więc od "index.php" i wewnątrz niego szukaj tejże pętli, albo odwołań do innych plików, w których tę pętlę z właściwym fragmentem kodu znajdziesz.

Nie tak dawno prowadziłem rozmowę ze znajomymi na temat domeny w podobnej formie właśnie, dlatego przedstawię to, co jako swoją opinię wyraziłem wtedy właśnie. Nie znam się na tzw. "SEO", więc w tej kwestii się nie wypowiadam. Szczerze mówiąc nie bardzo mnie interesuje jakieś "pozycjonowanie", dla mnie najważniejszy jest zawsze bezpośredni wpływ strony i jej adresu na żywych odwiedzających, na ludzi, wpływ pośredni poprzez wyszukiwarki ma dla mnie drugorzędne znaczenie, a same boty wyszukiwarkowe i ich algorytmy w ogóle mają u mnie niski priorytet. Skupiłem się na tym jak nazwa domeny będzie przekazywana potencjalnym i rzeczywistym klientom (chodziło tam o stronę dla małej firmy usługowej). Z przekazywaniem w formie linków na forach, w emailach itp. nie ma problemu. Publikowanie nazwy w formie pisemnej na różnego rodzaju ulotkach, wizytówkach też nie powinno stanowić problemu. Ale czasem przecież rozmawia się z kimś twarzą w twarz, albo przez telefon - czy wtedy nie pojawi się problem? Nie chodzi tylko o samą cyfrę, to tylko pierwszy "niuans" wymagający uściślenia przy każdorazowym słownym przekazywaniu adresu, tak by nie było wątpliwości po drugiej stronie. Pojawia się tu (i w przypadku moich znajomych, i w przypadku Twojego przykładu) mieszanie języków. W przypadku znajomych można założyć, że 99% klientów będzie polskojęzycznych. Nie wiadomo, czy wszyscy oni będą wystarczająco dobrze znali angielski. Jak zatem wypowiadać taką nazwę domeny? "siks ałers dot pi el" - po angielsku? Ale to w końcu Polacy będą zazwyczaj, więc może lepiej "sześć ho urs kropka pe el (szóstka na początku cyfrą)"? Nie za bardzo mi językowo pasuje - a dość często stosowany - "miszmasz językowy": "siks ałers kropka pe el". Ale to tylko moje skromne zdanie. Zależy czy w ogóle i jak często będzie konieczny przekaz słowny nazwy domeny, do kogo w ogóle strona będzie kierowana.

Czyżby motyw, który kupiłeś, miał w sobie zaszyte jakieś "anty-childowe" zabezpieczenie? Jeśli wszystko jest jak należy i identyczny sposób działa w przypadku innych motywów, to inaczej wytłumaczyć tego nie potrafię. Teoretycznie wyobrażam sobie, że możliwe jest zakodowanie czegoś takiego (choć nie wiem dokładnie jak, trzeba by się wgryźć dokładnie w sposób obsługi motywów przez Wordpress), ale nie rozumiem po co miałby to ktoś robić. Widywałem już zakodowane fragmenty motywów Wordpressa tak, aby niemożliwe było łatwe usunięcie linku autora ze stopki itp., ale...

Ten temat jest (darmową) odpowiedzią na temat: Wordpress - stworzenie Child Theme napisany przez @kacper3355 Nie rozumiem osób, które korzystają z wtyczek do tego, jeśli "ręcznie" jest to banalnie proste. Źródło porad i bardziej szczegółowe informacje: https://codex.wordpress.org/Child_Themes Tworzenie "child theme". Stwórz nowy katalog wewnątrz "wp-content/themes", nazwa katalogu może być dowolnie wybrana przez Ciebie. Wewnątrz tego katalogu obecne muszą być dwa pliki: "style.css" i "functions.php". W pliku "style.css" umieść następującą zawartość: /* Theme Name: ORYGINALNY THEME Child Description: Child theme for the ORYGINALNY THEME Template: ORYGINALNYTHEMEFOLDER */ @import url("../ORYGINALNYTHEMEFOLDER/style.css"); Zamień "ORYGINALNYTHEMEFOLDER" poprzez rzeczywistą nazwę folderu ze swoim oryginalnym motywem. Teraz wejdź do panelu Wordpressa, do zarządzania motywami i wybierz swój nowy motyw "ORYGINALNY THEME Child". I już, "Child Theme" działa. Jak wykonywać zmiany? Zmiany CSS dodawaj w utworzonym powyżej pliku "style.css" !poniżej! "@import". Jeśli ma to być modyfikacja istniejącego oryginalnego stylu, skopiuj wybrany fragment z oryginału i zmieniony umieść w "dziecku". Zmiany funkcji dodawaj w "functions.php". Plik "functions.php" "dziecka" jest wczytywany najpierw, plik "functions.php" nadrzędnego stylu w drugiej kolejności. To istotne w przypadku tworzenia funkcji o tej samej nazwie, o tym samym zastosowaniu. Zmiany w pozostałych plikach (page.php, header.php, footer.php itd.) dokonuj poprzez skopiowanie oryginalnego nadrzędnego pliku do folderu "dziecka" i wykonanie zmian w tejże "dziecięcej" kopii. Wszystkie te pliki (poza style.css i functions.php) jeśli istnieją, są pobierane z folderu "dziecka", jeśli nie istnieją, wówczas używane są te z nadrzędnego oryginału. Aktualizacje Aktualizacje nadrzędnego motywu mogą być bezproblemowo wykonywane i nie mają wpływu na "dziecko" do czasu, gdy są to zmiany "kosmetyczne". Jeśli jakiś nadrzędny motyw zmieni się w sposób znaczący, w szczególności jeśli zmieni się struktura plików tego nadrzędnego motywu, nasze "dziecko" może już nie pasować. WAŻNE Opisany przeze mnie sposób tworzenia "dziecka" jest sposobem najłatwiejszym, ale przestarzałym, nieoptymalnym (chodzi o "@import" w CSS). Sposób nowszy, zalecany, optymalny jest nieco bardziej skomplikowany odnośnie wskazywania używanych plików CSS motywu nadrzędnego i dziecka, do tego odnoszą się te nieco skomplikowane opisy używania "wp_enqueue_scripts" i "wp_enqueue_style" w pliku "functions.php" w tekście, do którego umieściłem powyżej link. Nie ma jednak najmniejszego problemu, by sposób ten zastosować później, gdy "child theme" będzie już zawierał modyfikacje. Uwagi, aby ułatwić sobie pracę Dobrze jest - czy to w stylu CSS czy to w plikach PHP - umieszczać komentarze, czego dotyczy zmiana. Gwarantuję, że po kilku latach i naniesieniu kilkudziesięciu drobnych zmian może okazać się, że bez komentarzy nie ogarniemy wszystkiego, lub zajmie nam to znacznie więcej czasu. Zapomnijmy o łatwym połapaniu się w kodzie bez komentarzy, jeśli operować będzie na nim kilka osób. Przy przesyłaniu plików poprzez FTP dobrze używać jest trybu binarnego (nie tekstowego). Zamiana znaków końca linii pomiędzy systemami w trybie tekstowym nie zawsze działa jak należy, czasami następuje "rozstrzelenie" kodu w co drugą linijkę, poza tym tracimy możliwość porównywania plików na podstawie rozmiaru w bajtach. Dobrze - moim zdaniem - jest również zachowywać datę modyfikacji pliku przy kopiowaniu go z serwera na dysk lokalny lub przy tworzeniu kopii zapasowej. Przy tworzeniu archiwów tar.gz bezpośrednio na serwerze nie ma z tym problemu, ale przy przesyłaniu przez FTP należy zaznaczyć odpowiednią opcję w używanym oprogramowaniu. Umożliwia to porównywanie plików na podstawie daty modyfikacji - które kiedy i czy w ogóle zmienialiśmy.

Przed dziesięciu - kilkunastu laty takie serwisy były bardzo popularne i było ich sporo (xt.pl, bee.pl, uni.cc, co.cc - to kilka najbardziej znanych), lecz nie ma po nich śladu. Obecnie jedyny jaki znam to freedns.afraid.org - istnieje już dość długo, jest tam wiele domen będących czy to w gestii samego właściciela serwisu czy to innych użytkowników, którzy w zamian za darmowy serwis DNS udostępniają możliwość tworzenia subdomen. Musisz brać pod uwagę, że domeny od użytkowników mogą zniknąć w każdej chwili. Te od właściciela serwisu są jakoś tam przez niego gwarantowane, serwis istnieje wiele lat, utrzymał się najdłużej ze wszystkich, ale też żadnej 100-procentowej gwarancji tego, że przez kolejną dekadę będzie to działać bez zmian nie masz. A subdomeny od firm hostingowych są zazwyczaj przypisane tylko do serwerów danego hostingu i z reguły nie da się ich przypisać nigdzie na zewnątrz. .tk ma złą reputację nie tylko ze względu na wykorzystywanie tych domen do nadużyć, ale i ze względu na to, że popularne domeny serwis potrafi po jakimś czasie nagle i bez słowa przejmować i każe sobie za nie słono płacić. Jeśli masz zamiar prowadzić jakiś poważny i wieloletni projekt, to chyba najrozsądniej będzie wesprzeć się zwyczajną, płatną domeną - choćby najtańszą z jakąś "dziwną" końcówką, albo regionalne "pl-ki" (patrz na koszt przedłużenia, a nie jakąś promocyjną cenę pierwszego roku). Z hostingów, serwerów poczty itd. itp. również osobiście korzystam darmowych, jednak domeny mam "swoje", w ten sposób mam zapewnioną ciągłość swoich projektów, nawet jeśli któryś darmowy usługodawca zniknie. Gdyby zniknęła domena - nie ma ciągłości.

Jeśli nie będziesz miał żadnej strony, a chodzi jedynie o skonfigurowanie rekordów DNS dla innych usług, to - jak wspomniał zlotowinfo2 - możesz skorzystać z usługodawców DNS. Nie tylko CloudFlare (jako same DNS, bez korzystania z ich CDN), ale choćby freedns.42.pl i kilka innych. Poza tym wielu rejestratorów domen ma wliczoną w cenę rejestracji domeny podstawową usługę DNS, można skorzystać więc z usługi rejestratora (zależy gdzie trzymasz domenę). Szczególnie, że w najtańszych i darmowych hostingach www dość często nie ma możliwości swobodnej edycji rekordów DNS, więc nawet korzystając z takiego hostingu dla utrzymania strony www nierzadko musiałbyś i tak skorzystać z innego, niezależnego usługodawcy DNS, by stworzyć rekord A/AAAA (i ewentualnie SRV się przydaje dla ts3) kierujący gdzie indziej niż tenże hosting.

Nie ma wielkiego znaczenia kto jest rejestratorem Twojej domeny. Istotne jest, jakie serwery DNS wykorzystujesz dla swojej domeny. Jeśli DNSy OVH, to na nich, a jeśli inne, np. od jakiegoś hostingu, to na DNSach tegoż hostingu, konfigurujesz rekordy MX zgodnie z instrukcjami od usługodawcy poczty. Rekordy MX właśnie decydują gdzie będzie trafiać poczta przychodząca na Twoją domenę.

Zainteresuj się rekordem SRV dla TS3. Wyglądać to powinno mniej więcej tak: _ts3._udp.sbg.example.com. 86400 IN SRV 0 5 9987 sbg.example.com. sbg.example.com. 86400 IN A 1.2.3.4 Gdzie "1.2.3.4" to IP Twojego serwera TeamSpeak, "9987" to numer portu, na którym działa.

@TTL Chyba nie sądzisz, że firmy organizujące tego typu promocje liczą na to, że 100% klientów pozostanie na dłużej. Liczą, że *jakaś część* klientów zostanie na dłużej. I z reguły takie promocje pojawiają się w firmach, gdzie standardowe stawki są na tyle wysokie, że to im i tak się opłaca, bo bez promocji tylko osoby nierozeznane w rynku decydują się płacić tak dużo. A osoby rozeznane w rynku zrobią dokładnie tak jak zlotowinfo2 i nie ma w tym absolutnie nic złego ani nic niespodziewanego, duże firmy zdają sobie z tego sprawę i mają to "wliczone w cenę".

Faktycznie, nikt by się tego nie spodziewał. Pierwszy raz widzę coś takiego. Nie dość, że mają wysokie ceny domen, to jeszcze biorą pieniądze za to, że od nich odchodzisz... Coś takiego trzeba publikować głośno, bo faktycznie, mało kto rejestrując domenę zajrzy do sekcji cennika "inne usługi". Domeny.pl, cytuję cennik:

Nie znam tematu u tego konkretnego rejestratora, ale zapytam na wszelki wypadek: Czy nie rejestrowałeś przypadkiem tej domeny w jakiejś ich promocji typu (obecnie trwająca) "Domenobranie"? Niestety standardem u zdecydowanej większości tych najdroższych rejestratorów jest mamienie ludzi promocjami na rok pierwszy i jednoczesne umieszczanie w regulaminie promocji zapisu, że w razie chęci przeniesienia domeny do innego usługodawcy zobowiązujesz się albo do minimum jednorazowego odnowienia u nich, albo do wyrównania różnicy między ceną promocyjną a zwykłą. JEŚLI masz tę domenę w promocji, to zapewne o to chodzi, o warunki promocji, które zaakceptowałeś. Przykład z obecnie trwającej: Z tych promocji u drogich rejestratorów to można korzystać wyłącznie, jeśli z domeny ma się zamiar korzystać rok, a później ją porzucić. Jeśli ma się zamiar utrzymywać domenę dłużej, to już w dwuletnim okresie taniej wychodzi bez żadnych promocji wziąć domenę u tańszego rejestratora. A tak na marginesie... te obecne ceny promocyjne za rok pierwszy u omawianego rejestratora są takie jak zwyczajne ceny gdzie indziej... W przypadku *.eu AuthInfo można pobrać sobie pomijając rejestratora (choć i tak mógłby wysyłać upomnienia odnośnie zapłaty). W przypadku *.pl można by się odwoływać do NASKu, kod musiałby rejestrator wydać, ale i tak pewnie upominałby się o zapłatę. W przypadku *.com nie znam procedur. Zajrzyj w whois kto jest Twoim faktycznym rejestratorem (bo polskie firmy zazwyczaj tylko pośredniczą w rejestracji domen globalnych), napisz do niego. Ale i tak pewnie domeny.pl będą upominać się o zapłatę, nawet jak dostaniesz AuthInfo od "nadrzędnego" rejestratora.

Przeczytaj mój ostatni akapit. Przecież tworzysz SRV "_ts3._udp.example.com.", a NIE "_ts3._udp.ts3.example.com.".

Potrzebujesz dwóch rekordów, SRV i A. Wyglądać one powinny mniej więcej tak: _ts3._udp.example.com. 86400 IN SRV 0 5 9987 ts3.example.com. ts3.example.com. 86400 IN A 1.2.3.4 Gdzie "1.2.3.4" to IP Twojego serwera TeamSpeak, "9987" to numer portu, na którym działa. Subdomena "ts3" (lub jakakolwiek inna dowolnie przez Ciebie wybrana) musi mieć odpowiedni rekord A kierujący na adres IP serwera TeamSpeak i dokładnie ona musi być użyta jako wartość końcowa dla rekordu SRV "_ts3._udp". Zarówno strona jak i serwer ts3 dostępne będą po wpisaniu "example.com" bez konieczności znajomości adresu IP ani numeru portu przez użytkowników.