Jump to content

pecosk

Members
  • Posts

    23
  • Joined

  • Last visited

Everything posted by pecosk

  1. Co sa robilo s eshopom od doby ked to fungovalo? Nemazal si skupiny? Defaultna skupina zakaznikov id_group=1 by na eshope mala byt ... Pozri v databaze v tabulke PREFIX_group (id_group, reduction, date_add, date_upd) by mal byt aspon zaznam id_group=1 /datum v tvare yyyy-mm-dd hh:ii:ss/ (1, 0, datum, datum) potom v tabulke PREFIX_group_lang (id_group, id_lang, name) pre id_group=1 (1, 1, 'Default') (1, 3, 'svk preklad default') ak slovencina je id_lang=3 a v tabulke PREFIX_category_group (id_category, id_group) zaznamy napr (1, 1) (2, 1) (3, 1) ... do ktorych kategorii 1/home/, 2, 3, ... ma opravnenie skupina 1 Pred pripadnymi upravami nezabudni na zalohu DB
  2. Skontroluj v BO pri kategorii, ktora zmizla, ako su nastavene opravnenia na skupiny zakaznikov (porovnaj s kategoriou, ktora sa zobrazuje)
  3. nedal si verziu PS ... napr v 1.5.4 su obmedzenia 1/ v tabulke PREFIX_attachment_lang je `name` varchar(32) 2/ v AdminProductController.php ... elseif (Tools::strlen(Tools::getValue('attachment_name_'.(int)($language['id_lang']))) > 32) $this->errors[] = sprintf(Tools::displayError('The name is too long (%d chars max).'), 32); ... 3/ v admin themes v attachments.tpl (potom aj v preklade) <p class="margin-form preference_description">{l s='Maximum 32 characters.'}</p> Dalej som neskumal, ale pri PS je mozne, ze aj po nacitani name z databazy bude dalsia kontrola, ci neni nazov moc dlhy
  4. Mozna chyba v email preferences v cykle foreach je preto, ze nie su prelozene nazvy zamestnancov. Skontroluj/preloz v BO > Zamestnanci > Kontakty slovenske nazvy (v anglictine Webmaster, Technical support, ...)
  5. Ten slide modul je posunuty hore, lebo tam chýba horizontalne menu. V stiahnutej teme black&white je medzi modulmi aj modul Top horizontal menu (adresár blocktopmenu). Tento adresar treba nahrať cez ftp medzi ostatne moduly, potom ho v back office nainštalovať a nastaviť mu poziciu v Top of Pages (hook top) tesne pred modulom Home Slideshow.
  6. sprav kopiu enlinks.xml > premenuj ju na sklinks.xml
  7. Je v adresari modulu homeslideshow subor sklinks.xml (kopia z ineho jazyka) ?
  8. Pozri v databaze tabulku PREFIX_orders (stlpec invoice_number), kde mas asi fakturu s cislom 7855 PS_INVOICE_START_NUMBER (zadavane v BO alebo priamo v MySQL) musi byt vyssie ako MAX(invoice_number) v tabulke objednavok. Odzalohuj si DB a skus tie cisla faktur pri objednavkach zmenit na take, ake boli v 1.2.5
  9. V module na preklad retazcov databazy od otakarw su na niektorych miestach v subore preklady.php volane funkcie preklad($id_eng, $id_cs, .....) - treba v nich prepisat $id_cs na $id_svk alebo staci v subore svk_translation.php /cca 60riadok pred include("preklady.php");/ povedat, ze id_cs je vlastne id_svk $id_svk = $id_svkA['id_lang']; // ziska sa id_lang premenna sk fraz $id_cs = &$id_svk; include("preklady.php"); // nacita preklady zo suboru preklady.php
  10. Skusil by som vymazat vsetko (okrem index.php) z adresarov /tools/smarty/cache a /tools/smarty/compile Ak su na locahoste testovacie stranky shopu v podadresari (ostry shop je v hlavnom adresari web priestoru domeny), tak treba upravit .htaccess Priklad jedneho riadku prepisovania obrazku v .htaccess (z PS verzie 1.4.2.5) ak je shop na www.example.com/ RewriteRule ^([0-9]+)\-([0-9]+)/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1-$2.jpg [L] a ak je shop na www.example.com/sub_dir/ RewriteRule ^([0-9]+)\-([0-9]+)/[_a-zA-Z0-9-]*\.jpg$ /sub_dir/img/p/$1-$2.jpg [L]
  11. v /admindir/ajaxfilemanager/inc/config.base.php je v komentari okolo riadku 95 navod na jednoduchy skript /document_root.php/ <?php echo dirname(__FILE__); ?> ktory umiestni na web tak, aby si ho spustil na adrese nazev.domena.cz/document_root.php potom zmen v config.base.php define('CONFIG_WEBSITE_DOCUMENT_ROOT', ''); na define('CONFIG_WEBSITE_DOCUMENT_ROOT', 'cesta, ktoru vypise skript'); neviem, ci je to dobre riesenie, ale za pokus to stoji, ked si zufaly
  12. Tak ti to posielam, asi to nie je najelegantnejsie riesenie, ale mne to tvoje rss na 1.5.3.1 ide: rss-problem-s.zip
  13. Aka je tvoja verzia PS a modul blockrss? Napr. moje testovacie PS 1.4.9 aj 1.5.3.1 maju blockrss.php ver.1.1, ale su to rovnake len cislom verzie - metodu na nacitavanie feedu beru z roznych Tools... Zipni a postni tu alebo do PM subory: modules/blockrss/blockrss.php classes/Tools.php override/classes/Tools.php (ak existuje)
  14. v BO (admin) > Preferences > Customers nastav: Druh procesu registracie = Iba vytvorenie uctu + Tel.cislo = Nie alebo Druh procesu registracie = Standartny + Tel. cislo = Ano alebo Nie
  15. Ja by som namiesto zmeny farby pozadia upravil modules/homefeatured/homefeatured.tpl v casti, kde je kod: {assign var='liHeight' value=342} ... <ul style="height:{$ulHeight}px;"> Vyska ul sa pocita ako vyska li * pocet riadkov ... teraz ma 3riadky produktov a ul ma vysku 1026px Ak hodnotu liHeight 342 prepises na 257 (vo firebugu vidím li vysoké 257px +padding-bottom:1px), tak by to malo byt OK.
  16. namiesto {products} aj {discounts} sa generuju <tr> riadky tabulky - napr pre 1 produkt: <tr style="background-color:#EBECEE"> <td style="padding: 0.6em 0.4em;width: 15%;"></td> <td style="padding: 0.6em 0.4em;width: 30%;"><strong>LED svítidlo 12W</strong></td> <td style="padding: 0.6em 0.4em; width: 20%;">519,00 Kč</td> <td style="padding: 0.6em 0.4em; width: 15%;">1</td> <td style="padding: 0.6em 0.4em; width: 20%;">519,00 Kč</td> </tr> a v kode potom vznika tabulkovy chaos <tr><td><tr>... Skus nahradit tuto cast kodu <tr> <td align="left"> <table style="width: 100%; font-family: Verdana,sans-serif; font-size: 11px; color: #374953;"> <!-- Title --> <tbody> <tr style="background-color: #b9babe; text-align: center;"> <th style="width: 15%; padding: 0.6em 0;">Kód</th> <th style="width: 30%; padding: 0.6em 0;">Produkt</th> <th style="width: 20%; padding: 0.6em 0;">Jedn. cena</th> <th style="width: 15%; padding: 0.6em 0;">Množství</th> <th style="width: 20%; padding: 0.6em 0;">Cena celkem</th> </tr> </tbody> </table> </td> </tr> <tr> <td> {products} {discounts} </td> </tr> tymto <tr> <td align="left"> <table style="width: 100%; font-family: Verdana,sans-serif; font-size: 11px; color: #374953;"> <!-- Title --> <thead> <tr style="background-color: #b9babe; text-align: center;"> <th style="width: 15%; padding: 0.6em 0;">Kód</th> <th style="width: 30%; padding: 0.6em 0;">Produkt</th> <th style="width: 20%; padding: 0.6em 0;">Jedn. cena</th> <th style="width: 15%; padding: 0.6em 0;">Množství</th> <th style="width: 20%; padding: 0.6em 0;">Cena celkem</th> </tr> </thead> <tbody> {products} {discounts} </tbody> </table> </td> </tr>
  17. Dump lang tabuliek z MySQL, otvoriť sql súbor v PSPade (skontrolovať nastavenie UTF-8), select textu na konverziu a z menu vybrať: Nástroje > Užívatelské konvertory > Named HTML entity to chars
  18. v Product::getProducts a Product::getProductsProperties pouzivas id_lang 4 a pri kategoriach intval(3) Skus: <?php $id_lang = 4; // integer - id predvoleneho jazyka $shopUrl = 'http://www.forseti-fashion.cz'; // název domény include(dirname(__FILE__).'/config/config.inc.php'); // správná cesta k souboru include(dirname(__FILE__).'/init.php'); // správná cesta k souboru error_reporting(0); $p=Product::getProducts($id_lang, 0, 0, 'id_product', 'desc', false); // čeština v DB pod číslem 4 $products=Product::getProductsProperties($id_lang, $p); // čeština v DB pod číslem 4 header("Content-Type: text/xml"); echo '<?xml version="1.0" encoding="utf-8"?> '; foreach ($products as $row) { if ($row['active']){ $kategorie=array(); $category = new Category(intval($row['id_category_default']), $id_lang); while ($category->id <> 1) { $kategorie[]=$category->hideCategoryPosition($category->name); $category = new Category(intval($category->id_parent), $id_lang); } ...
  19. Na testovacom obchode v aktivnej teme v subore header.tpl zmen <meta name="robots" content="{if isset($nobots)}no{/if}index,follow" /> na <meta name="robots" content="noindex,nofollow" />
  20. Zmena ID dopravcu (zneplatnenie stareho a vytvorenie dalsieho s novym ID) pri editacii je zamer, predpokladam aby nebolo mozne pri existujucich objednavkach zmenit zakaznikom zvoleneho dopravcu (niekto zvoli osobny odber, v tabulke objednavky ma zadane ID dopravcu a ty mu to zmenis na kuriera). Nie je to moc stastne riesenie, chcelo by to v BO nejaky checkbox, kde by sa dalo zvolit, ci editaciou vytvorit novy zaznam dopravcu alebo len UPDATE, hlavne ked sa jedná len o doplnenie popisu. Ja som upravy popisov dopravcov (aj vacsinu lang tabuliek) riesil priamym zapisom do tabuliek (prefix_carrier*) v databaze. Moj tip na na editaciu tabuliek okrem phpMyAdmin je Adminer. Pre PS staci stiahnut Adminer pre MySQL (je to jeden php skript), nahrat ho na server do "tajneho" adresara a spustit v prehliadaci. Vypyta si konfiguracne udaje /server,databaza,meno,heslo/ a ide sa na vec ... vid obr. Pri priemernej znalosti MySQL a struktury PS tabuliek je to vacsia zabava ako preklikavat zalozky v BO. Zalohovanie DB pred upravami je doporucovane
  21. v original prestashop teme/sablone zmenim farby pozadia v TinyMCE textarea v global.css okolo r. 226 /* global RTE fields */ div.rte, .mceContentBody { background: ... } V tvojej sablone by v global.css mal byt sekcia /*global RTE fields*/. Tam skus menit background pre .mceContentBody
  22. lomka na konci __PS_BASE_URI__ co urobi? define('__PS_BASE_URI__', '/dev/eshop/');
  23. Zdravím, pokúšam sa rozbehnúť PS 1.3.7 a stojím na zásadnom probléme a to je divný výpočet DPH a teda aj celkovej ceny na úhradu. Ak je jednotková daň niektorého produktu zaokrúhlená na stotiny, tak pri nákupe viac ks takéhoto produktu je výsledná daň počítaná ako násobok takejto zaokrúhlenej dane. Napr. pri tovare s cenou bez DPH 3,33€ je DPH 0,67€ (zaokruhlene z 0,666) a cena s DPH je teda 4€. Pri nákupe 5ks Presta vypočíta daň 5*0,67=3,35 a cenu s DPH 5*4=20€ To je myslím nesprávne ... podľa zákona o DPH sa daň počíta z daňového základu, teda daňový základ 5*3,33=16,65 potom daň 0,2*16,65=3,33 a výsledná cena s DPH 16,65+3,33=19,98€ Na priloženom obrázku je ukážka, ako rovnaký nákup počíta Presta a ako účt. program. Nie je dobré, ak kupujúci v shope by bol vyzvaný na uhradu prevodom 224€ a skutočná faktúra bude na 223,92€. Otázky pri znalých v účtovaní: Je výpočet Presty správny? Čo by na to povedala kontrola DÚ? Otázky pre programátorov: Má niekto upravený/vie niekto upraviť kód tak, aby v ajax košíku, v pokladni a košíku (order.php), v mailoch - hlavne v príkaze na úhradu a faktúre boli počítané DPH a celková cena tak, ako počíta účt. program?
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More