gabeshackle

I'm getting the same error when attempting to upgrade. All files upgraded. Now upgrading database... [Ajax / Server Error for action upgradeDb] textStatus: "error " errorThrown:"Internal Server Error " jqXHR: " "

I posted a fix in a related forum topic using an override: http://www.prestashop.com/forums/topic/315798-no-html-allowed-in-blockcmsinfo/?do=findComment&comment=1666595

There are a couple live chat providers who's documentation state that the embed code should be placed in the head of the site. Either way, this kind of optimization is something that should at the very least be a global setting that can be turned on or off and ideally could be manipulated on the individual instances like in my override. In my opinion, PrestaShop should not be modifying template controlled HTML unless the owner of the code is intentionally initializing it. It took a good 2-3 hours of investigation just to figure out specifically what was going on when this started happening. This change definitely feels like it's someone's opinion of proper code practice being forced on the developers regardless of the impact it will have. Especially this particular type of change as the improvement to page and site performance is extremely minor at best.

This makes the erroneous assumption that everyone follows the best practices rules regarding using jQuery. I have a few 3rd party vendors that require their code being in the header. With the current version of PrestaShop (1.6) this is impossible. As a workaround I created a Media class override that allows for a specific custom attribute to be applied to the opening <script> tag which will allow you to keep that tag where it is and render the JavaScript in that position within the HTML. I've posted this script and an example on GitHub here: https://gist.github.com/hereswhatidid/8c8edef106ee95138b03 If you take that Media.php file and place it within the /overrides/classes/ directory of your installation, then delete the /cache/class_index.php file you should be able to use that method. I'm not sure if that's the ideal way to handle it but it works for me currently.

As of 1.6 ALL inline JavaScript is being pushed to the bottom of the page. Even those scripts being manually written in to a template file. This has been a major headache for me since upgrading.

One thing I've noticed that may be quite problematic for people is that as of 1.6 it appears that all inline JavaScript is being forced to the bottom of the page. This would essentially break any inline script that was dependent on where it was supposed to be written within the page. How can we disable or at least force this not to happen on a case by case basis?

After upgrading to 1.6.0.5 I'm also seeing all <script> tag contents being stripped from Smarty output even when using {literal} wrappers. This is a pretty significant issue as it completely destroys all inline JavaScript.

I have a module that allows the admin to select from a number of optional blocks of HTML to be displayed on the product detail page. The content of each of these blocks is editable via the module's configuration screen. The problem I'm having is determining how to clear the cache on the these templates as I may want to clear the template for just the single product if that particular product is edited but I also would want to clear all instances of those templates of the module configuration changes. I'm using 1.6.0.6. Basically I'd like to know if there's a way to clear all caches, regardless of cache id, associated with a particular template file. Here is my code for creating the cache on a product by product basis: if (!$this->isCached('mytemplate.tpl', $this->getCacheId($unique_product_string) )) { $this->smarty->assign(array( 'title' => Configuration::get( 'title' ), 'description' => Configuration::get( 'description' ) )); } return $this->display(__FILE__, 'mytemplate.tpl', $this->getCacheId($unique_product_string) ); And the code to clear the cache for that template (which returns 0 clears every time): $this->_clearCache('mytemplate.tpl');

Actually, some digging around turned up that the commands were simply renamed in TinyMCE 4.0. The new commands now are: mceRemoveEditor/mceAddEditor I'd still like to see if there's some way to reinitialize the Bootstrap components as well though.

Is there any way in the new 1.6 admin to be able to trigger the Bootstrap and TinyMCE activation scripts from a custom Tab on the Product edit page. For example, in the past I've used: $(document).ready(function(){ tinySetup(); tabs_manager.onLoad('Informations', function(){ tinyMCE.execCommand('mceAddControl', false, 'sidebar'); }); }); To ensure that the TinyMCE field in my custom tab would load. This no longer appears to work after upgrading to 1.6. Is there any PrestaShop-endorsed method for adding custom tabs to the product page and have all the initialization scripts applied to them? The primary problem is that the custom tabs are not actually written to the Product page on the initial load but are loaded via Ajax on click.