sadams101

Thanks for reminding me of that possibility, but this isn't the case. Here is the RSS feed, which is now set to ALL categories: https://www.celiac.com/rss/7-celiaccom-disease-gluten-free-diet-support-since-1995-articles.xml/ If you compare to the live articles on the home page you will notice that quite a few are missing. Note that there are a few pinned articles that have publish dates not in chron order, but after those all are in chron order, but don't match up with the RSS feed: https://www.celiac.com/

I set up an RSS feed, and am having issues with missing articles in my Pages app. I fully understand the settings--I've selected "Articles" under the "Content" setting, under "Categories" I've checked ALL, and content posted by everyone, yet around 1/3 of the articles do not show up in the RSS feed. I've also tried selected every category manually to see if anything is different, but there are still 1/3 that are missing. Does anyone know why this could be happening?

You do not even know anything about what we are doing.

I can assure you that @Adlago knows how and why there is a need to edit IPB's core site files, and that we know how to upgrade after doing so. The reason we have to edit them is because of IPS' ongoing site speed issues, which they are always at least 2 years behind in addressing, for example this thread: IPB is mistaken if it believes that CDN's will help with site speed. After going back and forth from a CDN I found they do not help. Most of the speed issues with IPB software are inherent in the IPB application, and as @Adlago has pointed out, have to do with how IPB's JS and CSS files written and served. This is why some people need to tinker with these files, not for fun, but for speed...no CDN (if we could achieve this without editing the core files we would):

I my pages app, for some reason, whenever you edit an article the article's image is deleted and renamed in the background. Like most people who use the pages app, I often have to go into older articles and fix a typo or change something. Whenever I do this the article's image URL is changed. This can cause issues with image search in google, if your image was indexed and is suddenly throwing a 404, and it also causes problems with my weekly eNewsletter which I send out to my subscribers (I often cut and past last week's article content from my index page into that eNewsletter--if I should edit any of the articles within that eNewsletter after I've created it, the image is broken in my eNewsletter and the only fix is to correct it before it gets sent, or if the eNewsletter has already been sent to create a 2nd duplicate image with the old name). It would be great if the image wasn't deleted and renamed when you re-save an article. I can't really think of any reason why the current programming that causes this to happen would be helpful for anyone.

For the past couple of days I've seen this error repeat over and over in my php error logs. Does anyone know what could be causing it? [08-Aug-2022 00:10:59 UTC] PHP Deprecated: Optional parameter $votes declared before required parameter $pagination is implicitly treated as a required parameter in /home/mysite/public_html/uploads/template_cache/template_161_7a734b11232065691bc1176040cb26ad_topics.php on line 3174 [08-Aug-2022 00:10:59 UTC] PHP Deprecated: Optional parameter $nextUnread declared before required parameter $pagination is implicitly treated as a required parameter in /home/mysite/public_html/uploads/template_cache/template_161_7a734b11232065691bc1176040cb26ad_topics.php on line 3174 [08-Aug-2022 00:11:04 UTC] PHP Deprecated: Optional parameter $question declared before required parameter $pagination is implicitly treated as a required parameter in /home/mysite/public_html/uploads/template_cache/template_161_7a734b11232065691bc1176040cb26ad_topics.php on line 3174

I use this plugin on my site with Pages, and regularly schedule articles to go live at later dates, and I have not had the issue that you describe here.

When adding an image to an article in Pages, which is probably accounts for 90% of the images I use in articles in Pages, I see this when uploading the image: Accepted file types: gif, jpeg, jpe, jpg, png However, when using the insert tool to insert an image within the text of an article I see this: Accepted file types: gif, jpeg, jpe, jpg, png, webp I guess I am wondering why webp would be excluded as an option for the article's main image?

Since I don't know exactly how this tag works, my only hope would be that a way could be found to make it not throw an HTML error, for example if it could be made to work using CSS, and something like: class="ipsnoembed"

I have found that on my site it only does this on the Pages app category links that I cut and paste into a forum post...when I do so, this gets inserted: ipsnoembed="true" Can you tell me more about where this ipsnoembed is coming from, and why it might get inserted?

I am testing one more type of link here:

Before going this route, I am running a simple test here. I have cut and pasted a link in your top menu using the right click "copy" and then pasted it here: https://invisioncommunity.com/news/ When I looked at it in "view source" I don't see the embedded code. I suspect this must be coming from my drop down menu plugin and will look into this possibility first, and let you know what I find out. Test #2: https://invisioncommunity.com/files/

If I share even simple internal site links in posts in my forum this gets embedded: ipsnoembed="true" The problem is that it throws an HTML error in the W3 validator: https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.celiac.com%2Fforums%2Ftopic%2F157160-easy-gluten-free-pizza%2F%23comment-1101054 Is there a reason for using ipsnoembed="true", and if so a way to fix the errors?

I agree that it would be much better to restore the ability to edit CSS templates.

After re-reading all Google blog posts on site speed as a ranking factor there is zero evidence that they are using a simple pass/fail for their core web vitals in their algorithm (perhaps they were initially when they first began ranking for site speed), and there is a lot of evidence from SEO companies who study this in great detail and compare thousands of Web sites and their rankings that they are indeed using the 0-100 score as a ranking factor. Why would Google's speed tools go into incredible detail and provide 6 separate speed categories with tons of links for how to fix each speed issue that your site has if they were not incorporating such things directly in their algorithm for ranking? Why do you think they use the standard red, yellow and green rankings for each of these categories? Google has clearly spent a great deal of time creating tools to help you speed up your site incrementally, 1% at a time, and according to SEO companies like SEM Rush and others, every little bit of speed gained will help increase your rankings. In fact, I've never seen an article on site speed ranking from a reputable SEO company that says that all you need to do is pass the core web vitals--51% is fine, and you don't need to aim for a 90% or higher score.

A quick update, on my test site simply stripping scrolling="no" eliminated the errors, and the posts function correctly.

Actually replacing scrolling="no with: data-controller="core.front.core.autoSizeIframe" seems to work without downsides....please let me know.

I did a small test, and it seems that simply removing: scrolling="no seems to eliminate the errors, and I see no downside to this approach. Do you have any concerns with using this approach?

I understand that IPB is unable or unwilling to deliver proper site speed, which is why I and others have handled this on our own. This thread, as you may recall, was created because you've now stripped those of us who actually care about this issue of the ability to upgrade our sites on our own and make them faster...why would you do this? So far I've not gotten a reasonable response about why you've stripped away the ability to edit all CSS from those who use that tool. What is next, stripping out ability to modify the templates?

That is too bad, as I've got such posts everywhere in my site, and such errors are bad for SEO.

I have updated my site to 4.7, yet the scrolling="no" is still present, and the error is still there: https://validator.w3.org/nu/?doc=https%3A%2F%2Fwww.celiac.com%2Fforums%2Ftopic%2F157194-long-haul-covid-from-celiac-disease%2F A look at view source for: https://www.celiac.com/forums/topic/157194-long-haul-covid-from-celiac-disease/#comment-1100737 Shows: <iframe allowfullscreen="" class="ipsEmbed_finishedLoading" data-embedauthorid="28795" data-embedcontent="" data-embedid="embed1807498815" scrolling="no" src="https://www.celiac.com/applications/core/interface/index.html" style="overflow: hidden; height: 400px; max-width: 502px;" data-embed-src="https://www.celiac.com/articles.html/no-greater-risk-of-covid-19-or-severe-covid-19-in-celiac-disease-patients-r5863/?do=embed"></iframe>

I recently upgraded to 4.7 and noticed that your dropdown menu plugin now says that it isn't compatible with 4.7, however, it appears to be functioning in 4.7, so perhaps IPB automatically flags all plugins as non-compatible until the author checks off that their plugin is compatible? In any case, do you know when the existing version will be marked as compatible, or an updated version will be available?

I recently upgraded to 4.7 and noticed that several of your plugins that I run now say they are not compatible with 4.7, including: SuperBlocks 1.2.0 Enhanced Forum Views 1.4.1 SuperTopics 1.1.0 SuperGrid 3.2.0 Each one appears to be functioning in 4.7, so perhaps IPB automatically flags all plugins as non-compatible until the author checks off that their plugin is compatible? In any case, do you know when those plugins will be marked as compatible, or an updated version will be available?

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.

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?