Fizyda

Z ciekawości, czemu postawiłeś wszystko na osobnych virtualkach? I czemu postawiłeś dwa dnsy skoro i tak stoją na jednej matce - nie wystarczyłby jeden widoczny z dwóch różnych adresów ip? Nie czepiam się konfiguracji, po prostu jeśli chodzi o administrację to jestem noobem i staram się wykorzystać każdą możliwość do zdobycia nowej wiedzy, a konfiguracja wydała mi się ciekawa bo zrobiłbym to zupełnie inaczej.

Budżet to nie cena, a przydaje się po to, że jeśli dla mnie coś to koszt od 200zł, a Twój budżet to 100zł to szkoda tracić czas na wyceny, dogadywanie się, analizowanie problemu bo i tak się nie dogadamy. Tym bardziej, że po przeanalizowaniu problemu i wycenie może okazać się np. 500.

Budżet?

Patrz tabelkę: https://pl.wikipedia.org/wiki/Webmaster Patrz gwarę: https://pl.wikipedia.org/wiki/Programista Pierwsza lepsza oferta o pracę Java Web Developer Do Twoich obowiązków będzie należało: Tworzenie innowacyjnych rozwiązań webowych Usprawnianie istniejących komponentów oprogramowania Współpraca w międzynarodowym środowisku Jeśli czytasz dalej to powinieneś umieć: Programować w Java oraz Javascript Znać Html oraz CSS Podkreślone oznaczają programowanie, nie projektowanie. Swoją drogą jak chcesz tworzyć oprogramowanie nie programując? To bardzo ciekawa teoria. źródło: https://www.pracuj.pl/praca%2Fweb%20developer%3Bkw Jeszcze przykład z FrontEnd Developer Wymagania: znajomość frameworka Angular2 lub innego, np. AngularJS, React.js, Backbone.js, Ember.js dobra znajomość języka JavaScript (ECMAScript6) wiedza z zakresu HTML5, CSS3, jQuery doświadczenie z Bootstrap, preprocesorami LESS lub SASS dobra znajomość standardów W3C i zagadnień związanych z browser-compatibility umiejętność pracy z systemem kontroli wersji GIT dobra znajomość języka angielskiego (zarówno w mowie, jak i piśmie) umiejętność analitycznego myślenia chęć i determinacja do rozwoju oraz dalszej nauki Podkreślone to umiejętności z zakresu programowania. PS. Frontendowiec to też programista, ale specjalizujący się we frameworkach i bibliotekach przeznaczonych na frontend, a w szczególności w języku programowania JavaScript. Dodatkowo fontend dzieli się dla Twojej wiadomości na backend i view więc masz dodatkowe pole do wymyślania sobie różnych rzeczy Myślę, że nasze doświadczenie jest zupełnie odmienne i tyle w temacie. Schodzisz na tematy wręcz filozoficzne zupełnie tak jakby brakowało Ci jakichkolwiek argumentów. Dziwie się, że osoba z takim doświadczeniem może tak bardzo mieszać niektóre pojęcia i tak daleko odejść od tematu. Na każdą Twoją opinię przedstawiłem argumenty które ją podważały lub obalały dodatkowo przytaczałem argumenty popierające moje zdanie. Ty nic poza negowaniem tego co piszę nie napisałeś, żadnych argumentów popierających Twoje zdanie, jedyny to Twój argument to doświadczenie i że pracowałeś z programistami, dlatego znasz się na programowaniu najlepiej (po przecinku to już moja prywatna opinia na temat tego co napisałeś). Gdy podałem Ci prawie że napisane wręcz rozwiązanie nagle wyskoczyłeś z filozoficznymi problemami. EDIT: Jeśli mówisz poważnie, podaj mi proszę linki do swoich skryptów Czyli rozwiązania dynamiczne nie potrzebują żadnych rozwiązań po stronie serwera Haha, czyli dane bierzesz z powietrza czy skąd?

Nie chce mi się rozpisywać więc krótko odniosę się do poszczególnych akapitów, trochę od końca może, ale nie ma chyba to większego znaczenia. Akapit 5) Chodzi o niepotrzebny transfer niepotrzebnych nagłówków HTTP Akapit 4) Jeśli zamierzasz tworzyć osobnego php do obsługi jednego zapytania ajaxa z pominięciem core wp musisz połączyć się z bazą danych i sam pobrać dane dotyczące kategorii/subkategorii. Omijasz w ten sposób ORM wordpressa, tym samym rezygnujesz z wbudowanych zabezpieczeń (np. przed sql injecton) Akapit 3) Napisałem kilka postów wyżej, że ajax będzie miał zastosowanie w specyficznych przypadkach Akapit 2) Jak wyżej, pisałem że jeśli jest to część strony rzadko używana przez użytkowników w tedy możemy mówić o optymalizacji i zmniejszeniu transferu w przypadku użycia ajaxa. Nie rozumiem skąd pomysł na generowanie kilkutysięcznego kodu JSa. Nie wiem też czemu chcesz odczytywać jakiś duży plik i porównujesz to z odczytem z bazy danych? Nie wiem co w tym momencie powiedzieć, jeśli danych nie da się zgromadzić mniejszą ilością danych to w takim wypadku nie ma innej drogi optymalizacyjnej niż cachowanie odczytanych danych - takie coś ma sens gdy dane nie są aktualizowane "co 5 minut", w tedy raz na jakiś czas jak cache jest out of date robisz powiedzmy 5 zapytań do bazy, a w większości przypadków tylko 1 - odczytanie z cache. Akapit 1) Jeśli w moich postach nie doczytałeś się odpowiedzi na Twoje pytanie to chyba mamy różne podejścia co do tworzenia stron internetowych. Nie mogę się oprzeć by nie zacytować fajnego fragmentu Twojej wypowiedzi: Dla Twojej informacji wszystko co kończy się na developer to programista, a to czy zaczyna się na web, android, ios, embeded czy windows to tylko określa specjalizację w danej dziedzinie, platformie lub systemie. Łatwo więc zauważyć, że sam sobie przeczysz. Z jednej strony nie jesteś programistą bo jesteś typowym programistą - parafrazując Twoje słowa. Żeby nie było że tylko gadam, proszę bardzo bardziej techniczne wytłumaczenie (bez cache bo to inny temat) jak zrobić o co pytał autor: Pobieramy dane, do tego używamy: https://developer.wordpress.org/reference/functions/get_terms/ w pierwszej kolejności kategorie główne, później dla każdej kategorii pobieramy jej subkategorie, tą samą funkcją. Pobrane dane przechowujemy najlepiej chyba będzie w tablicy asocjacyjnej. Przekazujemy informacje o subkategoriach i przywiązaniach do kategorii do skryptu JSowego - inaczej mówiąc tablice z punktu 1 przekazujemy jako zmienną do skryptu, robimy to przy użyciu: https://codex.wordpress.org/Function_Reference/wp_localize_script Wyświetlamy w select z kategoriami Do pełni szczęścia potrzebujemy napisać skrypt JS który: Dla wybranej kategorii w select pierwszym ustawi wartości dla selecta drugiego na podstawie wcześniej przekazanej zmiennej z danymi Zostało tylko załączyć skrypt JS do strony i ewentualnie style CSS. Całość to około 50 linijek samego kodu. Bez niepotrzebnego rejestrowania obsługi nowego żądania ajax.

Tak robiłem, napisałem nie jedną wtyczkę do WordPressa. Jestem pewny że to zadziała. Co do Nie jest prawdą. Nie jest też w pełni kłamstwem. Stosowanie AJAXa zmniejsza zużycie transferu, zmniejsza zużycie procesora i pamięci dla niektórych żądań w specyficznych przypadkach. Używanie ajaxa do pobierania danych które równie dobrze możesz zwrócić z resztą strony, gdzie przechodząc do kolejnych podstron robisz to samo tracisz zasób jakim jest czas i zwiększasz zużycie transferu ponieważ za każdym razem musisz pobrać de dane ekstra ajaxem. Wygląda to mniej więcej tak: Użytkownik wchodzi na stronę: mojawww.pl/stronaA - lista żądań HTTP i nawiązania połączenia z serwerem: pobierze stronę stronA po document.read wykonujesz skrypt ajax który pobiera asynchronicznie dane - w tym miejscu ma żądanie typu ajax/jakisklucz Użytkownik przechodzi w ramach tej samej sesji na: mojawww.pl/stronaB - lista żądań HTTP i nawiązania połączenia z serwerem: pobierze stronę stronB po document.read wykonujesz skrypt ajax który pobiera asynchronicznie dane - w tym miejscu ma żądanie typu ajax/jakisklucz Nawiązanie każdego połączenia z serwerem to są kolejne ms w wyświetleniu treści na stronie, nawiązanie połączenia z serwerem to jest dodatkowy zbędny transfer. A można to zrobić tak: Użytkownik wchodzi na stronę: mojawww.pl/stronaA - lista żądań HTTP i nawiązania połączenia z serwerem: pobierze stronę stronA - w raz z danymi które wcześniej pobierałeś ajaxem Użytkownik przechodzi w ramach tej samej sesji na: mojawww.pl/stronaB - lista żądań HTTP i nawiązania połączenia z serwerem: pobierze stronę stronB - w raz z danymi które wcześniej pobierałeś ajaxem W przypadku ajaxa będzie to mniej wydajne niż w moim z tego powodu że dla żądania ajaxa, aby wordpress je obsłużył musisz załadować core, a tym samym wykonać zapytania sql o ustawienia i podstawowe dane wordpressa. W moim przypadku masz 1 żądanie czyli wykonujesz te operacje 1 raz. Jeśli rozpatrywalibyśmy tylko kwestię wydajności samego wyświetlania listy, pomijając całą resztę to bez dodania cache dla listy kategorii i subkategorii oba rozwiązania będą tak samo słabe wydajnościowo z tego powodu że musisz wykonać N zapytań SQL by pobrać kompletną listę kategorii z subkategoriami - niestety tak to jest napisane w WordPressie. Aby zmniejszyć liczbę zapytań SQL czyli przyśpieszyć czas wykonywania się skryptu stosujesz cache wrodpressa. Listę kategorii i subkategorii pobierasz jeden raz, wrzucasz do cache i pobierasz je z cache (1 zapytanie sql zamiast kilku). Dane w cache dezaktualizujesz w momencie gdy dochodzi do aktualizacji lub jakiejś zmiany w liście kategorii i subkategorii - od tego masz odpowiednie eventy, w tedy usuwasz to co miałeś w cache i generujesz raz jeszcze dane i zapisujesz ponownie w cach - ewentualnie nadpisujesz stare, wszystko zależy od implementacji. Zazwyczaj robi się tak że sprawdzasz czy dane są w cache, jeśli ich nie ma generujesz je zapisujesz do cache i sobie dale robisz z nimi co chcesz (np wyświetlasz). Jeśli dane są w cache pobierasz je i robisz z nimi co tam robiłeś w pierwszym przypadku. AJAX jest fajny, zmniejsza transfer i zużycie zasobów, ale trzeba wiedzieć kiedy to robi. Stosowanie go wszędzie bo jest fajny jest tylko przykład na to że nie do końca rozumie się dane zagadnienie oraz, że robi się to nie do końca świadomie i często dlatego że można i się da. PS. W dalszym ciągu uważam, że nie czytasz moich postów ze zrozumieniem lub nie czytasz ich w całości.

Odpowiedź zawiera się w tych linijkach: W części zdania: sugeruje że listę tworzymy dynamicznie w php, ponieważ skoro widget to php, skoro funkcje wordpressa pobierają dane czyli w naszym przypadku listę kategorii i subkategorii to jest to już robione dynamicznie. Nie musimy obsługiwać żądania ajaxowego, czyli pisać dodatkowego kodu. Dalej piszę: Czyli zwyczajnie rozwijamy i zwijamy zagnieżdżone listy za pomocą JS przy pomocy obsługi onClick na przycisku do zwijania/rozwijania listy subkategorii. Na koniec kosmetyka: Czyli zapewnienie poprawnego chowania/pokazywania się subkategorii plus, co nie jest obowiązkowe bo można to odziedziczyć po ustawionym stylu tylko trzeba znów wiedzieć jak sam design całej listy - kolory, fonty, rozmiar, ewentualne dodatkowe zdobienia - ramki podkreślenia efekty hover i co tam jeszcze styl nie ma. AJAX to nie jest duży arsenał, tylko niepotrzebne komplikowanie struktury takiego pluginu/widgetu oraz nawiązywanie dodatkowych - niepotrzebnych żądań do serwera które kosztują czas. Lepiej w większości przypadków od razu zwrócić całą przygotowaną (dynamicznie w php) listę kategorii i subkategorii w kodzie strony niż dociągać je przy pomocy AJAXa. Nie są to tak ogromne ilości danych by zaoszczędziło to transfer, ale będą do frustrujące milisekundy/sekundy dla użytkownika który będzie rozwijał taką listę ponieważ może on musieć chwilę zaczekać na nawiązanie połączenia z serwerem i zwrócenie danych. Ponieważ dopiero po tym zostanie mu wyświetlona lista subkategorii. Nad wprowadzeniem ajaxa można by się zastanawiać gdybyśmy mieli listę zbliżającą się do 100 i więcej kategorii i subkategorii łącznie. Jeśli będzie to powiedzmy lista głównych kategorii w okolicach 10/15 plus na każdą przypadnie do 5-8 (zwracam uwagę na słowo do, co znaczy że mogą być kategorie gdzie nie ma subkategorii) co da nam łącznie około 30-50 pozycji, to ja bym ajaxa odpuścił. Chyba że z takiej listy mało kto korzysta i praktycznie nikt jej nie rozwija w tedy też można ajaxa użyć jak mamy długą listę subkategorii. Na pewno nie używałbym ajaxa w momencie gdy taka lista/widget byłby czymś w rodzaju głównego menu nawigacyjnego które wymusza taki sposób nawigacji po stronie. W takim przypadku użycie ajaxa to zamęczenie użytkownika. Wyobraź sobie że wyświetlając kolejne pozycje menu musisz czekać za każdym razem ~1 sekundę na załadowanie się informacji. Dodatkowo dochodzi problem gdzie wordpress nie jest aplikacją SPA i jeśli przejdziesz na kolejną podstronę tracisz wcześniej zaciągnięte dane i użytkownik znów rozwijając listę czeka na wczytanie danych.

Właśnie to jest argument za widgetem. Widget to plugin tak naprawdę, możesz dodać shortcode, funkcję do wyświetlania. Tym samym masz 3 sposoby umieszczania takiej listy na stronie: 1) jak normalny widget w dowolnym sidebarze 2) w treści strony/postu przy pomocy shortcode 3) za pomocą funkcji php w dowolnym miejscu w szablonie Lista aktualizuje się automatycznie wraz z dodawaniem/usuwaniem/edycją kategorii i subkategorii we wszystkich miejscach. Nie musisz aktualizować niczego w kilku miejscach tylko wszystko w jednym. EDIT: Mocno nadinterpretujesz to co piszę, wskaż mi w moim poście moment w którym porównuję C++ i AJAX? Czyli język programowania z techniką/metodą pobierania danych. Gdzie napisałem że proponuję zrobić to statycznie przy użyciu js i css? Wskaż mi w mojej wypowiedzi takowe miejsce. Ogólnie mam wrażenie jakbyś czytał 50% tego co piszę.

Nie powiedziałem, że jest to niemożliwe, napsikam tylko o negatywnych skutkach takiego rozwiązania względem widgetu. Wiem czym jest AJAX, a ja nie pisałem o ajaxie tylko o js. AJAX to technika wykorzystująca wiele technologi która ma na celu pobieranie treści strony bez jej blokowania, a to w tym konkretnym przypadku nie jest zupełnie potrzebne. Wręcz zastosowanie ajaxa do takiego menu będzie powodowało opóźnienia podczas wyświetlania subkategorii, skomplikuje proste rozwiązanie oraz wymaga większego backendu. Wystarczy stworzyć widget który wyświetla listę kategorii i subkategorii w odpowiedniej strukturze HTML, dane łatwo można pobrać za pomocą funkcji wordpressa, dodać obsługę w javascripcie rozwijania subkategorii przy użyciu przycisku i ostylować wygląd tej listy. Rozwiązanie proste, sprawne i niezawodne. Można je jeszcze zoptymalizować o użycie cache wordpressa i raz wygenerowaną listę zapisać w cachu, później wystarczy generować ją po ewentualnej aktualizacji jakiejś kategorii. AJAX to przerost formy nad treścią. Równie dobrze można by napisać w C++ moduł do phpa który będzie taką funkcjonalność zapewniał, tylko po co? W programowaniu nie chodzi o to by udowadniać że coś da się zrobić na N sposobów lub w inny sposób bo to jest oczywiste i wszyscy o tym wiedzą, chodzi o to by znaleźć najprostsze i najlepsze rozwiązanie w danej sytuacji bo programowanie miało ułatwić ludziom życie - zautomatyzować procesy i przyśpieszyć obliczenia i przetwarzanie danych, a nie udowadniać że da się coś zrobić w konkretny sposób.

AJAXa nie ma sensu do tego angażować, owszem można zakodować w sidebarze szablonu, tylko tracisz możliwość organizacji kolejności widgetów w sidebarze. Konkretnie to nie masz za dużego wpływu w którym będzie znajdowała się ta lista. Ustawienie takiej listy pomiędzy widgetami będzie praktycznie niemożliwe, a jedyna droga realizacji to stworzenie dwóch sidebarów które będą wyświetlane przed i za taką listą jako jeden sidebar, efekt będzie taki, że zagmatwa i utrudni to zarządzanie kolejnością widgetów bo trzeba będzie pamiętać, że sidebar na stronie jest widziany przez WordPressa jako dwa, tym samym zmiana kolejności widgetu będzie mogła wymagać zmiany sidebaru w którym ma być wyświetlany.

Da się, nie jestem teraz w 100% pewny, ale chyba da się to zrobić na zasadzie odpowiedniego dostosowania wyglądu w szablonie wbudowanego widgetu wordpressa do wyświetlania kategorii. Jeśli nie (musiałbym zerknąć w kod) to można to zrobić dodając własny widget. Do wykonania tego na pewno trzeba znać JavaScript i CSS, gdyby okazało się, że trzeba napisać widget to do tego dochodzi jeszcze znajomość PHP oraz API WordPressa. Najładniej i najbardziej elastycznie - bez modyfikacji szablonu czyli potrzeby tworzenia motywu potomnego w celu uniknięcia utraty zmian po aktualizacji szablony będzie z całą pewnością stworzenie specjalnego widgetu, który będzie miał zaimplementowaną funkcjonalność tylko w JS, a wygląd czyli style CSS będą zaczerpnięte z szablonu. Gdybyś był zainteresowany zleceniem tego napisz do mnie na priv, jestem w stanie Ci to zrobić.

Jak dla mnie za mało szczegółów by móc wstępnie wycenić projekty, ale zakładając, że funkcjonalność mniej więcej jak u konkurencji to z tym budżetem chyba przesadziłeś. Za tyle to może byś znalazł jakieś studenta bez doświadczenia, pytanie czy masz czas i ochotę go pilnować by nic nie popsuł przy okazji.

To napisz skrypt który będzie wykrywał potencjalne takie strony, poinformuje Cię o tym i w razie czego będziesz blokował.

Oczywiście można podjąć środki prawne bo jest to naruszenie praw autorskich. Można też polubownie załatwić to z usługodawcą jak piszesz, ale czy coś zrobią to jedna wielka niewiadoma, dodatkowo to nie jest rozwiązanie problemu bo bardzo łatwo złośliwiec może postawić taką samą stronę gdzie indziej, moim zdaniem to strata czasu pisanie do wszystkich firm w których będzie miał hosting. Lepiej zrobić narzędzie do blokowania tego typu działań. Pytanie czy skierowanie sprawy do prokuratury bo to chyba jedynie oni mogliby wyciągnąć dane właściciela domen będzie warta zachodu. Raz potrwa to długo, a dwa pytanie jak będzie ze skutecznością. Jeśli ktoś chce wchodzić na taką ścieżkę to chyba najlepiej będzie zebrać materiał dowodowy w sprawie tych domen, przekazać prokuraturze (lub w odwrotnej kolejności), a następnie i tak zablokowanie tych stron we własnym zakresie by zminimalizować poniesione szkody. Takie rozwiązanie hybrydowe. Wszystko jednak zależy od tego co to za strona i jakie są na niej treści.

No to moim zdaniem zrobiłeś to dobrze, ja bym zostawił na kilka dni takie przekierowanie dopiero później skasował i wysyłał im puste strony.

Ale tylko za pierwszym razem? Chyba że masz źle stronę skonfigurowaną i wszystkie linki zamiast na https www kierują na http bez www. To w tedy faktycznie może być problem. Musisz mieć w prescie ustawienie odpowiedzialne za adres strony i okreslenie czy jest to http czy https jeśli domyślnie nie wykrywa.

Tak, wystarczy przekierować bez www odrazu na www z https. Swoją drogą co Ci przeszkadza to jedno przekierowanie więcej?

W jaki sposób zrobiłeś przekierowanie do siebie? Może da rade zrobić 301 Permanently - im zwracasz zupełnie pustą stronę jedynie z kodem przekierowania do siebie pod odpowiedni adres.

Jak aktualizujesz stroną u siebie to automatycznie na tamtych stronach prawda? Jeśli tak to przez wysyłanie im specyficznej treści strony masz wpływ na to co indeksuje u nich google. Czyli jak zmienisz im content strony na zupełnie inną tematykę teoretycznie Twoja strona powinna wrócić na swoje miejsce.

Jeśli pobierają oni tylko statyczny html - czytaj nie wykonują skryptów javascript możesz trochę przebudować silnik tak by zawsze zwracał pustą stronę ze skryptem JS w którym to będzie zapisana ścieżka do pobrania danych dla tej konkretnej strony. Zwiększy to ruch na serwerze i trochę go dodatkowo obciąży, ale jeśli hakerzy nie wykonują JSa to nie będą pobierali zawartości strony.

Nie jestem specjalistą seo, nawet za specjalnie się tą działka nie interesowałem, ale chyba nadal istnieje page rank tylko bardziej złożony, skomplikowany. Problem raczej nie jest zależny od tego jaki staż ma strona. Google może wykopać starą stronę bo uzna nową jako stronę z aktualniejszymi informacjami. To nie jest też raczej jakiś atak na stronę, CMS czy serwer. Nie sądzę też by była to kwestia iframe bo z tego co mi wiadomo google iframe nawet z tej samej domeny indeksuje jako osobną stronę. Nie może to być też wykonane przez JS bo jest zabezpieczenie przed CSRF czy XSS, to jest raczej skrypt np w php który pobiera stronę ofiary podmienia adresy na swoje i zwraca do przeglądarki. Adres ofiary generuje na podstawie adresu żądania, a że kopiuje praktycznie 1:1 do się wszystko zgadza.

Nie zgłębiałem tematu, ale zgaduję że cały hack polega na tym, że kopiujemy 1:1 zawartość strony OFIARA.pl i wystawiamy ją pod nazwa HAKER.pl google indeksuje naszą stronę, podpina do niej więcej ref linków tym samym sposobem algorytm może uznać stronę ofiara.pl z mniejszą liczbą linków zwrotnych za podszywającą się pod haker.pl. Efekt jest taki że domena haker.pl zyskuje wyższy page rank niż ofiara.pl i jej wyniki wyszukiwania wyświetlane są jako pierwsze. Ponieważ strony są identyczne z wyjątkiem nazwy, wyniki wyszukiwania też są identyczne i różnią się tylko nazwą która jest modyfikowana w locie co wygląda jakby ktoś ukradł pozycję w google. W rzeczywistości strona ofiary jest jakby wypchnięta z wyników wyszukiwana na rzecz strony atakującego. Jeśli się nie mylę to dodatkowo taka strona ofiary gdy zostanie uznana za tą która kopiuje treści z innej strony (atakującego) może nie być w ogóle wyświetlana w wynikach wyszukiwania.

A może lepiej podłożyć im świnie? Jeśli boty mają stałe IP to może dla tych IP zwracaj jakieś treści zupełnie inne, nawet bym powiedział takie za które mogą dostać bana od google. Ale musisz być z tym ostrożny żebyś sam nie oberwał. Możesz im wysyłać 404. Jak kopiują bezmyślnie może sami się odindeksują.

Skonfiguruj SPF na początek.

Nie, nie ma znaczenia. Pewnie określ że użytkownik loguje się z localhosta. Co do instalacji to nie powinno to tak wyglądać, prawdopodobnie masz nie skonfigurowane rewrite na serwerze. PS. Jeśli wykonałeś polecenie gran z posta wyżej to zmieniłeś hasło więc może to jest powodem braku dostępu.