Příspěvky uživatele Jirka Daněk

Navedl bych tě i přesněji, ale nevím čeho konkrétně se snažíš docílit.
To řeší funkce _uniForm(), a skládá to funkce _formOutput(). Dá se to ovlivnit napsáním pluginu s využitím události sys.form případně jiných událostí.

_extend('reg','sys.form', function($args){

if($args['id'] === 'postform'){
// vlastni zpracovani
}

});
Pokud by se ti jednalo jen a pouze o ovlivnění těch formulářových prvků, tak by se dala použit událost sys.form.postform
Další počtení https://elegal.cz/upload/143-sber-e-mailu-podle-gdpr-infografika.pdf

Mazání by vypadalo asi takto, ale nezavíral bych ho do ifu. Schoval bych to za jinak danou podmínku (nejspíše DB::count()). To HCM je prostě nešťastně řešené a zastaralé. Použitelné sice je, ale chce to dost úprav.
DB::query("DELETE FROM `" . _mysql_prefix . "-massemail` WHERE email=" . DB::esc($_POST['email']))Pro aktuální verzi systému již nic neprogramuji, jen supportuji... takže tě nasměruji, ale přepisovat to nebudu.
Doporučuji přečíst: https://www.lupa.cz/clanky/gdpr-last-minute-co-musite-splnit-kdyz-sbirate-e-maily-pro-posilani-newsletteru/

Nechci sem kopírovat celý článek, ale pro budoucí čtenáře kdyby článek náhodou neexistoval sem dám odstavec.

Jedním účelem je naplnění smluvního vztahu či právní povinnost (informování zákazníka o potvrzení objednávky, fakturace apod.). Dalším samostatným účelem je pak použití e-mailových adres k rozesílání newsletterů, což pro samotné plnění smlouvy není nezbytné.

Jelikož se jedná o oddělený účel zpracování, které navíc nepodléhá oprávněnému zájmu či nevyplývá z právní povinnosti, je nutné pro něj získat od zákazníka souhlas.

Poznatek k HCM:
Zkusmo jsem si nahodil to HCM doma, mě vypisuje IP 127.0.0.1, ale ::1 je ekvivalent podle protokolu IPv6. Po odhlášení emailu z odběrů, zůstává i nadále v DB jen se stavem active=0. Myslím si, že by bylo lepší kdyby ten email byl odstraněn, protože uživatel nadále nesouhlasí se zasíláním emailů a tím pádem není důvod jeho email udržovat. To už asi porušuje GDPR, třeba mě někdo opraví nebo doplní...
Teď jsem si ušetřil trochu času a zrovna jsem to chtěl taky napsat. To co jsi vymyslel, byl trošku fujtajbl zavánějící problémem.

Rád bych upozornil, že i toto HCM není výhra... je letité, neudržované a nerespektuje současné požadavky GDPR. Jde tam hlavně o ten sběr emailových adres, bylo by potřeba určitě doplnit ukládání data, IP (?u neregistrovaných?) a času přihlášení k odběru. Protože bez uživatelem potvrzeného souhlasu nesmíš s jeho údaji nakládat. Řekl bych, že newsletter není oprávněný zájem jako například email pro vytvoření a aktivaci účtu. A ani na ten bez souhlasu nesmíš zasílat nic víc než emaily třeba na reset hesla, prostě nic co není spojeno se základní funkčností.
Na hostingu byla nastavena služba Supercache na 120minut, 😕 takže to podstrkovalo již vygenerované stránky namísto tahání čerstvých informací.

Nevím zda to je zapnuté defaultně, ale po přehrání všech systémových souborů a pokračujících problémech jsem nakonec prolezl každou stránku v nastavení hostingu. 🤬 🤬 🤬

https://ctrlv.cz/shots/2020/04/01/V8TP.png
img
Deaktivoval jsem member panel a trochu se to zlepšilo, podívám se zda není poškozený, ale ten chat v bočním panelu je peklo, brzdí načítání stránky, ale celkem zásadně.
Ukázka: https://ctrlv.cz/MROi
Zjednodušeně: FTP je přenosový protokol, pro přístup k souborové struktuře. Přehrál bych pokud by to bylo třeba jen systémové soubory, nikoliv design. Spíše ale chci prověřit ty pluginy. Údaje pro přístup k FTP většinou chodí do emailu, při založení hostingu.

100% nedoporučuji ty přihlašovací údaje psát sem do diskuse.

P.S. Mě se tu nevyká... 😁
Tohle není určitě standardní chování systému, buď tam je nějaký vadný plugin nebo bordel. Přehrát systém je tak na 15minut. Případně bych se mohl podívat, ale potřeboval bych přístup na FTP. (Email případně dodám.) Před pár dny jsem na Endoru instaloval SL a ten běžel správně. Nebo alespoň nemám informace, že ne...
Ten, který mě zajímal by musel být v rootu (tam co je index.php). Popravdě nevím co to způsobuje, nepomohlo by přehrát soubory na serveru?
Vypadalo by to asi takto.
<?php
/* --- kontrola jadra --- */
if (!defined('_core')) {
exit;
}

/* --- definice funkce modulu --- */
function _HCM_mysearch()
{
if (_search) {
return "<form action='index.php' method='get' class='mysearchform'>
<input type='hidden' name='m' value='search' />
<input type='hidden' name='root' value='1' />
<input type='hidden' name='art' value='1' />
<input type='hidden' name='post' value='1' />
" . _xsrfProtect() . "
<input type='search' name='q' class='q' placeholder='Type any keywords...'>
<button type='submit' title='" . $GLOBALS['_lang']['mod.search.submit'] . "'><i class='fa fa-search' aria-hidden='true'></i></button>

</form>
";
}
}
Nastyluj si HCM search a použij ho v šabloně namísto toho formu. Pokud ti nevyhovují CSS třídy nebo obalení tak si HCM duplikuj a přejmenuj třeba na mysearch a pak volej v šabloně.

Například:
<?= _parseHCM("[hcm]search[/hcm]"); ?>nebo
<?= _parseHCM("[hcm]mysearch[/hcm]"); ?>
Ten web se opravdu chová divně, po přihlášení i odhlášení zůstávají jakoby nacachované jednotlivé stránky a nedochází k redirektům. O member panel vůbec nejde, ten načítá data ze systému.

Máš tam nějaké pluginy?
Máš tam soubor .htaccess?
Trochu nás pozlobila reCaptcha, snad to již bude v pořádku.
Díky za feedback, upravím popisek pluginu a nechám ke stažení i tuto curl verzi. Pro osmičku to zkusím vymyslet jinak.
Strana: 1 ... « předchozí 15 16 17 18 19 20 21 22 23 další » ... 70