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.

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.

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...

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.

Jeśli to ma być naprawdę masowe, to wstępnej selekcji dokonałbym z wykorzystaniem systemu DNS. Najskuteczniejsze odsianie jest w przypadku sprawdzenia czy domena ma jakieś rekordy NS na głównych DNSach dla danej końcówki (np. a/c/d/e/f/g/h/i-dns.pl w przypadku końcówki *.pl), ale można ograniczyć się do łatwiejszego, szybszego sprawdzenia, czy istnieje rekord A. Brak takich rekordów NIE jest jeszcze definitywnym dowodem na to, że domena jest wolna, ale łatwo i szybko odsiewamy wszystkie te, które są zarejestrowane i mają swoje rekordy DNS. Pozostałe, te które rekordów DNS nie mają, można wrzucić do formularza u jakiegoś rejestratora, np. netoid w tym temacie z maja 2016 roku informował o wykorzystaniu formularza domeny.pl umożliwiającego sprawdzenie 100 domen jednocześnie. Korzystanie z whois sprawdzi się tylko na małą skalę, bo serwery whois mają dość znaczne ograniczenia w tym zakresie. Formularze rejestratorów powinny przyjąć więcej, ale też trzeba liczyć się z jakimiś ograniczeniami jeśli chodzi o ilość zapytań w danym przedziale czasowym.

llu nie pyta o domenę, ale o hosting za 1,80 zł netto za rok (jeden, pierwszy tylko). Faktycznie - jak to często bywa w takich przypadkach - do szczegółowych warunków promocji trudno się dostać. Zgodnie z ogólnym regulaminem hostingowym, po wypełnieniu formularza rozpoczyna się okres testowy (maksymalnie 10 dni), a okres rozliczeniowy zaczyna się po wpłynięciu opłaty. Umowa zawierana jest na czas określony, nie powinno zatem być przymusu przedłużania na kolejny okres. Jest też jednak zapis dotyczący ewentualnych rozbieżności pomiędzy regulaminem ogólnym a regulaminami promocji, wówczas pierwszeństwo stosowania mają regulaminy promocji. Takowego jednak - dotyczącego tej konkretnej promocji - nie udało mi się odnaleźć.

Pamiętaj, że używasz tzw. "child theme", więc część kodu używana jest ze stylu nadrzędnego, a część nadpisujesz w swoim "dziecku". To co chcesz zmienić ujęte jest w stylu nadrzędnym, ale nie modyfikuj go, pliki stylu nadrzędnego zostaw takie jakie są, dzięki czemu będziesz mógł w przyszłości dokonywać uaktualnień bez utraty swoich własnych zmian. Zmiany dokonuj tylko w swoim "dziecku". Zatem z pliku "/wp-content/themes/type/style.css" skopiuj do pliku "/wp-content/themes/type-child-theme/style.css" prezentowany przeze mnie poniżej na samym końcu fragment (nie testowałem, ale to powinno być właśnie to, być może nawet za duży fragment zaznaczyłem) i tu modyfikuj wartość "960px" według uznania. ALE! menu nie-mobilne spokojnie mogłoby wyglądać dobrze w rozdzielczości 960+ px, gdybyś zrobił to, co zasugerował powyżej Mega_88, czyli we wskazanym przez niego fragmencie z ujemnymi marginesami zmień "1024" na "960". Najpierw zastosuj zmianę sugerowaną przez Mega_88 (czyli zmień 1024 na 960 tam gdzie te ujemne marginesy dodajesz). Jak dla mnie wygląda to wówczas dobrze, nic ucięte nie jest. Jeśli zmieniasz typ menu przy 960px, to i rozmiar/marginesy zmieniaj tak samo przy 960px. Obecnie typ menu zmieniasz przy 960px, a rozmiar/marginesy przy 1024px, dlatego pomiędzy 960 a 1024 masz niedopasowane jedno do drugiego. Poniższe TYLKO jeśli zmiana "1024" > "960" z ujemnymi marginesami Ci nie będzie odpowiadać. @media screen and (min-width: 960px) { /* Navigation */ .mobile-navbar, .main-navigation ul .dropdown-toggle { display: none; } .main-navbar { display: block; } .main-navigation { display: inline-block; } .main-navigation ul { display: inline-block; background-color: transparent; text-align: center; } .main-navigation a, .main-navigation li { display: inline-block; } .main-navigation > ul > li > a { padding: 0 10px; margin: 0; color: #222; line-height: 40px; font-size: 14px; font-weight: 700; text-transform: uppercase; border: 0; opacity: 1; transition: color 0.3s ease-in-out 0s; } .main-navigation > ul > li.current-menu-item:before { content: ""; position: absolute; width: 50px; height: 3px; left: 50%; bottom: -5px; ; background-color: #2e64e6; } .main-navigation > ul > li.menu-item-has-children > a, .main-navigation > ul > li.page_item_has_children > a { position: relative; } .main-navigation > ul > li.menu-item-has-children > a:after, .main-navigation > ul > li.page_item_has_children > a:after { font-family: 'Material Icons'; font-weight: normal; font-style: normal; font-size: 16px; /* Preferred icon size */ display: inline-block; line-height: 1; text-transform: none; letter-spacing: normal; word-wrap: normal; white-space: nowrap; direction: ltr; /* Support for all WebKit browsers. */ -webkit-font-smoothing: antialiased; /* Support for Safari and Chrome. */ text-rendering: optimizeLegibility; /* Support for Firefox. */ -moz-osx-font-smoothing: grayscale; /* Support for IE. */ font-feature-settings: 'liga'; content: "\E5CF"; vertical-align: -20%; } .main-navigation > ul > li:hover > ul, .main-navigation > ul > li.focus > ul { top: 40px; } .main-navigation ul ul { display: block; position: absolute; top: 30px; right: 0; padding: 0; visibility: hidden; opacity: 0; border: 1px solid #ededed; transition: top 0.4s ease 0s, opacity 0.4s ease 0s; z-index: 99999; text-align: left; } .main-navigation > ul:before, .main-navigation > ul:after { content: none; } .main-navigation > ul > li > ul:before { border-bottom: 8px solid #fff; border-left: 8px solid transparent; border-right: 8px solid transparent; content: ""; right: 40px; position: absolute; top: -8px; z-index: 19; } .main-navigation > ul > li > ul:after { border-bottom: 10px solid #ededed; border-left: 10px solid transparent; border-right: 10px solid transparent; content: ""; right: 38px; position: absolute; top: -10px; z-index: 16; } .main-navigation ul ul a { width: 160px; padding: 10px 0; border-top: 1px solid #f2f2f2; } .main-navigation ul ul li:first-child > a { border-top: 0; } .main-navigation > ul > li > ul > li.menu-item-has-children > a:after { font-family: 'Material Icons'; font-weight: normal; font-style: normal; font-size: 16px; /* Preferred icon size */ display: inline-block; line-height: 1; text-transform: none; letter-spacing: normal; word-wrap: normal; white-space: nowrap; direction: ltr; /* Support for all WebKit browsers. */ -webkit-font-smoothing: antialiased; /* Support for Safari and Chrome. */ text-rendering: optimizeLegibility; /* Support for Firefox. */ -moz-osx-font-smoothing: grayscale; /* Support for IE. */ font-feature-settings: 'liga'; position: absolute; right: 15px; top: 13px; content: "\E5CF"; vertical-align: middle; } .main-navigation ul ul ul { opacity: 0; top: 0; right: 100%; visibility: hidden; opacity: 0; transition: opacity 0.3s ease-in-out 0s; } }

W międzyczasie zmienił się adres IP, może to zatem kwestia przeprowadzki przeprowadzonej przez kogoś w nie do końca udany sposób. PS. Mój monitor zmiany adresu IP nie uwzględnia w sposób automatyczny, dlatego później "dobijał się" wciąż pod stary i dawał fałszywe wyniki (które usunąłem). Zakładam, że od 10:16 już wszystko działało (o 10:17 już pojawiły się posty).

Nikt nic z DNSami nie zrobi za Ciebie. Transfer domeny to zmiana rejestratora. I nie ma nic wspólnego z tym jakie DNSy domenę obsługują, przy dokonaniu transferu żadne DNSy się nie zmieniają, pozostają wciąż te same, dotychczas ustawione. Chyba, że zaznaczysz opcję, by jednocześnie *dodatkowo* zostały zmienione, ale to Twoja odrębna decyzja "przy okazji", a nie wymuszona transferem. Uwaga: czasem rejestratorzy "podstępnie" mają taką opcję zaznaczoną domyślnie i można ją przegapić przez nieuwagę. Pomimo zmiany rejestratora możesz wciąż korzystać z dotychczasowych DNSów (chyba, że to usługa u byłego rejestratora, więc w ciągu dnia czy trzech przestanie funkcjonować). Albo zmienić na DNSy nowego rejestratora - jednak chyba będziesz mógł strefą na nich zarządzać dopiero po zakończeniu procesu transferu. Albo wybrać jakiekolwiek inne, zewnętrzne od podmiotu trzeciego - ja osobiście takich najczęściej używam, kto inny jest dla mnie rejestratorem, kto inny obsługuje DNSy, kto inny zapewnia mi usługę hostingową i pocztową.

Przeczytałem wczoraj wieczorem tę specyfikację i wygląda to - jak dla mnie - ciekawie, o ile odpowiednie oprogramowanie zostałoby napisane również pod stare systemy operacyjne, aby wystarczyła do nich "mała łatka". W przeciwnym razie, moim zdaniem - odpowiednio mniejszy, ale jednak - pewien procent urządzeń jeszcze przez wiele lat pozostanie wyłącznie w "sieci IPv4", bo jest mnóstwo przykładów, gdzie pomimo ostrzeżeń o bezpieczeństwie itd. itp. urządzenia różnorakie nadal pozostają pod kontrolą systemów uznawanych za przestarzałe i dopóki coś działa to ci właściciele/administratorzy bawić się w zmianę systemu nie będą.

Zmiana wygląda tak, że jak ktoś wieczorem pyta czy "hosting x" to dobry wybór pod nowo otwierane forum i użytkownicy odpowiedzą, że nie i zaproponują co innego (chyba trzy odpowiedzi z pięcioma propozycjami, nie pamiętam dokładnie), to wszystkie te odpowiedzi znikają już pomiędzy 6 a 7 rano. Cóż... pytać o rady co do hostingu już się tutaj nie da. Bo ani "szeptanek" - co zrozumiałe - ani ofert własnych - różne podejście mieć można - ani nawet zwyczajnych dobrych rad od ludzi już tu nie będzie.

Uściślijmy, że "slave DNS" nie jest odpytywany przez klientów tylko i wyłącznie wtedy, gdy "master" ulega awarii. Dla klientów wszystkie DNSy podane u rejestratora dla danej domeny są równorzędne i odpytywane na zmianę. "Master" i "slave" to tylko kwestia wyznaczenia, na którym serwerze strefą zarządza użytkownik, a na którym robiona jest kopia tej pierwszej. Wydaje mi się też, że taki pojedynczy "slave" nie miałby dwóch stref dla jednej domeny, ale jedną strefę, tę z wyższym SOA (albo tę, której aktualizacja została w jakiś sposób wymuszona jako ostatnia). Sugestia mariaczi teoretycznie by podziałała, ale od strony klienta jest bardzo nielubiana, niejednokrotnie uniemożliwia dodanie domeny, gdy również i rejestrator dokonuje sprawdzeń ze swojej strony, a zupełnie zapomnieć można wtedy o sytuacjach, gdy strona przenoszona jest z serwera na serwer i docelowy chcemy przygotować w pełni zanim dokonamy jakichkolwiek zmian DNS, aby uniknąć przerw w działaniu. Alternatywą dla sprawdzania, czy u rejestratora podany jest właściwy DNS, może być sprawdzenie czy domena jest już dodana na innym z Twoich serwerów. Albo poprzez odpytanie wszystkich 'masterów', albo (łatwiej) samego "slave". Nie wiem czy można (i ewentualnie jak) uzyskać to w DA. Choć i to rozwiązanie miałoby wadę, gdyby klient przenosił domenę pomiędzy Twoimi serwerami i chciał przygotować nowy, gdy stary wciąż jeszcze domenę obsługuje. Zależy jak dużo masz tych DA i jak wielu klientów. Im mniej tym mniejsze prawdopodobieństwo, im więcej tym większe zaistnienia opisanej przez Ciebie sytuacji "zdublowanych" domen/stref. Osobiście przy setkach nie znających siebie nawzajem klientów oceniłbym ryzyko na stosunkowo niskie, przy tysiącach klientów (lub mniej, ale gdy siebie nawzajem i swoje domeny znają, np. z publicznego forum przypisanego do hostingu) już chyba raczej nie pozwoliłbym sobie ryzykować. Szczególnie, jeśli ktoś taki "bug" by wykrył, to mógłby celowo cudzą domenę w taki sposób "przejmować".

Również jestem przeciwny jakiemukolwiek wymuszonemu dostosowywaniu się do "jedynego słusznego" wzorca. Już i tak zbyt wiele różnorakich praw, nakazów, zakazów, norm, wytycznych nakładają na ludzi rządy, urzędy, instytucje, służby, krajowe, unijne, międzynarodowe itd. itp. i co za tym idzie zmniejsza się coraz bardziej sfera wolności i różnorakich praw jednostki. Domaganie się jeszcze większej regulacji, choćby tylko czegoś tak mało znaczącego jak "życie" na forum internetowym jest dla mnie głupie. Zwykły ludzki rozsądek czytającego powinien wystarczyć moim zdaniem. Chęć oparcia się na jakiejś automatyce, ścisłym wzorcu bez uwzględniania indywidualności każdej osoby i wpisu lub jedynie na cudzej ocenie (moderacji) to pójście na łatwiznę i jednocześnie zubażanie swoich własnych doświadczeń (choć pewnie oszczędność czasu dla tych, którzy wdali się w jakiś swój życiowy wyścig i czasu do stracenia nie mają, ale to ich własny wybór, że taką drogę wybrali). Mile widziana byłaby też odpowiedzialność za własne słowa po stronie ogłoszeniodawców, szkoda że jest to w zaniku, ale zastępować tego moderacją, automatyką, "jedynym słusznym" wzorcem absolutnie bym nie chciał. Sugestie, uzasadnione podpowiedzi, edukacja (ogłoszeniodawców w tym przypadku) - i owszem. Ale jeśli pomimo sugestii postanowi ktoś się do nich nie zastosować - to jego wolna wola. Wymuszanie czegokolwiek, ścisłe normowanie - absolutnie nie.

Trzecia opcja to podzielenie pliku .sql na mniejsze części. Na upartego można ręcznie w dowolnym edytorze tekstowym, ale są do tego narzędzia takie jak choćby darmowy SQLDumpSplitter itp. Jeśli plik już skompresowany ma 90MB, to z pewnością napotykasz limity najróżniejszego rodzaju, bo pełna wersja ma co najmniej kilkaset MB. Duże bazy najlepiej importować bezpośrednio do mysql, pomijając pośrednictwo PHPMyAdmin itp. Czyli tak jak już wspomnieli przedmówcy - połączyć się przez SSH (jeśli takowy dostęp masz), uruchomić mysql i w konsoli wywołać "use DATABASE_NAME" i "source /path/to/file.sql" (po wcześniejszym wgraniu pliku .sql na serwer). Opcjonalnie podwyższyć można limity PHP i próbować tym PHPMyAdminem. A gdy nie ma dostępu do powłoki na danym serwerze (bo to np. tani hosting współdzielony bez takowego dostępu) ani możliwości podwyższenia limitów PHP, to pozostanie Ci podzielenie pliku na mniejsze części.