Přehled odpovědí
-
Příspěvky
-
Tak mě se eshop nezobrazuje správně ani v jednom prohlížeči(Chrome, Firefox, Opera, Edge …). Navíc co dělá ten cron v URL?
http://hubohealth.cz/?doing_wp_cron=1500817619.4521150588989257812500Attachments:
Dobrý den,
pokud se Vám nepodaří lokalizovat, kde vzniká problém můžete použít následující funkci, kterou vložíte do function.php v child šabloně.function nt_change_translate_text( $translated_text ) { $words = array( 'Cart Subtotal'=>'Mezisoučet', 'Order Total'=>'Celkem za objednávku', ); $translated_text = str_ireplace( array_keys($words), $words, $translated_text ); return $translated_text; } add_filter( 'gettext', 'nt_change_translate_text', 20 );PHP funkcí to vyřešit nejde, ale jde “natvrdo” přepsat názvy dní v souboru
\class\class_ct.php řádek 187 až 199 a řádek 247.Dobrý den,
kam ten kód píšete, případně kde ho upravujete?Protože u expand/colapse se mění jen
styleu<ul class="yith-wcan-list yith-wcan " style="display: block;">style="display: block;" nebo style="display: none;"Ten Váš script se nikde nenačítá.
Chybí tam
.widget h3
celkově tedy
$('#yith-woo-ajax-navigation-3 .widget h3').prepend('<div class="plus">+</div>');Další věci je, že tam máte nějaké divné apostrofy – používá se
' a "a ne‘ a ”.Pro Kategorie je správný selektor #yith-woo-ajax-navigation-3 nebo .widget-6
Pro Technika #yith-woo-ajax-navigation-4 nebo .widget-7Další věcí, kterou jsem tímto zjistil je že NIKDY nezakládejte více vlastností než je bezpodmínečně nutné.
S každou další vlastností tabulka postmeta roste geometrickou řadou a veškeré dotazy probíhají pomaleji. Takže pro jednoduchý produkt zvolte jen vlastnosti podle kterých chcete filtrovat, ostatní si vložte třeba ve formě tabulky do popisu produktu.Při hodně produktech a hodně vlastnostech může mít tabulka třeba 1M záznamů a velikost 300MB, po přesunutí do popisu se můžete dostat na desetinu.
Dobrý den,
určitě se to tak dá.
Při instalaci WooCommerce si vytvoří vlastní stránky “Obchod, pokladna, košík …) a stránku obchod potom přidáte do menu.Programovat nemusíte umět, ale musíte mít nějaké základy pro správné nastavení eshopu. Nicméně existuje rozsáhlá dokumentace a také spoustu pluginů rozšiřující funkčnost WooCommerce. Jeden z nich je i tady – České služby!
Detailní report dávám jak kvůli někomu, komu by to mohlo pomoct, tak i kvůli tomu, kdybych to někdy potřeboval :-)
Kusy se budou aktualizovat asi jednou za 10 minut (ne jak bylo původně 10x denně) Script běží necelou vteřinu, takže v tom problém nebude.
Po objednávce ve WC se odešle objednávka k dodavateli a tím pádem vygeneruje nové CSV se správným počtem kusů.
Takže jsem vlastně obešel WooCommerce a sklad řeší externí řešení.Nicméně ty filtry se mi líbí čím dál víc, když si s tím pohraji, tak vlastně můžu WC použít jen jako framework s bonusem tisíce různých pluginů, ale data si můžu zpracovávat úplně někde jinde s neporovnatelnou rychlostí.
WC je moc dobrý eshop kvůli jeho dokumentaci, rozšiřitelnosti apod., ale rychlost je tragická. Samozřejmě s každou novou verzí je lepší a rychlejší, nicméně na eshop s desetitisíci produkty a nějakou automatizací procesů je v základu nepoužitelný. Nese si totiž bohužel “dědictví” z WP v podobě návrhu tabulek. Vím že je to pro vývoj lehčí (používají se nativní f-ce WP), ale je to zase omezené funkčností WP.
Asi začnu podrobněji zkoumat API, protože kdyby se mi podařilo přes nějaké filtry přemluvit WC aby nativně používali jinou tabulku z DB s mou vlastní strukturou, byl by to velice mocný nástroj. Tomu ale moc nevěřím, ale bylo by to super.
PS: Kdyby České služby taky nemuseli data tahat z postmeta, ale bylo by to v nějaké indexované tabulce, feed by mohl být vygenerovaný při 30k+ produktech během pár vteřin.
Díky moc za pomoc a postrčení správným směrem!
Tak SUPER!
Ceny 25k+ produktů jsou importovány za cca 2s – to je nesrovnatelný rozdíl!
Postup:
Z FTP stáhnu a naparsuji CSV, to předám další části skriptu, který CSV naimportuje do MySQL do nové tabulky, kterou před každým importem vyprázdní.Zobrazení cen na webu pak řeší následující funkce (ve function.php v child theme)
add_filter('woocommerce_product_get_price', 'nt_product_custom_price', 10, 2); function nt_product_custom_price($price, $product) { $csv_price = $product->get_regular_price(); $wcsku = $product->get_sku(); global $wpdb; $querystr = "SELECT price FROM nt_ceny WHERE sku = $wcsku"; $ntprice = $wpdb->get_results($querystr, OBJECT); foreach ($ntprice as $newprice){ $csv_price = $newprice->price; } return $csv_price; }Zde se ještě změnil hook od WC > 3.1 z
woocommerce_get_pricenawoocommerce_product_get_price.Co se týče skladových zásob je to požadavek od klienta, který požaduje zobrazení ks. Také zákazníci se rozhodují podle toho, kolik ks je skladem potřebují totiž ve většině případů 4 ks, minimálně však 2 ks.
Skladem/není skladem nic neřeší, také je to custom_field. Jedině porovnávat rozdíly a z nich aktualizovat.
Neznáte nějaký hook na _stock ?
Zatím jsem jenom našel funkci$product->get_stock_quantityS dodavatelem bohužel není technická dohoda možná, dokonce jsem ho nepřesvědčil aby data dal na https místo na FTP, takže jsem musel do WP All Import psát spoustu funkcí, aby si stáhl soubor z FTP, obrázky z FTP atd., protože WPALLI neumí nativně pracovat se soubory z FTP. Jejich datová struktura je taky neuvěřitelná, nehledě na duplicitní identifikátory apod. Někdy mi to připadá, že to snad neleze ze systému, ale že to někdo datluje ručně.
Příspěvek se odeslal, ale nikde ho nevidím :-( tak znovu.
Tak filter
woocommerce_get_priceje magický. Změněná cena se projeví všude (product, order, email) a můžu si s ní dělat co chci, třeba tahat ceny z jiné DB.Takže založím novou tabulku, do ní budu importovat ceny z CSV a vše spouštět cronem.
Teď ještě podobně vyzrát na _stock.
CSV je od dodavatele v celkem nepoužitelné struktuře. Takže si ho pomocí skriptu nejdřív stáhnu z FTP, přeparsuji a uložím.
Váš nápad je ale vcelku geniální. Víceméně můžu nechat na disku poslední kopii CSV, stáhnout nový a porovnat rozdíly a ty pak uložit do CSV na import. To v případě cen.
V případě skladu je to ovšem trochu jiné. Jedná se o rychloobrátkové zboží, kde se synchronizuje sklad od dodavatele a ne sklad prodejce. Určitě tím ušetřím “hrubou sílu”, ale nevím na kolik. Taky si předem neumím představit návštěvnost a prodeje a měl bych rád nějakou “rezervu” ve výkonu.
Ta Vaše další možnost vypadá možná úplně nejlépe, ale moc si to neumím představit. Pravděpodobně by těch hooků muselo být moře, aby se cena projevila všude (product, order atd.) Nebo stačí jeden hook např.:
add_filter('woocommerce_get_price', 'return_custom_price', 10, 2);?
A do funkcereturn_custom_price()narvat SQL dotaz ?Zkouším WC 3.1 a ten nový CSV Import/Export. Pokud je to pro malý eshop do 1000 produktů, tak by to asi i mohlo fungovat. Bohužel pro větší eshopy je to nepoužitelné. Nelze nastavit co vše má aktualizovat a proto spouští u každého produktu dotazy na všechny taxonomie, všechny post_meta, projíždí tabulky wp_terms, wp_term_taxonomy, wp_term_relationships, wp_post_met atd., takže asi ani nepočkám jestli to dojde někdy pozítří dokonce.
Je sice pěkné, že vyjeli s CRUDEm, který WC posouvá zase kousek dál, ale kdyby radši místo toho opustili post_meta (podle mého na toto není vůbec vhodná ani navržená) a navrhli vlastní db strukturu udělali by daleko lépe a zrychlení by mohlo být více než znatelné.
Teď se ještě dívám na class WC_Data_Store (WC >3.0) respektive WC_Data, to vypadá dobře, nicméně zase jen na čtení (udržuje se v cache $cache_group), v zápisu to ale výkon asi nepřinese.Čili pro mě nezbývá nic jiného než zprovoznit ten script.
PS: ceny by mě ani moc netlačili, ty se mění třeba jednou denně, ale _stock by se měl synchronizovat cca 10x denně.
Ještě jsem zapomněl, že vše běží na vlastním VPS a zdroje si můžu upravovat (s výkonem problém určitě není), stejně pomalu to běží i na testovacím serveru WP All Import, kde mi kolikrát server vrátí hlášku IMPORT TERMINATED.
Právě se chci úplně vyhnout zpracování na straně WP, proto píšu vlastní script. Ten na export je neporovnatelně rychlejší, než kdybych to exportoval přes WP All Export. Vlastně vše zpracuje jen MySQL a PHP jen zapisuje do CSV.
Podobného výsledku bych chtěl dosáhnout i u importu (řádově sekundy). Problém je, že meta_value se nedá indexovat a dotaz vždy prohledá celou tabulku, kde je teď okolo 1M záznamů a má už kolem 280MB. Proto je dotaz pomalý.
Při zkoumání řešení mě napadlo vytvořit další tabulku, do které by se zapsalo jen post_id a _sku.
Zjednodušeně by byla logika dotazu:
První Query: SELECT z wp_postmeta post_id, _sku CREATE novou tabulku a do ní INSERT hodnoty.
Druhý Query: by byl kombinací zjištění post_id podle _sku
Třetí Query by byl již jen UPDATE podle post_id (WHERE post_id = $x) – protože je post_id indexované musí podle mě UPDATE již běžet mnohem rychleji.
Bohužel nějak nevládnu syntaxí MySQL, tak už dva dny studuji, něco mi běží, něco ne, něco je extrémně pomalé atd.
Myslí, že nastíněné řešení by bylo nejlepší, nicméně ho ještě neumím napsat.
Kdyby byl někdo se zkušenostmi, myslím že dotazy má napsané za pár minut.
Předem díky za odpovědi !
Ukončil, ale při ukládání zmizel. Přes editaci jsem ho ukončoval ještě 3x,ale vždy zmizel.
Problém vyřešen.
Způsobil ho plugin Transposh Translation Filter, který si vytvořil rubriky “Nezařazené@en” atd. Po vymazání rubrik vše funguje jak má.
