yesdev

Just getting 400 Bad Request Request Header Or Cookie Too Large when trying to log into the Validator (Windows, 64-bit, Vivaldi)

I'm almost finished designing a new module for editing Prestashop & have hit a hurdle. The Helper form class expressly states: $this->context->controller->addJS(_PS_JS_DIR_.'tiny_mce/tiny_mce.js'); $this->context->controller->addJS(_PS_JS_DIR_.'admin/tinymce.inc.js'); Now I don't need TinyMCE to run anymore (got something better planned in it's place) but.. The override I've written refuses to remove these two items, even when using $this->context->controller->removeJS. Anyone have a solution? -- Solved it again myself. Created an override for the AdminController class that removed TinyMCE.

We ended up creating a few more variables to place inside the cart_product table that helped differentiate between product variants. Pretty bespoke code & refactoring as well.

I'm midway through developing a new administration module that uses 4 form buttons to pass variables to the final submit button. The submit button is hidden as I don't want people in the admin console to fire it directly. I just want them to press one of the 4 buttons I've designed. As I built this off the standardised module generator linked into the Prestashop validator, I'm wondering: why buttons aren't recognised when fired as part of the Prestashop admin console. I've got breakpoints / alerts set up through the sequence & they're not firing. As I've hidden but not disabled the submit button, does that break the overall Helperform structure? Anyone have any clue on designing a complex admin form like I'm working on? I figured it out - have the same form ID pass 4 different values

Just to let you know, logging into the Addons store with Paypal results in a white page of death. It authenticates correctly at the Paypal end. It just doesn't resolve gracefully on the way back URL it ends up resolving to is: http://addons.prestashop.com/authentication.php?paypal_login=1&paypal_close=1 Tested on: Vivaldi 1.0.344.37 (Beta 2) (32-bit) Revision 9ae925ff17ca36e328d999851001d0b9dae32e33 OS Windows Blink 537.36 (@0) JavaScript V8 4.7.80.25 Flash 20.0.0.306

As part of our ongoing build schedule, we designed new classes & controllers for new functionality across our Prestashop build to deliver what we need. I'm now going through harmonisation of our build to the latest 1.6.1.x structure & wondered if there was an way of placing: new classes new components inside the overrides folder instead of having them reside in /classes & /controllers area. The long term strategy is so we can just deploy a one click upgrade to Prestashop without it damaging all the new stuff we've designed & developed. Anyone have any ideas?

New work on our site has meant I've now developed a really, really simple soft registration sequence to help counteract cart abandonment. The good news so far is: We can correctly capture & set people up as potential customers with just their name & email addressThe dilemma is that: We need to have the address for the customer set once they are on the /quick-order page & registered. Not before.So I've done some work refactoring the ParentOrderController & order-opc files to suit. This is the sequence we have: Sign up using our soft registration sequence It creates an account & if you have something in the cart, will return you to the cart page (/quick-order aka order-opc.tpl). As you haven't entered an address, we've hidden the shipping & payment options. This works as planned You can add an address as you're already midway through the checkout sequence from the /quick-order page. This then redirects you to the Address class / control functionality where you can enter an address successfuly. Upon redirect back to the one page checkout, the system fails. The system is failing to recognise an address has been entered into the system, even though when running with the Smarty Debug Console, $formattedAddresses, $delivery & $address_collection has been correctly set. I've commented out the redirects to the Address page if a customers address hasn't been set in the cart & set a new smarty variable based on the Bad_delivery variable inside the ParentOrderController. PS Build is 1.5.6.1 Obviously I'm missing something that passes the smarty address variables back into the one page checkout sequence. Anyone know what they are?

Whilst the move towards SASS is a welcome step for 1.6, there are perhaps better ways of managing SASS than being dependent on Compass. There are ways of removing the Ruby/Compass dependency for Prestashop 1.6 & still maintaining code credibility. This is due to Ruby/Compass creating an overhead that may not be needed. As Prestashop is PHP based, you can actually use PHP to build & compile your SASS styles on the fly: https://github.com/reyhoun/sass-watcher PHP compilation is slow however in comparison to server level compilation using Apache/C. There is the ability for Apache to manage SASS for your themes (both admin & frontend) on the fly: https://github.com/sensational/sassphp using the Libsass C++ library. I maintain a custom fork of this latter codebase (also located on Github) and use it to build SASS on the fly for our design team. If your site is hosted using Nginx or Litespeed, there isn't a Nginx / Litespeed equivalent to the Apache extension, though hopefully someone will work on delivering that. So if you want to use SASS without Compass, it's entirely achievable.

Currently doing an in-place Git-based upgrade of our site from 1.5.6.1 to 1.6.0.9/11 and I've got everything working except this: The admin template does not display on the AdminModules page. Displays on every other admin page fine, just not that one. It's literally missing the header & footer code. To try & diagnose this issue I've: flushed cache_index flushed the caches With dev mode enabled, the page is not recording any errors either, which makes it annoying to diagnose in PHP. --- Solved it. Legacy 1.5 admin tpl/css files were still in Git trying to take over rendering.

I'm looking for a module (paid or free) that does this: Recognises the initial combinations of a product Mass add another variable (colour) to those product combination We currently use FSM CSV Pricing to generate the initial combinations of products, which means our pricing matrix is correct, but it's without colours. We've used Sitolog's Clone Combinations in the past but the issue becomes it takes too long to work on a product as we have to clone the pricing matrix out to another product, then clone it back to the original product in order to set all the colours. This can take up to an hour per product. We want to release another 300 or so products in our next release cycle if possible. The combinations generator that comes with Prestashop fails to recognise our products are in a pricing matrix & so breaks the pricing matrix when we try & add colours that way. Is there any paid modules that do what I'm looking for?

I have a new challenge to try & deliver for our store. I need a way to add a product to the cart when: it's not associated with the current product on the product page you are selecting the colour "product" I'm trying to do an algorithm to match product colours of our main products to "sample" products we sell cheaper. I don't want to do manual association as it's too much work. Any ideas?

I'm needing to extend the product page even further than what I already have. This in itself get complex. In order to minimise combinations & database overheads, all I want is: 1 free text field as a getValue string the sum of various extra select / option boxes & checkboxes turning into a getValue parameter as a string As it stands, we have a sum total of 22 extra various select boxes & checkboxes spread across 5 categories. The more product categories we have, the more this number will increase. I want to combine the $_POST output of what is on that area of the product page into a single getValue string variable. Product customisations wouldn't be the way to do this because: the number of extra form variables varies between product groups & it would take too long to replicate this into product attributes. As it stands, we are looking at potentially 80,000 product variations per product without including these extra form variables. I don't want to push this into millions of product variations per product by introducing more attributes than I need. product customisation functionality won't allow me to grab the sum total of multiple form select boxes / checkboxes & turn them into a single string variable available to be called by getValue By minimising the $_POST output to 2 potential variables that I can put inside the cart_product table, it will minimise product combinations, attributes and overall database load. Does anyone have any ideas how to achieve what I'm looking for? Or a software package that would do this for me?

We've been using a heavily customised (bug patched by us) edition of FME CSV Pricing to import all of our base price combinations for each product, as it's based on a matrix. This covers the width & height of our products, but not the rest of the product attributes (e.g. colour) As we're looking to now import around another 50,000 individual products to the store, whenever we want to add in colours & other product attributes to the product combination, post the matrix import, it breaks the pricing matrix. Is there any module that allows us to clone / duplicate combinations for 1.5.6.1 / 1.5.6.2 so that we can maintain the pricing matrix within each base product combination add in other attributes such as colour, etc?

I'm having a fairly unique issue with the cart logic at the moment. I've added in a couple of extra variables to be passed from the product page to the cart. When a customer adds in a second variant of the same product into the cart it's retaining the old values & duplicating when it should be seen as a separate product attribute variant I've tried a JQuery form reset of the product page and the blockcart-json.tpl file is still reporting the earlier values. e.g. Customer enters a value of 1200 for one variant of product. Adds to cart fine. Customer then enters a value of 925 for 2nd variant of same product. Instead of it being seen as a separate variant, it ends up being seen as a duplicate of 1st product added. Any ideas on how to fix this? - NVM fixed it

What we're experiencing at the moment is that about half a dozen products are being set to free shipping in the cart / ajax-cart when in reality, we've set: a specific shipping rule for those products verified that the rule exists inside the product_carriers table I've been through the forum trying to find a fix, but come up short. What I can glean from bug testing is that the shipping_cost & shipping_cost_float variables aren't being set for these products - they report as 0 instead of the specific shipping rule price. What irritates me no end is that this bug is seemingly random, it only applies to certain product IDs listed inside the product_carriers table. Specs on build: 1.5.6.1 Advanced stock management turned on, with all shipping rules enabled Guest checkout enabled - not one page checkout though