Is this really starting all over again? How many times does it have to be pointed out that URL delisting shown in the Search Console cannot be caused by the sitemap generation?
Listing and delisting happens when Google crawls the actual URL and it is decided based on what it finds on that URL. That’s it!
The sitemap can only help Google to find the URL faster. Nothing in the sitemap will cause an URL to be delisted. How could it? It’s just URLs saying “please check this out, Google!”. No slow or incomplete sitemap will cause delisting. No faulty sitemap will cause delisting. No entirely missing sitemap will cause delisting. Nothing in the sitemap can cause delisting.
If you find an actual bug in the sitemap creation you can demonstrate to be true, better open a support ticket or start a new topic about this bug and nothing else instead of adding it to this huge pile of “I don’t like my Google stats and I will just blame IPS and ask them to fix it”.
No. And copying some text from a blog on the internet doesn’t prove the opposite.
In any case: I merely add a button to access IPS’ contact form. I won’t change its functionality.
Not sure I understand the question. It’s just a more visible button linking to the contact form. (And you can choose the user groups who see it.)
Contact forms do not require additional consent, just as a online shop does not need consent that you use the shipping address for shipping the order.
However: It doesn’t hurt if you describe your use of the contact form data in the privacy policy. Is the data stored on the website or sent via email? Will it be deleted after a while? Do you guarantee not to sent advertising or give the data to someone else. This kind of stuff …
It is using the setting “Cache sidebar, header and footer blocks”, but that is usually only set to a few minutes.
So to be clear: the order should change each time the cache time has run out, not on every page load.
SuperBlocks is just styling. It doesn’t change anything about the ordering of records. That comes from Pages. So your problem probably has a different cause.
It shouldn’t matter where the image is stored, as long as its accessible and not outdated.
I can’t really debug this from a screenshot though. Have you tried to hitting the “scrape again” button as mentioned in the instructions?
Okay. I fixed that problem in the 1.0.2 release. You only need to upgrade the settings plugin. That will overwrite the old template (if it was unchanged). If you still don’t see a change, clear the cache.
The layouts are independent from the app. Just the number of items matters. How many are you using for this block?
I fixed the bug of the layout with 5 items in the latest release.
There are no plans to add this to listing views. Showing the results of any possible reaction needs way too much space for this design and leaving reaction makes no sense, since you first need to see the entry to react to it.
Edit: I just checked. Not sure why you still see that. It shouldn’t be in the 3.0 version at all. Its not only stripped from the templates, but also from the settings form.