Marcelismus

I can’t see any error on the page. And the information is too sparse to help, sorry.

Sounds to me like Gutenberg is coming into play? There is this bug there, but I have not been able to get it fixed for ages, as the reason is a mystery to me – it works for some, but not for others.

These are just the official URLs of the specific stores (just search for an app and you’ll have the url/domain). Google, Apple and others outsource the images to other servers, but you have to find that out manually, since they are variable (see the source tab in the developer settings of common browsers).

I don’t understand what you want.

The plugin calls the HTML code from the App Store, Google Play, etc. pp. and “reads” it. Other than that, there are no servers involved.

• This reply was modified 3 years, 4 months ago by Marcelismus.

This seems to me to be a bug at Apple – they currently show every app as free in the embedded JSON data. I’ll watch it for a few days, if necessary there will be a workaround fix.

• This reply was modified 3 years, 5 months ago by Marcelismus.

It is currently a Google-only attribute. I think that helps you much more and is the way that should be used (because more universal and flexible):

https://michaelkummer.com/tech/wordpress-link-attributes/

Yes, I have. But it is not used correctly according to the attribute purpose, if _affiliate_ links are _always_ marked with rel=sponsored (affiliate =! paid link) – and then Google has to introduce a new attribute again sometime, because everything is simply marked that way. Therefore there will be no global option.

• This reply was modified 3 years, 6 months ago by Marcelismus.

To mark all affiliate links with rel=sponsored does not correspond to the meaning of the attribute in my eyes:

rel=”sponsored”
Mark links that are advertisements or paid placements (commonly called paid links) with the sponsored value.

(developers.google.com)

In some countries affiliate links have to be marked, but that’s another topic (and can be realized better/flexible via CSS). rel=sponsored refers to purchased links, i.e. if developer John Doe paid you something for the placement. Just because affiliate links are used, the link to the app must not have been paid, so the correlation is not given.

The app data has a validity of 30 days. Once a day, 5 expired (i.e. 30+ days old) data is updated. You can calculate how long it takes to update, for example, 100 apps in the database. But as I said: There is no right or wrong. It’s just how up-to-date you want the app information displayed in the blogposts to be (also depending on how often min the pagecache is refreshed).

Next question: Why does the app have an old title and an old icon and why are they not updated ??

• This reply was modified 3 years, 6 months ago by Marcelismus.

Not “require”. A flush of the post cache can be triggered when an app is manually regenerated. Take a look at the cache-settings for WP-Appbox.

The time indicates when the app data is reloaded from the store when the web page is called up again – otherwise the stored data from the database is used.

Has nothing to do with page caching, but of course correlates with it. Since WP-Appbox’s code is only executed when the “real” PHP web page is also called, the query can of course take place – namely when a page’s HTML cache is also rebuilt. Seems a bit confused, but they are two different things, hence a logical flow of the processes.

Min and max values do not exist. However, if the time is too low and the requests to the app store servers become too high, the risk of a (temporary/permanent) bot lockout is possible.According to my tests, 720 minutes is still fine for small to medium sized sites.

As I said, it’s not enough to just attach the extension – because with the current mechanics (no cURL), saving the Google images (and other actions regarding screenshots) is not possible without further modification. Also with regard to already saved images.

There will be a change to the mechanics only with a new bigger update (and no idea if it’s working with CloudFlare); but this will no longer be 2021.

• This reply was modified 3 years, 6 months ago by Marcelismus.

Sounds simple – but leads(s) to problems with some stores, because partly different formats were output and for example Google does not deliver a “real” file (url). An additional query is unfortunately also not so easy possible – there would quickly start the bot protection of Google and Co. for medium pages.

To change the mechanics in the plugin would currently also rather a matter of weeks to months. Try to intercept the query and deliver the header yourself – if additional caching via Cloudflare is necessary. Currently not prioritized.

• This reply was modified 3 years, 6 months ago by Marcelismus.

The image is saved as it is on the stores, there are no conversations or changes (MIME type is recognized correctly). And as far as I know, an image does not have a response header, that is provided by the server ??

• This reply was modified 3 years, 6 months ago by Marcelismus.