Jump to content

cleoni

Members
  • Posts

    190
  • Joined

  • Last visited

1 Follower

Contact Methods

Profile Information

  • Location
    Bologna
  • Interests
    http://www.sitiweb-bologna.com/
  • Activity
    Web development agency

Recent Profile Visitors

5,583,344 profile views

cleoni's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • One Year In Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

23

Reputation

  1. Hello, bumping the topic, same problem here. I changed just numbers of 1 zone, until the end. Now (although I can see still values in the database via phpmyadmin), all the rows in the backoffice look like blanked out.
  2. Hello, I am using a custom theme, but I lately found out myself. The language selector for mobile is implemented in my theme as a form with a SELECT field, and the target url for each language is coded into the VALUE attribute of the select field. The code is somewhere in Presta core logic I guess, but once you put the correct url in the value, everything works.
  3. Hello, on an installation of PS 1.7.1 we have noticed that the module ps_languageselector on mobile view just redirects to the desired language homepage. I think that the correct vehaviour would be to send you to the equivalent page of the one you were visiting for the chosen language. I can't seem to find the code where the redirect logic is. Anybody has tackled with this problem already?
  4. Ciao, io alla fine ho risolto, il difetto che hai menzionato era nel mio caso dovuto a una forma di caching persistente e molesto di PHP per cui a ogni modifica in teoria si dovrebbe fermare e far ripartire un servizio legato al php (molto user friendly insomma, e la cosa bella è che è persino scritto nella documentazione). i due comandi per resettare la cache nel mio caso erano sudo systemctl restart php-fpm.service sudo systemctl restart httpd.service essendo veramente poco pratico per l'utente medio aprire una shell, dare comandi unix per riavviare servizi vari, cancellare cartelle, in una fase in cui dovevo fare molte modifiche e a ggrionamenti ho finito per disabilitare del tutto le funzioni di caching del php a prezzo di un calo di prestazioni, ma così almeno funziona senza stranezze. e la maggior parte delle dritte per ottimizzare le trovi qui: https://devdocs.prestashop.com/1.7/scale/optimizations/
  5. Hello, I have items with 500-550 combinations which already put the backoffice under stress. This means that if I save the item before 20 seconds (often 25 seconds) I get an error "Canot save settings" because the page is still loading combinations data via ajax calls in the background. I have tried installing the PS17 on a server with top optimizations and doubled server resources and have lowered the required save time to 10 seconds which is however very high for me. Anyway, from the frontoffice perspective, everything goes smoothly. On the powered server the site was running damn quick, so if who's working in the backoffice has patience, it could be a fair trade.
  6. @akme with this little number, the key question is if you need to calculate prices. If not, you are OK with the basic PS setup. Even if you need to calculate prices, you might be fine by calculating them on excel and then manual editing. Anyway I ended up buing WK Mass Combinations Assignment for Products, it has all what it takes for me.
  7. Hello, please do not get confused: the possibility to edit prices for hand-selected combinations is still there. And this is okay for shops with very limited numer of combinations for each product. The possibility to have the prices calculated automatically on the basis on attributes, each one having its impact on the final price, well this feature has been removed since PS 1.7. You have to buy a specific module for doing this. This turns out PS 1.7 to be inefficient for large apparel shops which have many product variants due to color, size, fabric, etc. each one having its own price impact. Not to speak about the performance problems due to the backoffice product page - if you have 200+ combinations for a product you have to wait many seconds before being able to successfully save a product and to have the save operation completed. So if you have to manage say 200+ combinations for each product - be prepared to buy a specific module and to face performance issues.
  8. Ciao, in breve avrei bisogno di un consigio sull'hosting ma ho visto cose brutte usando PS 1.7 dalla 1.7.6.* in avanti e da utente di vecchie versione di PS, alcune cose non mi tornano, ho bisogno di capire alcune cose su cui solo l'esperienza diretta può aiutare. Sto seguendo un PS 1.7 (aggiornato oggi alla 1.7.7.0) che ha sostituito una vecchia installazione di PS 1.6 la quale, a parte la lentezza, era solida. In questo PS 1.7 attualmente hostato su DigitalOcean con Ubuntu, ho riscontrato diverse cose che non vanno e che mi hanno fatto pensare di aver forse un server in cui PHP è forse configurato male: - In generale attivando le varie accelerazioni (non solo memcache e APC, anche semplicemente lo Zend opcache) il software fa stranezze, a volte è come se eseguisse codice compilato giorni prima e non si "accorge" del fatto che sono stati caricati gli aggiornamenti. Attivando file cache mi pare vada persino più lento. L'unico modo per vedere il software funzionare in modo normale è di disattivare tutte le accelerazioni mettendo addirittura il forza ricompilazione. Ci sarebbero tante combinazioni di ottimizzazioni da provare ma non voglio fare esperimenti su un sito attivo in produzione. - Pare non ci sia verso di attivare il banalissimo e standard logging degli errori php. Si può attivare la modalità DEBUG da backoffice la quale, rallentando con il profiler del backoffice, ha spesso mandato il backoffice stesso in errore. In generale, se c'è un errore capire perchè è un dilemma (nel vecchio PS si metteva il logging errrori php nel config.inc.php e via che si vedeva tutto, qua no) - Nel gestire prodotti con molte combinazioni in modifica, pare osservando il browser in modo debug, che vengano caricate informazioni tramite chiamate http in background, e la cosa dura svariati secondi. se si tenta di salvare il prodotto "troppo presto" si ottiene un messaggio in alto "Cannot update settings". Capita solo a me? Chiedo quindi se c'è qualcuno che ha un hosting dove un eshop PS 1.7 abbastanza "pesante" come prodotti funzioni bene, con le varie accelerazioni, e che non dia stranezze. Se esiste, e me lo può consigiare, mi sarebbe utile e lo userei anche io. Se invece ci sono altri che appena cercando di usare le accelerazioni si destreggiano tra error 500 e pagine bianche perlopiù poco spiegabili, magari uniremo le forze. Grazie per l'aiuto!
  9. Hello, sorry to reopen an old post. I have discovered that on PS 1.7 opcache interferes with the updates of prestashop modules. The effect is that the notification on how many modules need to be updated won't change after you have performed the update and refreshed the modules page. You see always the same "updates available" notification although you will notice that the module files have actually been updated on filesystem. I think opcache prevents the new updated files to recompile. Like it cannot detect the files have been changed. I tried to tweak the opcache settings without any good. The only way to solve the problem for me was to set up a php.ini that completely disables opcache before performing the updates, then restarting apache, then performing updates, then switching the old settings with opcache back in place. I don't know well this opcache, but I believe I had the default settings at the beginning, and they were very wrong. The system did even "confuse" things between two similar installations of prestashop on the same server, saving on the wrong DB. Horrible. So be aware - if you get strange "persistent caching" problems, make a copy of your php.ini then try turning opcache off.
  10. A quanto pare hai un error 500 nelle funzioni di backoffice, e non credo che c'entrino le combinazioni in senso stretto. Purtroppo per come è stato fatto il codice di questa versione di Prestashop, almeno per me, capire cosa non funziona è un vero dilemma. Di solito se un URL ritorna error 500 puoi ispezionare sempre nella console la parte "request" dove vedi - se sei fortunato - l'errore esatto che si è generato. Sempre che non sia un error 500 a "pagina bianca", perchè se è il tuo caso non vedi niente e occore prima attivare la modalità "Debug" di prestashop, poi riprovare. Per me errori di quel tipo sono sempre molto complessi da risolvere. La messaggistica di errore a me non dice nulla di comprensibile, confesso. L'ultima volta che mi è capitato era perché senza accorgermene nel trasferire il sito avevo per un errore tecnico traslasciato alcuni file e cartelle. Si è risolto ricaricando tutti i file di prestashop dal pacchetto di setup. Ma ho scoperto dov'era il problema totalmente per caso, mica per il messaggio di errore che si generava. Quindi per essere concreti, previo backup completo io tenterei di ricaricare tutti i file di prestashop - presi dallo ZIP della tua versione. Pulire la cache, riprovare. E se non funziona provare a fare upgrade. Ultima risorsa, provare a clonare l'eshop su un altro server (i VPS li puoi ottenere anche a ore per pochi spiccioli) e provare lì a vedere se la situazione migliora.
  11. Ciao, ti conviene aprire la console Javascript di Chrome (sul pc si fa Shift J, sul mac penso qualcosa di simile) e vedere se nella console vedi dei messaggi di errore. Talvolta per motivi tecnici può non venire caricato qualche script o si possono essere generati degli errori sulle chiamate che la pagina esegue per far apparire le combinazioni.
  12. Ciao @Fabry, si ho vito che rimpicciolendo la visualizzazione con Ctrl- sul browser si vede il campo per gli impatti sul prezzo. L'interfaccia attuale mi sembra vada bene in casi semplici o particolari, per esempio se hai un tot di articoli praticamente tutti con lo stesso prezzo salvo poche eccezioni, oppure quando gli aumenti del prezzo non sono determinati con precisione dagli attributi che hai messo. Se come capita nel campo dell'abbigliamento i prezzi sono dati dagli attributi (es. tipo di tessuto, taglia, colore, variante ecc) per calcolare gli aumenti ti tocca fare un foglio excel e pure conservartelo, perché a distanza di tempo non ricordi come hai calcolato gli aumenti. Prima, con il PS 1.6 si faceva facilmente, si poteva modificare facilmente, ed è un vero peccato che una funzionalità così utile si sia persa. Per ora il modulo WK Mass Combinations nel mio casi ci ha messo una pezza e sto chiedendo allo sviluppatore di fare alcune modifiche custom per recuperare dati del PS16 e la funzionalità del salvataggio automatico della configurazione attributi quando generi le varianti.
  13. @datshay thanks this is useful and at least solves the case in which more or less all products have the same price and you want to tweak the price increase of a few cmbinations. The problem still unsolved is that, if your price increases are calculated according to the variable attributes (see my example in my post above) you are completely alone, you have to buy a specific module for this. Prestashop 1.6 had this feature, it was working perfectly and it's a real problem they have dropped it.
  14. Ciao Pietro, sto lavorando in questi giorni su eshop migrato da PS16 a PS17 e per quanto ho scoperto finora confermo, chi ha progettato l'interfaccia combinazioni di PS17 ha creato un problema notevole. Il tutto è diventato pressoché inutilizzabile senza usare un modulo specifico che recuperi la funzionalità originaria, ovvero quella di poter ripartire dal set di attributi e incrementi sul prezzo da loro determinati. Provo a darti un aiuto indicandoti un modulo che è il "WK Mass Combinations" che ha una funzione chiamata "Combinations Generator" che ripropone più o meno la stessa funzionalità di prima ma che presenta due lacune importanti (in realtà solo una se non hai prodotti preesistenti): 1- Se vuoi salvare il set di attributi e incrementi prezzi te ne devi ricordare salvando con un apposito bottoncino, subito prima o dopo aver generato le combinazioni. Quando modifichi un prodotto dovrai poi caricare questi dati con un altro bottoncino. tutte cose che PS16 faceva in automatico. 2- I dati relativi a attributi e incrementi di prezzo usati per generare le combinazioni evidentemente il PS16 li salvava su DB. Se hai upgradato un eshop da PS16 a PS17 e hai centinaia di prodotti con combinazioni il poter recuperare questi dati permetterebbe di risparmiare una montagna di ore di lavoro. Ma purtroppo nessun modulo finora visto (e nemmeno questo che ti ho indicato) è in grado di leggere questa informazione dal DB. Il punto 2 per me rappresenta il problema maggiore. Sebbene io possa consultare il vecchio eshop che ho conservato per ricreare nel nuovo tutti i dati usati per creare le combinazioni, ci vorranno settimane di lavoro. Diciamo che se avessi saputo prima che c'era questo problema non avrei mai fatto l'upgrade, anche rischiando di aver difficoltà a mantenere il server in funzione. Per la funzione dell'etichetta a fianco del colore, io ho risolto facendo una modifica sul template ed è venuto piuttosto bene. Quello non saprei dire se l'avesse anche il PS16 originale.
  15. An Update. I specifically tested the modules: WK Mass Combinations Assignments for Products ( https://addons.prestashop.com/en/combinaisons-customization/26962-wk-mass-combinations-assignment-for-products.html ) and Bulk Combinations Generator ( https://addons.prestashop.com/en/combinaisons-customization/18240-bulk-combinations-generator.html ) to see IF: - If they succeed in replacing the functionality of creating combinations of a product with variations on a few attributes while assigning different price increments to attribute values, and - If they succeed in "getting back" price increments assigned to attributes in case we want to edit prices later (I mean, a shop owner cannot remember after weeks which price increments he had set to every single attribute of product, so this need to be stored somewhere) Here is my typical use case: I sell T-shirts, with 3 colours white black and blue with basic price 10 $. Blue costs 5 $ more Then I make them in cotton or silk. Silk costs 20 $ more because it is more expensive. Finally each shirt comes either short or long version. Long costs 5 $ more because it uses more fabric. Now I need to generate the prices for all these combinations of the 3 attributes (color,fabric,version: 3x2x2=12 combinations) and later I will need to edit price increases (say Silk has grown in price, or I have a new colour to be added) but I want to be able to edit the price increases as I originally set up. The results. Both these two modules in my tests did a good job in making easy the task of generating the combinations over these 3 attributes, and I could set the price increase for Blue, Silk and Long shirt version, and this is where the new PS17 interface did fail (or perhaps I don't know how to use it properly?). But - and here is the REAL problem! - both modules require me to Save/export the attributes+price increase setup before generating the combinations in case I want to change them later and start off where I left. WK Combinations uses a quick Save/Load function, while the other uses a sort of text file save for saving settings. Anyway ... >> I can forget of saving settings! Good old Presta 1.6 did save all this information for me, automatically, and I could re-enter the combinations screen, edit price increases, re-generate combinations, even add new attribute values (let's say we now produce a new colour: Red) >> my Presta 1.7 has been obtained migrating from a Prestashop 1.6 install. In my old Presta 1.6 I can still see combination attributes and their price increases if I try to edit combinations: so this information is still somewhere in the DB! Why somebody has decided to erase/loose this vital piece of information, why the newly developed modules don't recover and don't save this information automatically when I hit "generate"--- I cannot really understand. Hope the above is useful to somebody. I feel the new PS17 lacks a vital piece of software and so far I don't see a module which fully replaces the old functionality. It is very bery disappointing to discover that somebody has thought this functionality was something that could be left behind. Apparel shops do use this feature extensively, so cutting off a (working!) crucial functionality simply means loosing behind faithful customers.
×
×
  • Create New...