Přehled odpovědí
-
Příspěvky
-
Tedy možná netuším co má být výsledkem, ale dle mého je ten náhled v pořádku, viz přiložený obrázek. A je to linkované na originál obrázek o velikosti 755×1063. viz http://designedbynora.com/wp-content/uploads/2015/06/%C5%A0iju-s-chut%C3%AD-2016.jpg. A ten obrázek já vidím dle mého perfektní …tééda pokud nemám nějaké menší nároky :D, ale to asi ne… Ale napadlo mě, nemáte problém se zakešovanými obrázky v prohlížeči? Že by vám zobrazoval ty starší verze? Dost často se to stává.
Attachments:
Obecně. To že s tím nikdo nic nedělá neznamená, že to není porušení zákona. Je to prostě stejné jako s ostatními krádežemi. Do určité hodnoty ztráty se nikomu nevyplatí dělat složitou ochranu, dokonce ani platit ochranku a vše započítáte do ztrát. Jakmile ovšem ztráty překročí určitou procentuální mez tak samozřejmě dojde nejprve k ochraně a následně k restrikcím. A teď konkrétně.
@bosskloss: Opět ten autorský zákon říká, že pro osobní potřebu je možné využít zdroje jak z internetu, ale i jinde. Ale to, že z nich poskládáte nějaký nový produkt, což samozřejmě video na Youtube je, není osobní potřeba, protože tím, že dáváte to video jako veřejné, tak vlastně dochází k veřejné produkci a logicky k porušení zákona. Teď jde o to jestli má Google páky na to jak zjistit, že dané zdoje jsou a nebo nejsou vaše. A u hudby, jak si můžete všimnout, na to páku má, kdy umí zanalyzovat zda doprovodná hudba je či není free a pokud není, tak vám v lepším případě vypne u toho videa zvuk, v horším ho zcela zablokuje a dojde k varování, že pokud i v budoucnu porušíte pravidla, tak vám zablokuje účet. Takže jedině jak můžete ty fotky dle zákona využít, je tak, že si uděláte to video a to doma pouštíte třeba svým kámošům nebo rodině. Což je ale nuda, že? Takže samozřejmě lidé spoléhají na to, že to dneska ten Google neumí moc analyzovat a perou to na Youtube hlava nehlava a zákon nezákon.
@glados: To jak dnes WP udělá ochranu proti kopírování, je taková “ochrana neochrana” zaměřenou na BFU. Ale pokud něco víte kolem html tak vás toto nezastaví ani náhodou. Vlastně neexistuje web z kterého bych neuměl stáhnout fotky ať tam je nebo není zapnutá ochrana. Vždycky si můžete sáhnout do zdrojového kódu stránky, kde si najdete ten daný obrázek a je vyřešeno. Co se týká vodoznaku tak tam je to samozřejmě jasné, ale zase jde o to jak je tam ten vodoznak vložený. Pokud jej dáte decentně do rohu, tak je to opět jedno, protože ten image oříznete, pokud jej dáte přes celou fotku tak zničíte její uměleckou hodnotu. Co se týká toho, že bych někde musel mít na stránkách napsáno, že zakazuji kopírování, tak to je samozřejmě obrovský OMYL. Já nemusím mít nikde napsáno, že vám něco zakazuji, to vám automaticky zakazuje autorský zákon. Respektive, jak už jsem psal, můžete to dílo použít pouze a jenom pro svou osobní potřebu. A pouze, v případě, že chci dát to dílo free, tak musím uvést, že spadají pod Creative Common Free dílo a potom je možné je bezplatně stahovat a případně zveřejňovat. A jak dokáže, že to dílo je jeho, když ho vystavil na net? No jednoduše, má tu fotku jako zdroj. Každá fotka si přece nese své EXIF informace z foťáku o tom kdy byla pořízena, na čem byla pořízena atd. Samozřejmě se zde bavíme o případném soudním sporu, který by byl vedený. Ale přiznejme si, že když se vám ozve známý fotograf, že nezákonně uveřejňujete jeho fotku tak s ním asi nebudete moc diskutovat, zvláště když budete mít to “máslo na hlavě” a tu fotku rád z těch svých stránek stáhnete, aby se ten spor nevyostřoval.
To že by jste si ten WordPress nainstaloval na stejnou IP adresu by vám asi moc nepomohlo. Já bych to udělal raději tak, že bych si ten WP nainstaloval na jiný hosting s jinou IP adresou, samozřejmě je tu alternativa instalace na lokálním počítači, a potom si jenom nadefinujete v souboru hosts tu IP adresu s danou url adresou a takto si můžete ten web připravovat na těch správných url adresách a především ve finále můžete ten web spustit jen tak, že uděláte změny DNS a stále vám ten původní web někde existuje a je možné se na něj v případě potřeby jednoduše vrátit. Navíc by jste musel pro dokončení udělat změny url adres v databázi, což je pěkně otravné.
Takto jsem to dělal já když jsem přesunoval náš magazín http://www.profimoda.cz, který obsahoval cca 400 článků + 100 galerií se stovkami fotek a on běžel na OpenCMS a přesunoval jsem jej na WP. Takto si můžete i připravit případné podmíněné přesměrování (redirect 301), které asi ze začátku taky budete potřebovat, protože některé adresy prostě budete mít jinak než na stávajícím webu a máte je zaindexované. A teprve když to máte komplet připravené tak uděláte tu změnu DNS. A nebo pokud jste si ten web připravoval na lokále či provizorním hostingu smažete starý obsah a nakopírujete nový.
Dobrý den, obecně by to mělo jít u jakékoliv šablony. Už se o to tady diskutovalo, nejvíce je to rozebrané např. tady. Takže když si vytvoříte záložky ve stránce tak bez problémů můžete dělat na ně odkazy z menu.
Dobrý den, jsem zvědav jestli pro Vás někdo bude mít řešení, ale já když kdysi takto podobně uvažoval, tak jsem žádné řešení nenašel. A to i z toho důvodu, že si musíte uvědomit, že menu (tedy pokud se bavíme o menu v záhlaví) vlastně není spojeno se stránkou jako takovou, ale je právě v záhlaví (headeru) a tam žije vlastně nezávisle nad tím co se zobrazí níže. Jediné řešení je vytvořit si další menu (počet menu ve WordPressu je neomezený) a to vložit do sidebaru, nebo do dané konkrétní stránky. Takto to víceméně máte řešeno např. na http://www.alza.cz.
A taky to berte z pohledu uživatele, že pro něj by bylo vlastně to vámi navrhované řešení hrozně matoucí, kdy on, když se dostane na nějakou stránku, se v dané chvíli nedostane zpět. Takže proto vlastně vy by jste měl mít to “základní” menu jednotné pro celý web a jenom, pokud je potřeba si vypomáhat těmi doplňkovými menu.
Oops omlouvám se, samozřejmě jsem kecal, jenom ty desetinkové. Takže na tu velkou by se vám to updatovat nemělo.
Dobrý den,
automatická aktualizace WordPressu je od verze 3.7 normální záležitost v případě “desetinkových” aktualizací, tzn. že automatický update pokud jej nezakážete (viz níže) bude probíhat u verzí 4.6.1 na 4.6.2, případně jak to bylo teď z verze 4.6 na 4.7.
Co se týká zákazu a povolení tak se to nastavuje v souboru
wp-config.phpa to takto:
Zákaz:define('WP_AUTO_UPDATE_CORE', false);
Povolení:define('WP_AUTO_UPDATE_CORE', true);Dobrý den,
no na FTP jste je hledal zbytečně ony tam samozřejmě nejsou, ony jsou uložené v databázi. Na FTP najdete pouze content soubory, což znamená instalační soubory wordpressu, pluginů a samozřejmě obrázky, videa atd. Co se týká přesunu jsou 3 možnosti.
1. Použijete standardní import / export, který máte v Admin menu – Nástroje. Jenom zde si nevyberete konkrétní příspěvek podle jména, ale např. podle data.2. Můžete použít speciálnějších pluginy pro export a import, např tady je WordPress Exporter a zde WordPress Importer
3. Pokud těch příspěvků nejsou tisíce tak je zde třetí varianta, jak jsem to dělal i já. Buď přesunete vše a odmažete ty příspěvky, které nechcete a nebo si vždycky založíte na tom novém hostingu nový příspěvek pod stejným názvem jako jej máte na to starém, vejdete do editace příspěvku na starém hostingu, přepnete se do HTML, označíte celé to html a zkopírujete do clipboardu a takto jej přenesete do nového. Je to sice pracnější metoda, ale máte to zcela pod kontrolou.
Dobrý den,
No a podle toho co vám napsali s pipni.cz evidentně došlo k tomu, že ten váš web díky spatnému zabezpečení (asi slabé administrátorské heslo) někdo hacknul a jeho prostřednictvím došlo k rozesílání spamu z vaší emailové adresy latoya@aguiret.org, kterou máte také vedenu na pipni.cz. Což samozřejmě vedlo k nárůstu zátěže na SMTP serveru a logicky došlo k blokaci ze strany hostingu. Takže toto musíte vykomunikovat s podporou pipni.cz, dohodnout se případně na tom, že vám dají přístup k vašemu ftp, budete muset detailně projet všechny soubory, které jsou součástí wordpressu, zkontrolovat pluginy a samozřejmě doinstalovat pluginy, které vám web zabezpečí. O tom, že budete muset změnit všechny hesla je asi zbytečné psát. A pak jej opět spustit. Samozřejmě pokud máte k tomu webu zálohy.
@scrt: Já vás samozřejmě nechci podceňovat a především se vám snažíme pomoct, tak je zbytečné se rozčilovat. Vezměme to ještě od začátku. Jenom ještě pro upřesnění. Když jste měl, respektive asi ještě máte, ten WordPress na staré instalaci a podíváte se to do databáze tak tam máte u tabulek jenom jednu předponu ano? A to jakou ať v to máme trochu jasno.
A teď jak bych postupoval já v této chvíli.
1. Na novém hostingu bych smazal všechny tabulky v databázi.
2. Do té čisté databáze bych naimportoval tu zálohu databáze. Po tom importu musím mít v té databázi stejné tabulky jako to bylo na to starém hostingu. Jinak to ani nejde. A nebo vznikl problém např. při záloze a proto vám taky ten WP nenajede a chce instalaci. Už se mi to stalo.
3. Nakopíroval bych přes FTP zálohu webu
4. Kontrola a změna wp_config.php, kde je nutno změnit parametry u SQL na nové týkající se nového hostingu.
5. Stále se pohybujeme na nezměněné doméně, takže v dané chvíli ten wordpress MUSÍ najet, protože jsme v kopii 1:1 a i kdyby nechtěla najet homepage tak přes http://www.domena.cz/wp-admin by jste se měl dostat do administrace. Pokud ne, tak je někde nějaký dost zásadní problém.
6. Pokud bych se dostal do administrace tak nejjednodušší metoda na změnu domény je použít plugin Velvet Blues Update URLs . A nebo samozřejmě pomocí příkazů v SQLUPDATE wp_posts SET guid = REPLACE(guid, 'http://stararaurl.cz', 'http://novaurl.cz'); UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://stararaurl.cz', 'http://novaurl.cz'); UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://stararaurl.cz', 'http://novaurl.cz'); UPDATE wp_options SET option_value = REPLACE(option_value, 'http://stararaurl.cz', 'http://novaurl.cz');V žádném případě bych WordPress nenechal nic instalovat, protože to je cesta do pekel, protože pak by stejně muselo dojít v tom wp_config.php k tomu přepisu cesty prefixu a ty nové tabulky by tam byly naprosto nanic. A je naprosto jedno jaký mají prefix, jestli wp_, wpl_ nebo neco_.
Jenom drobnůstka. Doporučuji pro 100% validitu html kódu psát ten break takto:
<br />. Ony sice prohlížeče budou akceptovat i vámi uvedené<br>, ale jelikož se jedná právě o nepárový tag, tak jeho správná interpretace je právě s mezerou a lomítkem. Stejně jako se má správně psát<hr />, <input />@scrt: Zdravím, víte mám pocit, že problém bude tak trochu mezi židlí a serverem, protože žádnou z uvedených věcí jsem zatím nikdy nezaznamenal a to už jsem pár serverů, a ne zrovna malých, stěhoval.
1. Jak už napsal výše @kovanda tak předponu si volíte při instalaci WordPressu sám. Defaultně je to vámi uvedená
wp_, ale samozřejmě se mohlo stát, že při té bývalé instalaci někdo (vy?) tu předponu nadefinoval jinak. Paměť je velmi ošidná a krátká věc. Ale vás při přesunu vlastně ani nezajímá s jakou předponou jsou tabulky v sql uváděny – viz níže.
2. Protože, pokud by jste ten přesun dělal systémem 1:1, tzn. tak jak vy popisujete, tak si nějak nedokážu představit situaci, ke které jste došel. Vy přece naimportujete zálohu databáze do čisté SQL a v ten daný okamžik máte databázi shodnou se zdrojem. A upřímně vás, jak už jsem psal, vůbec nezajímá jestli má předponu wp_, AMBW_ nebo jakoukoliv jinou. Pak totiž zkopírujete přes FTP soubory webu a jediné co změníte tak je nastavení vewp-config.php, kde musíte změnit jméno, heslo a hostname k databázi, protože to je dáno provozovatelem webhostingu. A pokud toto uděláte tak máte kopii 1:1 (v tom je ten WordPress zlatíčko, přál bych vám dělat přesun v jiném redakčním systému jak jsem to měl kdysi já na Jave) a není důvod měnit URL adresy v databázi, protože ty stále zůstávají stejné! Vy, tedy pokud nám něco trošku nezatajujete, jste přece neměnil doménu, takže pak je ta url adresa stejná a je jedno na jakém webhostingu ten web běží.
3. Samozřejmě může následně nastat situace, že vám třeba ne zcela funguje zobrazení příspěvků, což může být případným specifickým nastavením.htaccesskvůli starému poskytovateli webhostingu, ale pokud to uděláte tak jak jsem psal a následně v administraci zkontrolujete nastavení trvalých odkazů, a zkontrolujete, případně smažete .htaccess, tak si skoro nedokážu představit situaci, že by vám ten web nejel. Tedy pokud jste neměnil doménu, nepřesunoval web z subdomény na doménu a podobně, což jsou složitější přesuny a zde už musíte počítat i se změnou url adres v databázi.Takže závěr bych viděl následovně. Jak se říká “zpět na stromy” a vezměte to ještě jednou podle toho popsaného postupu a musíte ten web bez problému rozběhnout. A WordPress je v tom opravdu nevinně, tomu věřte.
Tedy nejsem si jistý, že to bude příliš jednoduché. Předpokládám, že využíváte free variantu šablony. Zkuste se ozvat do support fóra, vypadá, že je vcelku živé a i vývojáři zde odpovídají. Případně zkuste napsat přímo vývojářům.
Dobrý den, když se podíváte do nastavení Nextgen Gallery, konkrétně Ostatní možnosti – Lightbox efekt, tak zde máte nastaveno co? Protože to je místo kde definujete styl zobrazení fotek. Druhá možnost je to, že se vám ten Lightbox bije z nějakým jiným javascriptem jiného pluginu. Zrovna dnes jsem měl stejný případ, kdy používám na sociální sdílení médií AddThis s kterým to funguje a chtěl jsem použít Monarch a zde se ty scripty pobily. Takže vypněte všechny ostatní pluginy kromě NG a mělo by to fungovat.
Zkuste se podívat na Caldera Forms plugin, který umí tvořit podmínky (Conditions) u jednotlivých polí. Plus má navíc přímo ukládání do databáze, takže si myslím, že by jste mohl takto vytvořit to chcete. Ještě k tomu pluginu jsem našel, že on umí editaci článku z frontendu, takže bude muset to co požadujete, protože pokud umí zápis do Single Line Text pole a Paragraph Text pole, tak bude umět pracovat i s jinými poli.
@paja: Jinak jednoznačné doporučení. Pro správné odladění používejte minimálně 2 prohlížeče a ať na své účely používáte Firefox, tak pro ladění webu zcela jistě používejte jako primární Chrome, protože jej používá o 80% více uživatelů než Firefox. A Firefox má dost špatnou interpretaci některých HTML příkazů, především ve stylech. Navíc počítejte s tím, že všichni vývojáři ladí své šablony primárně pro Chrome, patří k těm 80%, že? :D Já osobně používám, protože jsme na Apple, Chrome a Safari a pro klienty jdu dokonce do Windows a dívám se na to v Exploreru, protože tam to bývá všechno úplně jinak.:D
Nejsem si jist, protože když si dáte v google vyhledat
wpml problem domain without wwwtak se nejedná o ojedinělý problém. A pokud mě paměť neklame, tak jsem s něčím podobným kdysi bojoval a mám vážné obavy že ne příliš úspěšně. Zkuste do .htaccess vrazit toto:RewriteCond %{HTTP_HOST} ^platbos.sk [NC] RewriteRule ^(.*)$ http://www.platbos.sk/$1 [L,R=301]Ale pokud se nemýlím tak to jde udělat jenom na tu primární doménu a s tou druhou to bude stále trochu blbnout.
Nooo :D v Chrome mám Slovenštinu, ale v Safari mám Čestinu. Tak totiž je problém s doménou s www a bez www. V tom Chrome, alespoň v mé verzi a to mám tu poslední, mi když zadám platbos.sk udělá automatické přesměrování na http://www.platbos.sk. Ale v tom Safari ne. Když si ale zadáte
www.platbos.sktak to dělá vše korektně. Vám se to děje v jakém prohlížeči?Teď neřeším samotnou změnu ve WordPressu, o tom už tady bylo několikrát diskutováno jak to udělat a jak to chápu tak toto ani nebylo předmětem dotazu. Takže jakmile máte provedenu změnu ve WordPressu a stránky vám běží na doméně, tak uděláte následující.
Bavíme o tom, že opravdu pouze měníte url adresu ze subdomény na doménu 2. řádu a celá struktura a adresy “za lomítkem” zůstávají stejné, takže vy provedete podmíněné přesměrování v .htaccess souboru, což znammená, že tam přidáte tyto parametry
RewriteCond %{HTTP_HOST} ^en\.domain\.com [NC] RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]Takže nakonec v .htaccess souboru budete mít toto:
<IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteCond %{HTTP_HOST} ^en\.domain\.com$ [NC] RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule>kde to
en\.domain\.comje vaše subdoména ahttp://domain.com/ta doména. pak by všechny příchozí dotazy, tzn. to, že uživatel kliknul na dnes zaindexovaný článek v Google a dostal se k vám na změněný web přesměroval tak, že už bude ta url adresa na začátku s doménou. Tím vyřešíte problém s neexistujícími stránkami.Pak musíte donutit Google aby vaše stránky co nejrychleji přeindexoval a tím pádem také změnil url adresy zaindexoaných stránek. Tomu pomůžete, když si v Search console (dříve Webmaster Tools) od Google ten server zaregistrujete a pak v Kontrolním panelu – Procházení – Načíst jako Google dáte znovu načíst své stránky. Tím dáte impuls google robotu, aby šel na vaše stránky a znovu je celé proindexoval. Jakmile to udělá (během několika dnů) tak se začnou postupně měnit i ty URL adresy ve výpisu Google, tady to má samozřejmě svou určitou setrvačnost, ale myslím si, že tak do měsíce nejpozději by mohla být ta změna udělána. Všechno je to samozřejmě také o množství stránek o kterých se bavíme. Pomůžete tomu samozřejmě když dáte znovu v té Search konzoli načíst také Sitemap soubor. To přesměrování ale bude muset zůstat i nadále, protože změna proběhne pouze u souborů v Google výpisu, případně v jiných vyhledávačích. Ale tam kde jsou odkazy natvrdo (diskusní fóra apod. tak s tím nic neuděláte) a pokud by jste to přesměrování zrušil tak by vlastně došlo k tomu, že ten uživatel by došel na neexistující stránku.
Tak já nevím jak vypadá ten váš web a nevím jakou plánujete četnost publikování článků, ale pokud se bavím o klasickém magazínu, tak vám ty články stejně odtečou s titulní stránky a pak už jsou jenom součástí nějakých kategorií a tagu. A samozřejmě se stanou součástí archivu, což si dělá ten WP také víceméně sám. Mám pocit, že přecházíte z jiného typu redakčního systému, kde jste tyto věci řešili asi ručně, ale tady to asi ani nebudete muset řešit. Respektive nějak nevidím důvod je vůbec řešit.
