gonssal

I just installed version 1.7 in my local machine for a test drive, and after trying to log into the backoffice for the first time, I get what you can see in the attachment. 15 minutes loading the dashboard (and still going), apparently due to the "gamification" module, which for some reason is trying to get non-existent files from prestashop.com that seems to have a 2 minutes timeout. Is this normal? Has PrestaShop really gone in such a bad direction that it just doesn't even work after a clean install? I was starting to think on upgrading to 1.7, but after seeing this...

Can't you read? class AdminPreferencesController extends ModuleAdminController { /** * @see AdminController->init(); */ public function init() { parent::init(); // Just redirect to the module configuration page Tools::redirectAdmin($this->context->link->getAdminLink('AdminModules') . '&configure=' . Tools::safeOutput($this->module->name)); } }

http://doc.prestashop.com/display/PS16/Creating+a+first+module Ya te aviso que, en mi opinión, PrestaShop tiene posiblemente la peor documentación de todos los sistemas de tiendas on-line que he visto.

Pues por lo que entiendo sería cuestión de hacer un módulo que cuando hay un pedido use la API para crear el servicio. Si la API luego cambia el estado de los envíos o lo que sea, se actualiza el pedido de PrestaShop en consecuencia.

Hombre pues si explicas para qué se usa la api concretamente será más fácil ayudarte. En general, se tratará de hacer un módulo de prestashop que muestre información de la api en el front o el backend, o de sincronizar esa información con la base de datos de prestashop.

Casually landed in this topic, and have a couple of minutes to explain my solution. Create a new tab that links to one of your module's admin controllers (for example MyModulePreferencesController). In the Preferences admin controller's class, just define the init() class, call parent::init() and do a redirect: Tools::redirectAdmin($this->context->link->getAdminLink('AdminModules') . '&configure=' . Tools::safeOutput($this->module->name));

Pues si sólo lo necesitas para categorías, puedes estructurar el árbol como necesites que aparezca el desplegable. Si eso no es factible (por ejemplo porque quieres tener una estructura de categorías diferente a la del desplegable) o si también necesitas mostrar desplegables de la misma forma para atributos de producto, características de producto o fabricantes, necesitarás un módulo hecho a medida. Una forma de agrupar o categorizar todas estas cosas y que te genere los desplegables mostrando estas agrupaciones.

No, I can't elaborate anymore. Search for the string I said in core's code and look how it's done there, if you want to build on top of bad design decisions. Also, if I understand correctly you are modifying core files directly, which is a very bad idea, because if you want to update PrestaShop all your changes will be lost. There's an override system for that.

Hi. Sadly, PrestaShop uses a lot of redirections after doing some actions. This means that when you use certain action hooks, they will be run by a controller that doesn't display anything, and then redirects to another page. This also means that anything you try to display when that hook takes place will never show. It's specially annoying for module developers. This is a bad design decision that gets worse because there's not a session-based "flash messages" system in place. This is why in plenty of core's code you will see url parameters that are used to show messages through the back office (search for "&conf=" in the code to understand this). In your case, because you are using die(), the message will show but the redirection will never happen, so you get a blank page with the message. It is said that a proper messages system will be implemented in version 1.7, but currently you are out of luck. The only way to do it is by using url parameters on redirection pages or implement your own messages system.

No se si entiendo muy bien lo de "separar en secciones las listas", pero si te refieres a lo de "marcas más populares" que comentas en el primer post, no creo que puedas hacerlo con ese módulo, ya que requeriría tener un registro de las ventas y las categorías que más se venden, si es lo que quieres. Una opción sería hacerlo "manualmente", creando una categoría base "Más populares", y metiendo ahí las categorías que se quiera, y luego asignándolas a los productos que se desee. El inconveniente de esto es que tendrás más ramas en el árbol de categorías y que seguramente tendrás que tener categorías duplicadas. Si lo que quieres es que estas "secciones" se generen automáticamente, creo que tu única opción es un módulo a medida.

No parece que ninguna de las webs que has enlazado use PrestaShop. Creo que con Advanced Search 4 puedes conseguir lo que quieres.

Lo primero, mi consejo es que lo que estés haciendo, lo hagas en un módulo. El código es prácticamente el mismo, pero haces extend de ModuleAdminController y tendrás el modelo (Zone) en el mismo directorio que el controlador. Respecto a que no te encuentra la clase, PrestaShop usa un "cache" de clases que está en /cache/class_index.php. Borra ese fichero y vuelve a intentarlo.

Lo único seguro es que el error no tiene que ver con PrestaShop, sino con el servidor Apache y su configuración. Por lo que he podido encontrar, es un error muy poco habitual y sin solución única o fácil. La única manera es teniendo acceso al servidor y analizarlo bien. Mi consejo es que, si puedes, cambies de alojamiento y, si no puedes, le des los datos de acceso al servidor (o panel de control) a alguien que entienda y se lo mire. Si ninguna de las dos opciones es viable, te queda el ticket de soporte a la empresa donde tengas contratado el alojamiento.

You definately need custom code for this, preferrably a custom module. If I were you, I'd try to work with product combinations, and (programmatically, from the module) create a different product combination for every possible user selection, setting it's price accordingly. I'd create the variants only when a customer made a selection. What you wanted to do, "mocking" the product in the cart, is not possible in PrestaShop, because each cart line links to an actual product, unlike other ecommerce systems that abstract the product once in the cart.

No me suena haber visto nada para lo que necesitas. Tendrás que hacer un módulo a medida.

The carriercompare module is responsible for displaying the carriers list in the cart page. The wanted modifications need to be done in the module's code. More precisely in the carriercompare.js file, because the list is generated through javascript.

So if I understand correctly, what you are doing is dynamically price a product after some user customization and add it to the cart. Then you want to "mock" that product so, if someone else changes its price with different customizations, the one added to the cart by the first customer is not changed. Is this right?

Latest version and CCC disabled. It's a bug, because of this line in admin.js: $(item).val($(this).find('option[selected=selected]').val()); I don't even understand the point of the line, seems completely unnecessary to me, but it makes select[multiple=true] only load one $fields_value when using chosen.

That's unfortunate, there's a bug (one line) in admin.js that makes the chosen jQuery plugin only load one value for selects[multiple=true], making it a no-go when developing.

I'd like to know, if still possible/accepted, where to report bugs for version 1.5. I've looked in the official github repo, but I only see 1.6 branches plus master.

Hola. Si te fijas en la función hookDisplayHeader del módulo, se añade un javascript con addJS(). Lo único que tienes que hacer es crear el fichero CSS que quieras, idealmente en 'views/css' y en el hook copies-pegues la función addJS justo debajo cambiándola por addCSS con la ruta al fichero CSS que has creado.

This issue is related to the Layered navigation (blocklayered) module. If you are having this same issue please check this: http://forge.prestashop.com/browse/PNM-313 Fix for 1.5.x versions is included.

Thx for trying to give a solution but it didn't work for me. It still adds the product to the cart through AJAX but when you checkout, the cart is empty.

Hi. This is working for the rewrite rules I have set on my installation, version 1.5.3.1. For what I've seen on the code, this might not work for all your rewrites due to the regular expressions used being not the best I've seen. So if some rewrites fail, modify them. File to modify: /classes/Dispatcher.php Remove the foreach that follows the "Load custom routes" comment (line 428). Replace the foreach that follows the "Set default routes" comment (line 442) with this one: foreach (Language::getLanguages() as $lang) { foreach ($this->default_routes as $id => $route) { if ($this->use_routes and $custom_route = Configuration::get('PS_ROUTE_'.$id)) { $this->addRoute( $id, $custom_route, $route['controller'], $lang['id_lang'], $route['keywords'], isset($route['params']) ? $route['params'] : array() ); $this->default_routes[$id]['rule'] = $custom_route; } else { $this->addRoute( $id, $route['rule'], $route['controller'], $lang['id_lang'], $route['keywords'], isset($route['params']) ? $route['params'] : array() ); } } } Please note this is a fix i've put in place after looking at code for like 10 minutes. It shouldn't, but it could break things, so check that everything works on your installation. Also please note that the proper way of doing this is by using overrides, not modifying the original file.