tnn

I sent some feedback to Google in the Rich Test Results regarding this topic and also referenced this thread.

IPS v4 will not have support for PHP 8.2. The End.

As a matter of principle, PHP 8.2 should be supported officially for v4 in the next months. PHP 8.1 is already in security-only support and that expires on 25 Nov 2024.

It looks like a bug with Google. Seems to be valid schema when checked elsewhere. 

It may be that the numbers are missing quotation marks. 
issue is: 
- Unrecognized field "interactionStatistic"
- Validation: Not Started
Possible Cause:
"userInteractionCount": 3557 
"userInteractionCount": 14299
Correct:
"userInteractionCount": "3557" 
"userInteractionCount": "14299"
(note quotation marks around the numbers.)
 
 

Hi. I know it's just a warning but... I'm reporting it as a bug. The warning applies to the user's profile.
Example Code:
"interactionStatistic": [ { "@type": "InteractionCounter", "interactionType": "http://schema.org/CommentAction", "userInteractionCount": 3557 }, { "@type": "InteractionCounter", "interactionType": "http://schema.org/ViewAction", "userInteractionCount": 14299 } ] }

My live site with 4.7.14, and test site beta 2 4.7.15 is with PHP 8.2 - no issues.

IPS has ALWAYS said that 8.3 is not officially supported. It’s not tested against it. While it may work for you, it’s not guaranteed to. 

So now you’re coming back to them upset because something did not work because you decided not to listen to them anyway?  I’m not sure how you can blame them for this. Just because it used to work does not mean it will always work when they clearly say that version is not supported or tested against. 

Before you complain about something, make sure your environment matches the system requirements. There is a reason those requirements exist… they don’t list them just to be difficult. 

That's a lesson I learned a long time ago.  🙂 The "latest" is not always the best.  In fact in the corporate world, most organizations run slightly older LTS releases of software instead of the hot off the press versions.  
The key question to ask is if there is something specific you need in the latest release (for example a known bug was fixed in the newest release that is causing problems for you).  From a security perspective, since 8.2 for example is still supported, if there was a major security issue, they would release the next sub point release (8.2.XX).  It would not require upgrading to 8.3.x until 8.2 is EOS.  

I know it very well... And because it happened and surprised me a lot, that's why I wrote it... It sounds strange, but it's a fact.

You guys should really consider adding a maximum PHP version check both in the suite and the requirements checker. I'm not saying to lock everything with the wrong version, even a simple warning in ACP would to the job.
 
With a simple check for the maximum version, you'd avoid dozens of support requests... 🙄

In a nutshell...  you want to upload the files to the same spot where you first installed the IPB software into.  We can't tell you EXACTLY where your files are uploaded on your website as it depends on your hosting provider and how they setup their server.  
Here's a little more detail on the process to do a manual upgrade:
- Download the latest version of the IPB software from the client area.  (If you had a legacy migration from another platform, you might need to also check the box to download the converters as well.)
- Extract that ZIP file that is downloaded.  Inside of it will be all of the files related to IPB.
- Launch an FTP application of your choice and connect to your server.  
- Find where your IPB files are installed on the server.  (If you're using a server with cPanel, this is typically inside of the "public_html" folder.)
- Upload all of the extracted files up to your server.  It will prompt you some of the files already exist and what do you want to do.  You will select to OVERWRITE the existing file.  
This process will take a little bit to do.  Once complete, you will visit yoursite.com/admin/upgrade to kick off the upgrader.  It will ask you to login with your ACP credentials and then walk you through the rest of the steps.  

If you're using the Adsense auto ad code within the IPS advertising system, it will NOT work.  Disable all ads in the advertising manager and use the template logic system.  The code that I used above does work.  The person you were quoting was using the auto ad code within the IPS advertising system, which puts the ad code in the wrong spot (within the body instead of the head).  This will cause very unstable results.  

Try turning those off...  because they may be causing problems.  Also don't just look for the ad to be displaying.  Actually right click and view source.  Look at the code to make sure it's injecting to the right group.  
Google does not always decide to return ads for every site on every request.  The only way to confirm it's actually "working" is to check for the code.  If the code is there, then it's a Google problem of them deciding not to show the ad.  

If you are only doing it for guests...  it's even easier.  You don't need to check group.  Just check if logged in.  
{{if \IPS\Member::loggedIn()->member_id === NULL}} <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXX" crossorigin="anonymous"></script> {{endif}} Smack that right before your end head code.  
Regarding appearing in other themes, make sure you don't have any ad code stuck somewhere in the IPB ad area that Jim linked to above.  You cannot use the auto ads there...  it MUST be in the global template otherwise it will not get added to the header and instead just stuck in wherever is setup within the body.  

Sure it does. I use the version of it to only show ads to guests. 

This code goes in your theme within the global template in the head section.  It does not go in the standard IPB ad code area. 

That’s how it shows up on my board:



 
I can also see the same thing here on IPS:

I have created a ticket on this for you, so we can take a closer look

I have taken a look at your settings there, and while spam at present is indeed an issue for a lot of people (there is simply a massive amount out there at present), I would suggest the following:
Switch to hCaptcha - Once you have done this, also increase the sensitivity of this on your account on hCaptchas website until it helps reduce this
  Add question and answer challenges. - At present you have none of these on your site

What I am assuming happened here is that the content was deleted while you're still on 3.x and something happened there to cause the disconnect. As we now handled that differently, the software is unaware of these abandoned images and won't deleted them because they aren't tied to content that was deleted on version 4. 
If that is not the case, we can investigate further. However, what you're in the middle of now with transferring these, is probably the best way to clear them.

The simplest method to achieve this en-masse would be to move your storage to another location. You would need to do a full backup of both files and database first, and be prepared to revert if needed. But essentially you would
Create a new storage configuration. Say "uploads2" Move all items to that storage location Whatever is left, are items not being used. So whatever is left in uploads (if thats the location you are using) should be able to be deleted. You can then move everything back to the original storage method if you wanted to do so.

1. Click on crawl management tab (you see it in your screenshot). Click on custom and define your own. You can also click on “Do not use” and create your own file via FTP.  Remember though… if you choose custom or do not use… you start with nothing for the file. So you might want to add even the stuff that might already be in auto the IPS generated version. 

2. This is typically just the root of your install with the protocol. So https://yourwebsite.tld/invision/sitemap.php based on your example above. 

3. Slowing down bad bots, etc is not something you do at the software level. You do that at either your server level or firewall level. Talk to your host for help with that. And bad bots don’t respect robots.txt just fyi. 🙂 
4. That’s a server/hosting issue. You might block them using custom .htaccess rules or via a firewall. 

This also goes to show as much as Google loves to preach speed and performance… it’s somewhat of a do as I say and not as I do. 

Between their ad code and analytics code… Google has a long way to go to clean up their own house. 🙂 

I’ve played around with it in localhost environment without issue. But that does not catch everything that could happen in a prod setup. 🙂
Thanks @CheersnGears for being a lab rat!  We will bring some cheese for you! 😂