Gooly

Marius, I don’t see the point really. Theme creators may pre-define how posts and pages should look, declare what blocks can be used and eventually block them.
I didn’t dive into that kind of options, but I believe you completely on that. Nevertheless it sounds like doing the same thing we are already doing, only in a completely different way. So yes, I see the big change here, and no, I don’t see the additional value over what’s already there.

And on top of that (as I also explain in my own review), in my case I work with people who only need to change the ‘raw’ content of the blocks. At most they need to be able to select another content type. And like I said, that can already be done without Gutenberg. I don’t want these people to touch the styling, just the content. So ‘freedom’ is an overrated value here. I don’t want them to have this freedom. People want simpel, easy and intuitive interfaces. And “simpel and easy” means per defenition “restrictions”. Which is freedoms mean nephew.

And finally, it has (in a lesser way) the same problem that pagebuilders have: It can turn website migrations or theme changes to enormous projects because the content is polluted with all kinds of styling code which shouldn’t be there. And yes, I noticed that lots of the Gutenberg code is wrapped in HTML comments. This does make it more harmless in other situations, but it also makes a realy clean fresh start almost impossible. The dust has not been removed, it has only been swept under the rug in the livingroom ??

I fully agree with that. It’s like a scalpel for people who have no medical skills.
“You’re a gardner, but want to perform a surgery? No problem! With this special scalpel you can take any organ out of a body you like”
The patient will probably die or at least become disabled for the rest of his life, but hey, you as a gardner performed a real surgery ??

Thanks for your answer James. However this seems a ‘last resort’ solution. More a workaround then a solution. So before using a plugin like this, I rather find out what is causing this. (Or maybe I’m too stubborn ?? )
Both URL ‘versions’ are valid image urls’s, both lead to a valid, existing image. Nevertheless one works fine and the other displays a broken image as if the image is not there.
I checked it with the Chrome developer tools, and found out that the problem images don’t have a HTTP status (like 200, or 404) but a browser message: net::ERR_BLOCKED_BY_CLIENT

[edit] OK, this is not WordPress related.
I just found out that it must be one of my browser extensions. (Probably some add blocking thing). If I check it with a completely default Chromium browser (No extensions or additional changes) than it works fine and the images are all there.
PS. it’s Privacy Badger
[/edit]

• This reply was modified 6 years, 11 months ago by Gooly. Reason: New information foubd
• This reply was modified 6 years, 11 months ago by Gooly.

Resolved

Thanks bcworkz.
Yes, it’s hard to work around WP’s HTML fobia But with good reasons ?? I like WP’s security.
Someone pointed me (elsewhere) to the fact that the tagline is used on several places, not only as tagline in the frontpage, but e.g. also with page <title> generation. This made me realize that it might not a good idea to work around it.

So I decided to create a new custom field for it in Settings/General named: ‘Alternative Tagline’. This setting is also being ‘entitied’ before going to the database, but that is no problem. A simple PHP html_entity_decode() didn’t look too secure for me, so I decided to create a function to only decode ‘anchor related tags’

finally the function needed to be implemented in header.php, so that was the point where the plugin changed to a child-theme.

• This reply was modified 7 years ago by Gooly.

I tried to avoid decoding to entities with different hooks like option_blogdescription and pre_option_blogdescription
PHP html_entity_decode(), wp_kses(),
Getting the content directly from the hook parameter, getting the content with get_option, getting the content with $wpdb->get_results
But whatever I try or do, in the end my HTML shows up as entities.

If you have FTP access, you could simply remove the plugin from the /wp-content/plugins directory. Wp is smart enough to notice an go without the plugin.
Once you have access again you can put it back and eventually de-install it the correct way.

I’m not familiar with that plugin/option. But if I’m realy locked out and nothing else works, I create a new password directly in the database (E.g. with PHPmyadmin)

You’re supposed to first encrypt your new password to a Md5 hash. E.g. with
https://www.miraclesalad.com/webtools/md5.php

And that generated MD5 hash can be placed in the database in: wd_users > (you) > user_pass

Save it and you should be able login again. (Unless that plugin uses an entire other login feature then WP by default does ?? )

Edit:
Steves reply above is much more complete. We were writing at the same time ??

• This reply was modified 7 years ago by Gooly.

Thanks bcworkz.
Your reply makes a lot of sense. This is the reply I hoped for ++
It opens a new approach for me which I’m going to dive into. I either come back with some questions, or with the response that everythings works fine ??
Thanks again!

Many tnx Jacob!
This is exactly what I need. And on top of that, I learned something new ??

I’m not an expert in this matter, but usually when I have this error, I’m in some kind of redirection loop. E.g. the browser starts the route to ‘www.example.com’, a virtual host- or .htaccess file rewrites it to ‘example.com’ and WordPress rewrites it back to ‘www.example.com’. This results in an infinite loop. So not only the WP configuration is involved in this matter, but also the webserver configuration. So it might be an idea to also check what the .htaccess does and what the webserver configuration redirects.

Thanks for the tip Bet.
That’s a good tip for the themes. However if I leave the plugins deactivated, still the owners of the subsites will be able to activate it.
However from now my question only regards the plugins ??
Thanks for your help.

That makes sense JakePT. Thanks!
(I asked this question on some more places and this is the only answer not saying: “I don’t know, I just do it” ??

Clear Lorro. I understand now what you mean. I assumed falsely that setting every single variation only was required if you wouldn’t offer all possible variations, but only a selection of them. (E.g. when you only want to enable the big blue ones and the small red ones) and that not configure every single variation simply would fall back to defaulr parent settings.

I configured all variations now seperately and (after disabling the mention jQuery plugin) it works like a charm now.

I can imagine that you’re confused. I’m pretty new to WooCommerce (hoewever experienced in WordPress) and I’m learning WooCommerce and building a theme for it at the same time. Not exactly my favorite way of working, but the situation leaves me no other choice ??
But this situation leads often to confusion, for myself and for others.

Thanks very much for your effort Lorro. You did help me enormously.

OK, I have a problem isolated. I used a Bootstrap jQuery plugin (selectpicker) which caused a problem. After disabling that my theme behaved as any other theme; the add to cart section appeared when expected ??