Acer

Because it's bad SEO practice - especially from a human readable point of view and keyword techniques. It just looks unprofessional and untidy. And it's incorrect to say that it doesn't impact SEO - it does actually matter to Google and we've seen noticeable impact on the rankings as a result of page name / URL path names. Our company has a very strong SEO / Marketing department with years of experience, and research, and know what it takes to rank #1 in search results. They will not accept IDs in URLs... and with modern SEO friendly URLs there's no reason for them to accept it.

I was referring to the Panda Blog - it's got more features than the standard TB Blog - which is one of the reasons we purchased Panda. Can anyone please assist with my original question: In the Panda forums there is mention of "Advanced SEO URL" to fix this issue - but I'm not sure about compatibility? https://addons.prestashop.com/en/url-redirects/19643-advanced-seo-friendly-urls.html?ab=1 Also, is there another way or free module to remove the ID from the Panda Blog URL? As we've been spending bucks on Panda+modules+very expensive modules (here's looking at you Advanced Search 4 - €250), we're reticent to just dish out more. Unless it is absolutely necessary, a free module or code solution is preferred.

This is a bit of an issue / deal-breaker then as we're running Panda also... I'll try the earlier version you suggested (4.12.5) Unless, someone here has the Panda fix? @Jonny

Anyone here on TB 1.1.0 with latest Advanced Search 4 v4.12.9?

Hi So it seems that Panda Theme adds IDs to Blog URLs. Due to our SEO requirements this is a big no-no. In the Panda forums there is mention of "Advanced SEO URL" to fix this issue - but I'm not sure about compatibility? https://addons.prestashop.com/en/url-redirects/19643-advanced-seo-friendly-urls.html?ab=1 Also, is there another way or free module to remove the ID from the Panda Blog URL? As we've been spending bucks on Panda+modules+very expensive modules (here's looking at you Advanced Search 4 - €250), we're reticent to just dish out more. Unless it is absolutely necessary, a free module or code solution is preferred. Perhaps @Jonny is around or does anyone else know?

Thank you

Thank you. On which version? TB 1.1.0 and latest Advanced Search 4 - V 4.12.9?

Hi I know this is an old topic. However, we're currently considering Advanced Search 4 for our TB 1.1.0 store and need to check compatibility. Are you still using it on your store? Do you know if it's compatible with TB 1.1.0? Thanks in advance.

Hi Awesome, thanks Zen and co. I haven't tried this myself yet, but from what I can see it's going to bring great value to Niara and the community. Once it's been refined a bit - should it not be included in TB for Niara as default / out the box? I vote yes 👍

You're welcome. Glad I could help 😀

Hi I've just done this on a fresh, vanilla installation. Following these steps worked for me: Grab the contents of the following file (updated JqZoom version): https://raw.githubusercontent.com/jackmoore/zoom/master/jquery.zoom.min.js Find the jqzoom file: js\jquery\plugins\jqzoom\jquery.jqzoom.js Replace the contents of plugins\jqzoom\jquery.jqzoom.js with the updated file contents. Save, clear cache, and try again. Product zoom should now be working as expected. Let us know if this worked for you.

Hi Not sure if you guys have seen this? Think forum posts were busy when I posted this, so it could've been missed. Anyways - it's here if you need it...

Changing the validator doesn't exactly make it "Vanilla" then? 😋

Lol - indeed 😕😅 Thanks again for the clarification and patience.

Wow. What a mission... 😓 The thing is I needed to check if a JavaScript block with a type attribute would be accepted first, as I will be adding JS to the page in some cases. This would then confirm to me that I can then adjust the script block type attribute and try Google Schema afterwards as a test, which does require "type". When the type attribute kept on being stripped out on my "does it accept Javascript type attribute with javascript/text" test, I kept on trying to fix it and was sent on this long mission... Phew. Thanks for the clarification and patience. My next question is why does your CMS accept the script tag without (I presume) changes to the Classes/Validate.php file?

Ok. Getting closer... It seems that your example <script type="xxx/yyy"> works... However, that is not the correct way of declaring JavaScript, as it's normally done with <script type="text/javascript"> That explains why your example is working and mine is not because I declared it with "text/javascript" For some reason if it has type="text/javascript" - it gets stripped out. Maybe you can try this on your side? Also, once again you'll need to modify the Classes/Validate.php file for the script tag to be accepted in the CMS system. Not sure why it was working on your side without this change to the file? Also, I've tested the actual Google FAQ schema code that is declared with <script type="application/ld+json"> and it works... However, this still doesn't explain why <script type="text/javascript"> doesn't work? Maybe you can provide an explanation / solution for this?

In a way it is related, because if Classes/Validate.php is not modified, then the TinyMCE configuration to accept the script tag will not work. Also, I'm running on the "release version" of TB 1.1.0 - direct download from the site (not GitHub). This is frustrating as it's still not accepting the script type attribute, and I've tried everything here so far. Been at it for hours since yesterday... Vanilla TB 1.1.0 No HTML purifier in Admin BO -> General Added "extended_valid_elements" to TinyMCE Eventually copied relevant section from your TinyMCE Had to comment out Classes/Validate.php CleanHTML script (for the CMS to accept the script tag) And still... not working... ?

How Vanilla is your Vanilla installation really? Because I've reverted to Vanilla and it does not allow me to insert Script tag in CMS editor - it gives the following error "the content type is invalid". And does not save the page. The only way to make this go away is by changing Classes/Validate.php and either commenting out the script part (under CleanHTML) or by gutting that entire block completely. Can you please double check what files have been changed on your side? and if so, please share contents in full.

Ok, this is just plain weird. Still not working on this side. Going to dig a bit deeper - maybe has something to do with Vekia's extended editor changes. Going to revert and give feedback later.

Curious... Please copy paste your tinymce.inc.js here so that I can try with your version. Thanks

Hi Actually, I tried this one and it does not work (lol) - have you checked view source? Just because the console.log or alert comes up doesn't mean the type wasn't stripped... Also, the reason why is for new Google FAQ Schema code - that has to be on the page and it takes <script type="json">. And no, it doesn't work with Tag Manager - so no on that one.

Um - are you saying that no one here has encountered this one? Besides the TinyMCE in TB (from what I can gather) could be as old as the mountains - so pretty sure not going to help here. Also, I've been through the TinyMCE forums + Google + StackOverflow - and nothing I'm trying is working... I'm continuing to look however. Hopefully one of you guys have the answer.

Hi I've been battling with this one for a while now and no matter what I've tried, TinyMCE keeps on removing the type attribute from the Script tag 🤨 <script type="text/javascript"> becomes <script> I've tried setting valid_children: "+*[*]", valid_elements: "*[*],script[src|type]", cleanup: false, apply_source_formatting: false, verify_html: false, And tried many other settings, and even though I can make it accept Style Tags with Type attribute - no matter what I try the darn thing doesn't want to accept Script Type="" (HTML Purifier is off bytw) Can someone please help with this one?

The original question had a second part on how to prevent TinyMCE from stripping the type attribute from the Script Tag. I've created a post for this one specifically:

Thanks. Now to stop it from stripping out the type attribute <script type="javascript/text"> ... lol