sadams101

4 hours ago, Matt said:

It's quite tricky because we do have a lot of styles that could be potentially used, but are often not until a widget is added, for example. Tying specific styles to specific widgets is quite difficult.

However, we acknowledge that our CSS could be rebuilt and be more efficient. It's something we really want to fix.

For years IPB has promised site speed increases, and every one that you've delivered to date has turned out to be too little, too late--at least for anyone who is concerned at all about their Google rankings.

Here is a speed test of this very forum thread--and you use CDN with zero ads running--you score a 51%, which is an F for FAILURE:

After mostly CSS changes made with the ability to edit CSS files directly--the feature you just took away from everyone (and with the help of @Adlago), here is a similar forum thread on my site--I have no CDN and am running a large number of graphical ads:

What you see here is a site with mostly CSS changes, and it scores 25% faster than a site that is on a CDN with no ads. How is that possible? Perhaps you need to hire @Adlago because apparently speed improvements are still not on your radar, and now you've gone out of your way to strip the ability for those of us who actually care about this issue to be able to do something about it ourselves.

On 7/6/2022 at 1:53 PM, Jordan Miller said:

We are trying to discourage editing the core css files. Let's see if we can find another route. Can you expand on what specifically you want to achieve and maybe we can find a solution together. 😃 

I also cannot believe that you've removed this, and, after more than 15 years, and also looking at alternative boards to import my site into...totally unacceptable!

Your site speed is absolutely horrid...the only way I've been able to make my site get even average speed scores has been through extensive modification of CSS--now you've removed this ability from my--WHY??!!

Ahh...my bad...sorry about that!

So the programming that creates the canonical link is not stripping off this when you view the article:

• ?cat=11

but of course it should, otherwise there will be duplicate content issues in Google and other SE's.

So you've described the problem, but what is the solution? A blog, just like an article, must have only one canonical link.

Here is an example and this says 6, but as you can see there are 9 articles:

https://www.celiac.com/articles.html/journal-of-gluten-sensitivity/autumn-2004-issue/ 

I have some categories that say there are 6 articles, when there are actually 9. Is there a way to reset the count, or make the system rebuild the article counts in categories?

An SEM Rush report is showing duplicate content issues on my site, and they are from the blogs. For example this page:

https://www.celiac.com/blogs/blog/1432-lynda-meadowss-blog/

and this page:

https://www.celiac.com/blogs/blog/1432-lynda-meadowss-blog/?cat=11

are identical, yet their canonical links are different. This should be the canonical link for both:

https://www.celiac.com/blogs/blog/1432-lynda-meadowss-blog/

There are many such pages which have been indexed, so I'm hoping for a fix that will correct the canonical link in such cases.

I run over 25 apps and plugins, most are custom, and I did have to upgrade around 1/3 of them when I upgraded to PHP 8.0, but every single one of them seems to work fine with 8.1, so it seems to me the big leap was going from PHP 7.4 to 8.0, and the jump to 8.1 was not as big of a deal,

I'll report any errors I see, but so far I've been running it on a fairly busy, large forum for at least two months...long enough for Google to notice anyway 😁, and so far the main thing I've noticed is improved performance.

Any estimate on when the update will come out that fully supports 8.1?

Ok, I never do that.

I'm wondering why you've issued this warning today? I've been running PHP 8.1 without issues, and have been checking the logs for any issues, but see none. It's compatible, or I'd be seeing errors.

In fact, I see more errors in my php-fpm logs from when I was running PHP 8, then after I switched to PHP 8.1, and I won't even mention the awful speed scores I got from Google while running PHP 8.0. Downgrading to PHP 8.0 would cause my site rank to begin tanking again due to speed issues...it's been improving ever since switching to PHP 8.1.

Unless you can point to something very specific that would break by running PHP 8.1, I don't understand the new warning. Please explain?

 New Dashboard Warning:

Quote

PHP 8.1

Please be aware that Invision Community does not yet support PHP 8.1. Please downgrade your PHP version to the latest release of PHP 8.0 until we have finalised support.

I believe I reported this a couple of years ago, or made a suggestion to upgrade this, but it is still an issue. Whenever someone shares an article on my site the iFrame tags that are embedded insert this obsolete html tag: scrolling="no"

I am not sure about other sites, but with mine we share lots of the articles, so this error is an issue with SEO, and you can see examples of it here:

https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.celiac.com%2Fforums%2Ftopic%2F156801-do-anti-diarrheal-medications-help-during-recovery%2F 

Is this something you are aware of, and working on?

So it appears google will now accept a new sitemap as a regular sitemap submission, as long as it is formatted according to their news standards. After submitting my custom news feed as a sitemap my site was picked up again in Google News:

https://support.google.com/news/publisher-center/answer/9545414

It's possible that google news changed their formatting requirements. I'll look into this and report back if that is the case. 

It is true that I do have other sitemaps, and also true that each one of them validated just find before whatever update you did, but now they won't validate. So I'm confused by your responses here...is this your way of saying "nothing to see here, nothing is wrong," or are you looking in this issue?

PS - Your site map won't validate either...but did before right?

https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Finvisioncommunity.com%2Fsitemap.php

Google news cannot read the sitemap due to this issue.

This is how I discovered it...my site was dropped from Google News.

I suspect that an IPB update has caused an issue with the site map, as it will no longer validate:

https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fwww.celiac.com%2Fsitemap.php

I do know that this validation issue was not present until recently, but I don't know exactly when it began.

So after a server reboot the issue went away. It must have been related to caching.

So it seems to me that IPB should be the ones to do this, as several of your customers have already chimed in here to let you know about this issue, and most of your users likely don't know that it is an issue, but it is affecting their sites nevertheless.

My site continues to get warnings for this which reflects poorly on my site's SEO. It appears to be a simple fix, so why not fix it?

I cleared the Redis cache using:
 

redis-cli flushall

but unfortunately the issue is still there. My guess is that there must be something stored in the database somewhere.

Thank you, I did check there first, and every setting there is the same for all items in there:
/home/mysite/public_html/uploads

This is what led me to suspect a possible caching issue. I did clear the cache in the ACP's support area, but not the Redis cache. Is it possible that the old URL path got stored in Redis?

I guess I was hoping more for guidance on how to resolve this, rather than creating a support ticket. Would you be able to point me in the direction of what might be causing this? Could it be my Redis cache, and should I purge it?

BTW, this problem happens if you type the emoji in, or if you select it from the emoji choices. So if I type in or select a _default emoji:

:)

it will simply input the full URL, with the old subdomain in it.

I recently eliminated using a sub-domain to server my site's images, JS, CSS, etc., and under the Storage Settings I went back to this:
/home/celiac/public_html/uploads

from this:

https://sfd.celiac.com/home/celiac/public_html/uploads

All of my newer (what are non-custom emojis--I believe the "custom" ones are the originals from many years ago, but am not sure, as I never created a custom emoji, yet a dozen or more now exist in my 15 year old forum) emojis post just fine, and all new and old seem to display fine, however, when you post a custom one, that is one of the older emojis that are defined, it is simply posting the old subdomain URL into the post, so no emoji appears...just the URL appears exactly as below:

https://sfd.celiac.com/uploads/emoticons/default_smile.png

I believe that I've tracked down part of the issue to this code:

uploads/javascript_global/root_framework.js
 

for(var i=0;i<this._emoji[parts[1]].length;i++){if(this._emoji[parts[1]][i].code==codeToUse){var imgTag='<img src="'+this._emoji[parts[1]][i].image+'" loading="lazy"';imgTag+='title="'+this._emoji[parts[1]][i].name+'" alt="'+this._emoji[parts[1]][i].name+'"';if(this._emoji[parts[1]][i].image2x){imgTag+=' srcset="'+this._emoji[parts[1]][i].image2x+' 2x"';}

and perhaps there is a place somewhere in the ACP that I made changes to years ago, but I can't seem to find it. Any ideas how to get these older emoji's working using the default path instead of the subdomain?