Jump to content

sadams101

Clients
  • Posts

    778
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by sadams101

  1. I have no doubt that some Invision communities are doing "very well" in Google. Some might even say that my site is one of those, however, I can assure you that I've gained at least at least 100,000 in my USA rank (now around 50,000) after dealing with the many speed and SEO issues inherent in the out of the box version of this software. This is a huge difference, and in my case represented the difference between ~100,000 unique monthly visitors before, and ~350,000 after. So my question to you is, could those communities that are now doing "well" actually be doing a hell of a lot better? Yes.
  2. Hopefully you realize that your "Fantastic" means that most of your "beautiful" complex layouts on your customer's sites will never make it to first page Google results because they have a boat anchor tied around their necks, from which they cannot escape--thus their hard work, articles, posts, etc., will sink to page 5...10...20...who knows how low? The longer you fail to address this, the more weight Google will put on sites with such speed issues, because that is what Google does. Also, you didn't address the real issue here, which is stripping away my ability to do this myself--so far in this thread none of the arguments for doing this are convincing--why not allow users who want to do this to be able to continue editing their CSS?
  3. 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.
  4. 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??!!
  5. 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.
  6. 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/
  7. 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?
  8. 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.
  9. 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,
  10. 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?
  11. 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:
  12. 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?
  13. 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
  14. It's possible that google news changed their formatting requirements. I'll look into this and report back if that is the case.
  15. 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
  16. Google news cannot read the sitemap due to this issue. This is how I discovered it...my site was dropped from Google News.
  17. 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.
  18. So after a server reboot the issue went away. It must have been related to caching.
  19. 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.
  20. 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?
  21. 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.
  22. 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?
  23. 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?
×
×
  • Create New...