-
Posts
363 -
Joined
-
Last visited
-
Days Won
13
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by Acer
-
-
19 minutes ago, zen said:
I can confirm that ids in URL is not a problem, just an aestetic plus, you should contact support for Panda theme to fix it for you, as it is a purchased licensed product.
In fact ids in URL can be a real plus when you'll change your blog system, redirections will be easier !
Look, maybe from a technical point of view and from a developer's point, maybe it's not a problem.
However aesthetics do matter and from an SEO / Marketing expert's point of view, it's a big deal.Also I've asked the Panda team - but so no solution so far. That's why I'm asking the TB community - to check if you guys maybe have a solution?
-
On 11/13/2019 at 9:33 AM, haylau said:
It is definitely the lazy load on the category section of the theme. Disable that and all is well.
Good to know, however lazy load is critical in improving page load speed (plus it looks cool) - so it needs to be sorted somehow before we can go 4.12.9.
I don't suppose any one here know the fix for the Lazy loading issue? @Jonny
-
8 minutes ago, datakick said:
Out of curiosity, why are IDs in url such a big deal for you?
Friendly urls have zero impact on SEO. Google and other engines really don't care at all They are interested in content only. The only reason to have friendly url is type-in traffic. And be realistic -- nobody will ever going to type in url to your blog post into the address bar...
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. -
17 hours ago, zen said:
I do have one client with Panda theme installed... I just upgraded it from PS 1.6 to TB 1.1
For the blog side, they now use TB blog and have no problem for URLs without IDs in 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. -
13 hours ago, haylau said:
OK, tested. All seems to be OK. Except when products are filtered the images are missing. This may be an conflict with lazy loading in the theme as I seem to remember this before? We are using Panda. @Jonny
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?
-
18 hours ago, haylau said:
Advanced Search 4 v4.12.5
TB 1.1
Thank you
-
20 minutes ago, haylau said:
We are currently using it without issues
Thank you. On which version? TB 1.1.0 and latest Advanced Search 4 - V 4.12.9?
-
On 10/19/2017 at 5:58 PM, wakabayashi said:
@Baarssen yeah but they just fixed it for my personal use. So if you have same problems, you should write to the support.
I am exciting for the new elasticsearch module. I hope it will even be better then advancedsearch4.
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 👍-
1
-
-
31 minutes ago, danae5d said:
Thank you, is working fine, thanks a lot
You're welcome. Glad I could help 😀
-
51 minutes ago, danae5d said:
Hi, I tried to do this update, but I doesn't work and the zoom is not working
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):
-
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... -
2 hours ago, datakick said:
🙂 the life of a developer in a nutshell
I temporarily changed the validator for the column from 'isCleanHtml' to 'isString' --> classes/CMS.php
Changing the validator doesn't exactly make it "Vanilla" then? 😋
-
2 hours ago, datakick said:
🙂 the life of a developer in a nutshell
I temporarily changed the validator for the column from 'isCleanHtml' to 'isString' --> classes/CMS.php
Lol - indeed 😕😅
Thanks again for the clarification and patience. -
1 minute ago, datakick said:
You are right, type='text/javascript' is indeed stripped. That's probably because in HTML5 'text/javascript' is the default type for script tags. Type attribute is optional and should be omitted if script is text/javascript.
So, the correct way to declare scripts in html5 is simply <script> and not <script type='text/javascript'>. This is probably why tinymce strips the type when it is equal to default value. I would say it's nothing to worry about, since there is no functional change
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... ? -
40 minutes ago, datakick said:
Right, this does work on vanilla thirtybees installation. If you have other modification it can have conflicts.
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. -
Just now, datakick said:
It does work:
1) source
2) Rendered page
Curious...
Please copy paste your tinymce.inc.js here so that I can try with your version. Thanks
-
3 minutes ago, datakick said:
First of all, I wonder why would anyone wanted to inject scripts via tiny editor. It's very dangerous to open this functionality. For example, when you copy and paste some text from some web page you can unknowingly copy some <script> tag with it. This is a can of worms...
But if you are adamant to do this, who am I to argue with you, right 🙂
I googled this and found the answer in the very first stack overflow question. You need to use
extended_valid_elements: 'script[language|type|src]'
Tested, works correctly in thirtybees.
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.
-
13 minutes ago, datakick said:
I suggest you try to ask this question on some TinyMCE forum
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.
[Please help] Panda: ID in Blog URL Solution? Is "Advanced SEO URLs" module compatibile, or alternative solution?
in Module Compatibility
Posted · Edited by Theo
Wise words indeed and agreed. And Lol - another thing to add to the "let's not discuss list" at parties, next to "religion, politics, etc."
And woahah! - the price and time to do this just seems insane. Thanks for checking that module...
ST Themes recommended maybe this module - mind having a quick squiz at the features pls?
https://www.sunnytoo.com/product/prestashop-removing-ids-urls-module-seo-friendly