Přehled odpovědí
-
Příspěvky
-
Pokud jde o “kradení”, tak jsem měl na mysli zejména druhou variantu (tedy přebírání celých článků). Pokud jde ale jen o zobrazování názvů článků z RSS (třeba se stručným obsahem), tak to přebíraným webům spíše přinese vyšší návštěvnost a ohlasy tak bývají spíše pozitivní :-)
Smashing Magazine: Animace v Javascriptu na základě matematických vzorců.
Google Swiffy: Nástroj na převedení flashových .swf souborů do HTML5.
WordPress Answers: “Hrátky” s tvorbou vlastních menu – jak některé položky zobrazovat pouze přihlášeným uživatelům a umožnit podporu zkrácených zápisů (shortcode)?
WordPress Answers: Jakým způsobem kontrolovat, který obrázek z příspěvku bude odeslán na Facebook při použití tlačítka “To se mi líbí”?
Zdroják: Případová studie o provozování WordPressu v cloudu.
Otto on WordPress: Nové funkce pro snadnější implementaci nápovědy pro tvůrce pluginů ve WordPressu 3.3.
WPMU.org: Shrnutí 10 různých způsobů pro nastavení testovacího prostředí pro experimenty ve WordPressu, zajímavý je zejména DesktopServer.
Wptuts+: První část seriálu o práci s API (transients) pro dočasné ukládání některých informací (tedy vlastně určitý způsob cachování).
Wptuts+: Jak vytvořit plugin pro pohybující se přehled obrázků (slider) s využitím flexibilního (přizpůsobí se různým velikostem obrazovky) nástroje FlexSlider?
Otto on WordPress: GoDaddy patrně blokuje na svém hostingu z bezpečnostních důvodů i obsah webu, který obsahuje “nebezpečné” funkce v podobě textu.
Lukas: Není třeba se vracet k ručnímu zálohování. Plugin WP-DB-Backup umí posílat zálohy na email a jiné pluginy umí zase ukládat zálohy na jiné FTP či nějaké externí úložiště, např. využít službu Dropbox (zdarma).
Určitě je to možné, záleží jakým způsobem to chcete provádět? Nejjednodušší je asi použít RSS zdroje těchto webů a zobrazovat je pomocí widgetů na webu (použít lze základní widget s názvem RSS).
Pro složitější použití je vhodný např. plugin FeedWordPress, který články z webů přebírá a vytváří z nich automaticky příspěvky, které pak můžete zobrazovat libovolně na webu (uživatelé to občas používají pro “kradení obsahu”)…
mirekk: Zajímavé, také jsem si tento bod neuvědomil aneb proč je dobré číst podmínky :-)
Webhosting, bod 6:
V prostoru daného webu smí být uloženy pouze soubory, které jsou potřebné k provozu webu a prezentaci dat a směřuje na ně z webu odkaz. Webhosting neslouží jako zálohovací či odkládací prostor, ale pouze pro provoz WWW prezentací. Soubory, jejichž umístění v prostoru webu není dle názoru Provozovatele opodstatněné, je Provozovatel oprávněn smazat.
Každopádně jsem nečekal, že to budou i kontrolovat a prosazovat :-) Můžete ale pravidelně zálohovat jinam, existují např. i pluginy, které odesílají zálohu na externí uložitě (třeba Dropbox). Myslím, že jsem někde viděl zmínku, že bude Wedos spouštět službu právě pro webové uložiště, takže to je možná v podmínkách kvůli přípravě na tuto službu…
Zkoušel jsem to v minulosti u Gigaserveru (nějaký levnější tarif) a bez problémů to na základě emailové žádosti nastavili. Ale raději bych se jich pro jistotu ještě zeptal než tam začnete něco stěhovat :-) Každopádně je dobrý nápad shromáždit prověřené hostingy, kde je možné bez problémů provozovat subdomény na víceuživatelské verzi WordPressu.
Díky za info, pro ostatní dodávám odkaz na příslušné vlákno, uvidíme, co na to autoři pluginu…
Zajímavý editor, ale spíše bych zkusil využít nové funkce pro integraci TinyMCE pomocí funkce wp_editor(). Výhodou je, že nepotřebujete načítat žádný nový JavaScriptový editor a bude stačit samotné jádro WordPressu…
Ale i CKEditor For WordPress vypadá velmi dobře a jsem zvědav, jak to bude nakonec vypadat na webu. Myslím, že editor má některé položky nastavitelné (odstranitelné) přímo v administraci, např. právě nahrávání souborů. Každopádně podobně jako u TinyMCE je možné ikonky odebírat a přidávat své vlastní. Prohlédněte nejdříve přehled všech ikonek (dokumentace) a poté příklady implementace do WordPressu (je tam i ukázkový malý plugin). Stručně řečeno musíte vytvořit vlastní plugin (či funkci v souboru functions.php, kde budete definovat změny editoru. Pokud se nezadaří, tak to zkusíme nějak dořešit…
Řádek db_version (podle informací z tabulky wp_options s hodnotou 18226) by tam měl určitě zůstat. Je důležitý pro mnoho věcí i další aktualizace, takže bych ho tam co nejrychleji vrátil. Každopádně máte zajímavý problém a zatím přesně netuším, co ho mohlo způsobit…
1) Patrně jste používal WordPress 3.2.1 (db_version s hodnotou 18226). Byla tato hodnota stejná i v souboru wp-includes/version.php? Jinými slovy, neproběhly mezi exportem (a úpravou) databáze nějaké změny, např. aktualizace WordPressu?
2) Dále mě ještě napadají možnosti jako vyčištění cache (a cookies) prohlížeče (či vyzkoušet jiný prohlížeč/počítač). Problém by mohl být v tom, že vše odkazuje na stejné místo, ale změnil se pouze název složky.
3) Podle wp_options jste používal (používáte) cachovací plugin WP Super Cache, který by měl být před změnou určitě deaktivován a zcela vyčištěna dosavadní cache.
Tak pokud je problém i když není aktivní žádný plugin, tak bude problém patrně v provedených úpravách databáze. V čem konkrétně ale bohužel netuším, můžete nám poslat přihlašovací údaje (administrátor WordPressu a FTP) na email pavelevap@separatista.net, zkusíme se na to podívat. Pokud máte původní zálohu databáze, tak ji tam můžete zkusit vrátit a zjistit, zda chyba zmizí. Nějaké úpravy např. v souboru .htaccess neprobíhaly?
neteyescz: Díky! V tomto případě jde o klasický serverový skript a Cron. POužít to lze samozřejmě také, ale mnohem jednodušší je některý ze zmiňovaných pluginů a využití Cronu WordPressu.
Zkusil bych nejdříve deaktivovat všechny pluginy. Pokud to nejde z administrace, tak přejmenováním složky plugins na FTP a pokusit se následně opět dostat do administrace.
Jakým způsobem jste přejmenovával všechny výskyty staré URL adresy webu?
Je třeba rozlišovat, zda se jedná o klasický serverový Cron nebo jde o Cron WordPressu. Uvedený skript (nemáte odkaz?) se patrně týká serverového Cronu, takže je třeba tento skript nahrát na server a napojit ho na Cron, což není nic jednoduchého (a u standardního hostingu je to často i nemožné). WordPress má ale zabudovaný vlastní jednoduchý Cron, který se spouští v nadefinovaných časových intervalech (a kontrolovány jsou vždy při vstupu někoho na web). Tento Cron pak mohou využívat různé pluginy, např. právě pro zálohu databáze.
Jedním ze starších (ale prověřených) pluginů je např. WP-DB-Backup, kde si můžete také nastavit, aby se provedla záloha databáze každý den a někam se uložila (odeslala na email). Záloha ale neproběhne vždy ve stejný čas, ale v plánovaný čas + doba než někdo návštíví web. Takže pokud máte malou návštěvnost nebo vyjde spouštění Cronu uprostřed noci, tak se nelekejte, že může mít záloha klidně i několik hodin zpoždění…
Lukas: Ano, přesně tak. Pokud specifikujete IP adresy, ze kterých bude umožněn přístup, atk se tam nikdo z jiné IP adresy nedostane. Ujistěte se také, zda máte vlastní veřejnou IP adresu, někteří poskytovatelé internetového připojení ji nabízejí za příplatek a defaultně nastavují sdílenou IP adresu, která se mění s každým novým připojením…
Osobně si myslím, že je výše uvedený kód trochu zbytečný, ale na druhou stranu nikdy není bezpečnosti dost. Podrobnosti o tomto kódu naleznete např. zde. Stručně řečeno jde o další ochranu, kdy první řádky specifikují umístění souboru .htpasswd, kde můžete definovat hesla, která budou vyžadována pro přístup do příslušné složky. Pokud teto soubor ale nepoužíváte, tak se místo cesty k souboru nastavuje hodnota /dev/null. Podle mě ale, pokud nepoužíváte první dva řádky, tak nejsou potřeba ani další dva, takže teoreticky nejsou potřeba vůbec první čtyři řádky. Použití LIMIT GET znamená, že se omezení bude týkat pouze GET požadavků a nikoli už POST požadavků či přímého přístupu k samotným souborům.
Podobný dotaz jsem nalezl přímo u hostingu Wedos. Chyba 500 se vám tam zobrazuje patrně proto, že hosting nějaký příkaz nepodporuje (či přímo zakazuje) nebo je tam nějaká chyba (či jiný problém). Podívejte se do příslušné nápovědy, v souvisejících komentářích se podobný problém také řešil.
Používáte nějakou veřejně dostupnou šablonu, aby to šlo vyzkoušet? Máte tam definovanou velikost písma 24px a v souboru style.css mnoho různých definic pro
h2 a. Pozor při úpravách tam používáte i pseudotřídy u odkazů, takže je třeba upravit vše, tedy nejenh2 a, ale ih2 a:hover,h2 a:visited, atd. Zkuste dát také nové definici velikosti písma vyšší prioritu zpřesněním umístění struktury stránky, např. místo pouze h2 a můžete zkusit.product_grid_item .grid_product_info h2 a(a všechny pseudotřídy). Využít můžete také třídu prodtitle u h2, tedy např.h2.prodtitle a. Nic z toho jsem nezkoušel, ale zkuste si s tím pohrát, určitě by to mělo fungovat. I když ale zmenšíte písmo, tak samotné boxy pro výrobky bude nutné zmenšit jinak, patrně je v administraci pluginu Gold Cart nějaké nastavení?Nejjednodušším způsobem je přesměrování domény, kde nepotřebujete žádný hosting, ale pouze nastavíte potřebnou URL adresu. Podobnosti záleží zejména na poskytovateli, u kterého máte doménu registrovanou. Pokud se budu držet příkladu Wedosu, který uvedl kolega výše, tak si projděte příslušnou nápovědu, vše pak nastavíte přímo v administraci hostingu.
Potvrzuji, testováno ve WordPressu 3.2.1 i 3.3 a URL adresa je vždy automaticky generována bez problémů. Také odhaduji, že by za tím mohl být nějaký plugin, zejména pokud se toto chování objevilo až poslední dobou…
kubalap: Přesně tak, jak píše neteyescz. Pokud používáte nějakou strukturu trvalých odkazů, tak když píšete název příspěvku, tak se pod ním hned automaticky generuje URL adresa, která by neměla obsahovat žádné podivné znaky. Diakritiku do URL adresy ani vložit nemůžete, respektive můžete, ale bude ihned automaticky odstraněna…
Vypadá to, že je toto nastavení přepisováno používanou šablonou, konkrétně pak pomocí
.widget-area ul ul(v souboru style.css), kde jsou definovány čtvercové odrážky. Budete to tam muset upravit nebo trochu zvýšit prioritu pro jazyky, tzn. změnit.qtrans_language_chooserna.widget-area ul ul.qtrans_language_chooser(nezkoušel jsem, možná to bude třeba ještě trochu upravit, např..widget-area ul .qtrans_language_chooser ul). Pokud se zadaří, tak dejte prosím vědět, co nakonec pomohlo…Lukas: Jakou používáte šablonu?
Obecně by měla být funkce body_class() používána pokaždé u HTML značky body:
<body <?php body_class(); ?>>Výsledkem této funkce jsou totiž automaticky přidávané třídy pro snadné stylování pozadí v různých situacích.
Změna proběhla během vývoje WordPressu 3.3, kdy je nově styl vlastního pozadí přiřazován nikoli základní značce body, ale s upřesňující třídou body.custom-background, čímž získává toto nastavení prioritu (aby překrylo původně definované pozadí šablony či volbu jiného barevného schématu). Bohužel, pokud šablona nevyužívá funkci body_class(), tak nebude fungovat ani vlastní pozadí. Tento problém by se měl ale objevit jen u velmi malého počtu šablon…
Řekl bych, že to odkazované vlákno fóra je přesně to, co potřebujete. Jde pouze o změnu stylování, kterou provedete v souboru style.css (v adresáři aktuálně používané šablony).
Pomocí prvního kódu odstraníte odrážky u vlaječek:
.qtrans_language_chooser { list-style-type:none }Pomocí druhého kódu zarovnáte vlaječky na jeden řádek:
.qtrans_language_chooser li { float:left; margin-right:3px }A poslední kód přidává barevné orámování vlaječek (můžete experimentovat např. s barvou):
.qtrans_flag { border:1px solid #b6b6b6 }Netestováno, ale mělo by to fungovat…
P.S. Ten úplně první kód je vlastně pouze ukázka HTML, které je generováno widgetem a nikam se nevkládá, automaticky se zobrazuje na webu…
