Pokročilé hledání ve fóru

Někdy žádat administrátory o nápravu znamená i zaplatit nebo čekat.

Uvést práva do pořádku lze vlastními silami právě kompletním smazáním a opětovným obnovením z balíčku zálohy + kickstart.
Pokud se totiž soubory a složky rozbalí až na webu pomocí kickstart, mají automaticky "ta správná" oprávnění, vlastníkem je web.

Pak je potřeba na to pamatovat a nikdy nepoužívat žádného FTP klienta pro úpravy a nahrávání, stejně tak nezapínat FTP vrstvu v Joomle.
Vše je třeba řešit přímo v administraci Joomly a pokud je potřeba se soubory nějak pracovat, tak používat Phoca Commander opět v administraci.

srovnat práva a vlastnictví souborů a složek

Vladimír napsal: Je zvláštní, že i když mám stránky spadlé bylo v configuration.php nastaveno public $gzip = '1';. A navíc nejde upravený soubor následně uložit.

To by mohl být ten problém. Nejspíš máte různé vlastníky složek a souborů (CHOWN). Kde hostujete?

Editovat přes FTP configuration.php jde?

3. Nastavte vlastní barvu ikon souborů
Nyní je možné nastavit vlastní barvy pro různé typy souborů, které se mají zobrazit v mřížkovém režimu.

Toto je výchozí barva souboru.


Nastavíme vlastní barvy pro typ souboru .png.

Existují dvě barvy - pro celou složku a její okraj. Když nastavíte typ souboru, nepoužívejte tečku - místo .png by měla být png.


Užijte si výsledek

S takovým přístupem můžete zvýraznit typy souborů, které jsou pro vás důležité.

4. Import / export konfigurace

Pokud používáte Qunatum Manager na mnoha webech, možná budete muset zkopírovat konfiguraci a použít ji na jiných webech. Je to zejména aktuální parametry a hodnoty parametrů a oprávnění.

Když přejdete na možnosti komponent, jsou na panelu nástrojů další tlačítka pro import a export.

Konfigurace se uloží ve formátu JSON.

No, já se nechtěl dopátrat jestli máte správně oprávnění CHMOD, ale vlastnictví složek a souborů CHOWN, které je, tuším, na gigaserver rozdílné pro FTP a PHP.

Také byste měl mít tu Joomlu mít nainstalovanou v cílovém umístění a ne někde v cizí podsložce nebo subdoméně. Protože pak nemusí spousta věcí fungovat správně.

Co se se stránkami dělo? Migrace, úpravy,...?
Hosting?
Předtím aktualizace fungovaly?
Zkoušel jste stáhnout plný instalační balíček a nahrát jej: Aktualizace Joomla?

Všeobecně:

• Dejte si do pořádku vlastnictví složek a souborů
• Proveďte Údržba: Pročištění mezipaměti (stránky i administraci)
• Proveďte Údržba: Globální kontrola
• Opravte databázi Rozšíření: Databáze

Pak zkuste aktualizovat (i třeba výše zmiňovaným způsobem).

Když to nepomůže dejte si Joomlu do pořádku, viz. článek: www.joomlaportal.cz/jak-zacit/632-univer...ava-instalace-joomly

Děkuji že jste položil tento dotaz.

Jak se zdá, je vidět, že stejně jako většina programátorů co pro mě kdy pracovala (a přesvědčovala že jejich systém je nejlepší, nejrychleší a vůbec), jsou i ostatní z joomla prostředí v české republice zvyklí pracovat jen na localhost (maximálně verzovat změny pomocí interního systému jednotlivého pracovníka v netbeans nebo phpstorm na lokální počítač každého pracovníka samostatně) a následně změny kopírovat na ftp.

My jsme to dělali od roku 2011 (a nadále v tom pokračujeme) úplně jinak.

- Celý web (původně i DB, nyní bez DP a bez fotek) verzujeme pomocí gitlabu (ještě předtím než byl, tak pomocí interního systému git).
- Každé issues (úkol v systému redmine nebo easyredmine nebo jira) má vlastní branch a do ní programátoři a kodéři umísťují změny.
- Následně vedoucí programátor nebo ten kdo otestuje a schválí funkcionalitu úprav a má práva provede merge a nasadí úpravy do vývojové branch (devel) a nakopíruje na vývojovou verzi webu na ftp.
- Následně projektový manager projde úpravy a otestuje s klientem a nechá schválit
- Následně jsou úpravy zmergovány do produkční verze webu (master) a nasazeny na produkční verzi hostingu (ftp).
- Všechny změny v kódu jsou navíc označeny ID issues v systému redmine, aby se daly dohledat - popis, zadání, průběh, korektury a porovnat s původním kódem
- Seznam změn se pak archivuje pro případný upgrade

Tohle se opakuje neustále dokud není celý web dokončený

V případě exponovaných webů a eshopů ještě existuje mezistupeň - stage - který je přesná kopie produkčního webu a slouží k odladění funkcioanlity, kdy je nutné překlápět změny za chodu (jak jsem psal, jde o oexponované a VIP projekty).

Takže máme ve výsledku v gitu 3 hlavní branch:
- devel
- stage
- master

a tři vytvořené domény pro jeden projekt.

Tímto systémem je:
- neustálá kontrola nad celým procesem změn všech pracovníků
- nejsme závislí na jednotlivých pracovnících (při odchodu z firmy, výpadku, ukončení spolupráce)
- zákazník je součástí procesu a může průběžně kontrolovat nasazení změn a schvalovat - je součástí vývojového týmu a porad
- případné kolize se dají vyhledat, systém také slouží k zjištění kde nastala chyba při vývoji nebo nasazení a kdo ji z pracovníků udělal nebo zda došlo k chybnému zadání ze strany zákazníka (tohle již může dělat jen support manager na helpdesku při případném požadavku od zákazníka a není třeba používat programátora)

Tento systém jsem bohužel nevymyslel, jen jsem dotáhl během 3 let k dokonalosti a použití pro Joomla/wordpress a práci v týmu externistů, protože na stejném systému pracují kolegové například na eshopu pro Vodafone.

Pro použití tohoto systému je potřeba
- několik přesně daných software (pro PC nebo mac) a nastavení
- přesně dané postupy a bezpečnostní přístupy
- lidi, kteří znají systém práce s gitem (pull, push, fetch, merge a řešení konfliktů) a mají vše odladěno i na localhostu
- nadefinovaný systém gitlab (uživatelé, přístupy..)
- přizpůsobené přístupy na hosting

Podobný systém používáme při vývoji aplikací a rozšíření, tam se ale systém liší v použití branch (devel, master, hotfix, features, J25. J3).

Volbu jakým systémem ve firmě pracovat nechávám na každém samostatně.

Kolegové od Vodafonu používají Jiru a Mercurial, kolegové z Nette používají Redmine a Mercurial, my na Joomla používáme EasyRedmine/Redmine/Jiru a Gitlab.

No a nyní přímo k dotazu:

- neverzujeme DB - ta se ukládá 3 měsíce do backupu
- neverzujeme složky images, cache, logs a další podle typu webu
- neverzujeme dynamické soubory
- verzujeme vše ostatní

Rudolf

P.S.
Myslím že podobným systémem se pracuje při vývoji Joomla jako takové, jen používají Git.

Oprávnění na hostingu, PHP, databáze, verze Joomly i rozšíření? Vše tak jak má být?

Provozujete pořád Joomlu 3.9.2 (to je skoro rok nazpět), koukám, že to ostatní je také historie (Kunena, Phoca Gallery, češtiny,...). Začněte aktualizacemi a přechodem na vyšší verze (PHP, atd.), a hlavně opravit práva a vlastnictví složek a souborů. Myslím, že to pak bude fungovat bez problémů.

Jak opravit: www.joomlaportal.cz/jak-zacit/632-univer...ava-instalace-joomly

Ano, řešili jsme to, ale asi jsem nepochopil. Nějak jsem si to neuvědomil. Někde jsou fotky jako soubory, někde náhledy a ty se vytvoří při nahrání. Velikost souborů fotek tedy nemá vliv při zobrazování.

Jak jsem psal, já ty fotky zmenšuju při hromadným uploadu ještě před tím než se dostanou na server.

Já právě taky.

Vracet se k fotkám pro jiné použití? Ano, dobrá vlastnost, je to o koncepci, jestli chci dělat archiv, nebo jenom zobrazovat akce. Jako kdybych archivoval maily...ale je to dobrý tip, díky,pouvažuji o tom.
EXIF mohu zachovat, otáčení obrázků dělám při nahrání, ale jinak, myslím, nikoho z diváků EXIF moc nezajímá.

Ad místo na serveru. Ano, hostingy nabízí neomezený. Ale pokud zálohuji, stahuji je, upgraduji (záloha), je to znát.

Co nedělám, je to hromadné nahrání celé složky přes FTP. To zkusím, to by mohlo být rychlé. Díky za připomenutí. Ale BFU to neudělá. Co jsem nenašel (a už se to tu někde řešilo, budu hledat), je napojení na ty externí zdroje. Uvažoval jsem o Zonerama.

Obnovení ze zálohy, stejně jako vyčištění cache vám nepomůže.

Problém je ve špatně nainstalované Joomle, právech a vlastnictví složek a souborů nebo třeba i systémových prostředcích hostingu.

Samo od sebe se nic nepokazí, ale bohužel z tak málo informací těžko radit. Zkuste tedy být trochu sdílnější:

Co jste v poslední době se stránkami dělal (přesun, migrace, obnovení - jakým způsobem to děláte), kde hostujete, odkaz na stránky,... ???

Ahoj milá česká komunito,
Chtěl bych zde sdílet některé informace, které mohou být pro vás všechny užitečné.

Quantum Manager je správce souborů a médií, který dokáže pokrýt většinu potřeb a ušetřit spoustu času při práci s obsahem.


Klíčové vlastnosti:

• Hromadné nahrávání souborů
• Vytváření a mazání složek
• Oříznutí a změna velikosti obrázků
• Přejmenování souborů a složek
• Rozsahy pro seskupení souborů podle typu
• Integrace služby Unsplash - nyní si můžete stáhnout a vložit fotografie zdarma z populární fotobanky!
• Přidání vodoznaku
• Připojení souboru
• Automatická možnost změny délky názvu souboru
• Uložení původního obrázku
• Oprávnění skupiny uživatelů

Distribuční balíček se skládá z komponenty a některých pluginů.
Licence: GPL v.3

Stránka produktu v adresáři rozšíření Joomla

Snažíme se poskytnout bezplatný a užitečný nástroj, který vám ušetří čas při práci s obsahovými a mediálními soubory.

Kritika, přání a nápady jsou vítány

Díky za pozornost.
Eugene.

Ahoj, návody, vzorníky atd. - to by šlo řešit i odkazem. Tady jde o soubor, kterej je přístupnej jen po zakoupení produktu (prodej digitálního zboží - např. prodej softwaru, e-knih, atd.).

Nejde o to, že by se na serveru zipoval automaticky, jde o to, že když ho prodejce poskytne jako ZIP (např. dva PDF v sobě), tak někteří namítají, že s tím jejich zákazníci mají problém a že by raději v seznamu viděli dva PDF soubory místo jednoho ZIP (např. nějakej zákazník si zakoupí produkt, který se skládá ze dvou e-knih a on místo dvou e-knih ke stažení vidí ke stažení jeden ZIP).

Pokud jde čistě jen o produkt (a ne atributy), programátorsky by se to řešilo stejně jako u obrázků, kde je možné také přidat x obrázků k produktu.

Z hlediska výkonu to pak samozřejmě více zatěžuje, protože kromě pole download souboru přímo v tabulce produktu by existivala nová tabulku pro "additional download files". A to platí nejen pro případ uložení různých souborů u produktů, ale samozřejmě také u objednávky.

Co se týče atributů, tak tam už je to opravdu vyšší dívčí, protože se zanořujeme až do třetí úrovně: Produkt může mít X atributů, Atribut může mít Y vlastností a Vlastnost by pak mohla mít Z produktů ke stažení (a to ještě nemluvím o komplikacích s download tokenem a download folderem ve formátu tokenu, které se automaticky pro každý produkt nebo vlastnost atributu vytváří na serveru, atd.)

Vždy je potřeba na to dívat se z pohledu, že když X % prodejců bude chtít svým zákazníkům "ulehčit" život, zda má cenu to, aby těch zbylých Y % prodejců mělo nějakou i sebemenší zátěž (opravdu nepatrnou) v podobě složitější administrace a pomalejšího načítání na některých místech.

A otázka je, zda opravdu existuje možnost, že při prodeji digitálních produktů může být ZIP více souborů pro někoho opravdu problém?

Ernst napsal: To H13, to co popisuješ, je super, ale bohužel takhle daleko moje znalosti nesahají, mohl by jsi mi to blíže vysvětlit?

Místo toho, aby jsi dělal modifikace do každý komponenty, nebo do core Joomly!, je můžeš udělat jednou v tvým pluginu, kterej si prostě zapneš/vypneš/nainstaluješ/odinstaluješ podle potřeby.

Systémovej plugin v podstatě může přepsat cokoliv na stránce. Většinou obsahuje dva soubory: php a xml (php s kódem, který se vykonává, xml s definicí a informací o pluginu).

Pokud by jsi ho vytvářel, stačí vzít nějajej stávající plugin a prostě ho zkopírovat a modifikovat podle svých potřeb. Můžeš se např. podívat na systémovej plugin Phoca Upgrade - www.phoca.cz/phoca-upgrade-system-plugin - ten se snaží přepsat bootstrap 2 výstup na bootstrap 3. Podobně tak můžeš postupovat při přepisování title.

V Joomla! dokumentaci si najdeš metody systémovejch pluginů. Jednou z nich je např:

Prostě meníš kód ještě před vykreslením.

V tvým případě stačí jedna methoda, a to ta onBeforeRender()

A jakmile takovej plugin bude nainstalovanej a zapnutej, pak se jeho metoda onBeforeRender provádí při každým zobrazování jakýkoliv stránky v Joomle!

Má to výhody i nevýhody:

- Na jednom místě můžeš ovlivňovat veškerý výstup pro všechny části systému (články, k2, galerie, atd.)
- Ale protože to není v každý komponentě, nemáš tam např. proměnný z každý komponenty. Např. systémovej plugin při zobrazení článku nemá údaje o článku. Ty má jen content plugin. Jenže content plugin pracuje vždy jen ve článcích, už by nejel v k2, galerii, atd.

Proto je otázka, co se má dát do title. Pokud by to byla konstanta, nebo nějaká proměnná stejné pro všechny části (kterou by jsi např. dostal z databáze), pak je system plugin Ok. Pokud by ale byl pro každou část jinej - např. z článku by bral to, z galerie něco jinýho, z K2 taky, pak to bude složitější.

Pokud si ale systémovej plugin už jednou vytvoříš, pak ho můžeš používat všude a můžeš do něj přidávat různý nový vlastnosti, včetně parametrů, atd.

Snažím se zjistit, jak lze upravit layout (doplnit kód), který tvoří vzhled výstupu článků kategorie v blogu.
nyní lze tvořit výstupy pro content pomocí kódu v souborech složky: layouts/joomla/content/

Obsah složky (core joomly):
icons/
info_block/
associations.php
blog_style_default_item_title.php
blog_style_default_links.php
categories_default.php
categories_default_items.php
category_default.php
full_image.php
icons.php
info_block.php
intro_image.php
language.php
options_default.php
readmore.php
tags.php
text_filters.php

U šablony Helix Ultimate je pak override(přepis) v: templates/helixultimate/html/layouts/joomla/content/

Chtěl bych v přepisu dostat nad obrázek (ať už ve výstupu pro blog kategorie tak i pro samotný článek) kód, který zobrazí výstup konkrétních vlastních polí:Zkoušel jsem daný kód vložit do souborů full_image.php a intro_image.php nad kód zobrazující obrázek, ale nic se mi nezobrazilo.
Nejsem programátor, ale pouze "analoger" Nevím, zda je potřeba daný kód pro správné načtení upravit nebo je potřeba ještě něco načíst nebo zda lze doplnit do struktury souborů další php soubor a do něj doplnit potřebný kód a pak jej ještě někde načíst, aby se "zapojil" do výstupu pro vykreslení layoutu položky blogu nebo v pak dále i v článku (pozn. čísla ID polí jsou ok).

Děkuji předem za debatu a od těch, kdo se vyznají ve struktuře souborů (co s emusí napojit atd.) za pomoc. Jinak takové podobné věci kolem custom_fields v praxi bychom mohli řešit na srazu. Má to potenciál.

Saman6 napsal: Po vlozeni 3 clankov som sa zrazu nemohol prihlasit. System vypisoval ze je spatne heslo. Potom spadla stranka a vypisalo offline hlasenie "Na stranke sa pracuje" A teraz nemozem vkladat ani obrazovu prilohu a ani PDF subory.

Pokud "Na stranke sa pracuje" je hláška z Joomly, musel se v ní hrabat ještě někdo další ze Superadminů. Jinak vám tam něco dělal hosting. I hacknutí stránek může být ve hře.

Můžete zkusit v Globálním nastavení Povolit FTP (je třeba jej i nastavit). Jestli potom půjdou soubory nahrávat máte skutečně špatné vlastnictví složek a souborů.

Spoustu dotazů si můžeme ušetřit, když nám dáte odkaz na stránky, aby bylo možno se podívat.