sadams101

Things have gotten back to normal after 3-4 days of this strange traffic anomaly. I'm not sure if this issue was related to the upgrade or not, but it did begin right after the upgrade. The traffic drop was for my forum only, which normally has 7-10 times the traffic of my Pages app--for those days it was basically even 50/50 traffic between my forum and Pages apps.

Yesterday I updated to v4.7.15, and since then I've seen what appears to be a ~50% traffic drop in my forum app. At the moment it is hard for me to tell if this drop is real, or perhaps due to a change to the Online Users by App that I don't see listed in the change notes. In summary, until I upgraded yesterday my Online Users by App shows my forum visitors dropping a huge amount, to where they are now below the level of my site's Pages app. To me this seems like an impossible drop, given that 90%+ of my site's total content is within our forums. I am wondering if anyone else who upgraded has seen a similar drop in forum traffic, whether this drop is real, and what in the update might have caused such a drop?

I hope to propose a code update on this issue, and better explain what exactly is going on. Below is the issue, and this is when you have "Enable record image upload" on in the ACP (/admin/?app=cms&module=databases&controller=databases&do=form&id=2). In the Pages app if an article has an image (using the "Choose single file..." button) uploaded and saved, a thumbnail is created which is displayed on the home page, and category pages within the Pages app. If you then need to edit this article later for any reason, for example if it was pinned and you want to unpin it, or if you want to lock the article, or simply edit any text within the article (all of these actions are very common for publishers), re-saving the article, even if you do not upload a new image, will result in the original thumbnail being deleted (removed), and a new thumbnail being created. For example, on my home page this was the URL of the article image: https://www.mysite.com/uploads/monthly_2023_12/Colored_quinoa_CC--Michael_Hermann.thumb.webp.b584800290f53b053cc6b6072b832864.webp I opened the article, changed some text and saved it, and now this is the URL of the image on my home page: https://www.mysite.com/uploads/monthly_2023_12/Colored_quinoa_CC--Michael_Hermann.thumb.webp.136b728972637cf0163400ddd264bc29.webp The old image was deleted, the new image was added. Why is this a problem? Lots of broken 404 image links, or any other 404 links on any website is considered poor SEO by Google and other search engines. Google Search Console instantly picks up these lost images and lists them as issues that need to be fixed. I edit many articles a day, and this results in lots of 404 Not Found flags. Solution, which I hope IPS will incorporate in a future update (I paid @DawPi for this fix, and he agreed to let me share it here), is a simple code change in this file: applications\cms\sources\Records\Records.php else { $imageUploads[] = $values['record_image']; $fixedFieldSettings = static::database()->fixed_field_settings; if ( isset( $fixedFieldSettings['record_image']['thumb_dims'] ) ) { if ( $this->record_image_thumb ) { try { \IPS\File::get( 'cms_Records', $this->record_image_thumb )->delete(); } catch ( \Exception $e ) { } } $thumb = $values['record_image']->thumbnail( 'cms_Records', $fixedFieldSettings['record_image']['thumb_dims'][0], $fixedFieldSettings['record_image']['thumb_dims'][1] ); } else { $thumb = $values['record_image']; } $this->record_image = (string)$values['record_image']; $this->record_image_thumb = (string)$thumb; } and replace it with this code: else { $imageUploads[] = $values['record_image']; $fixedFieldSettings = static::database()->fixed_field_settings; if ( isset( $fixedFieldSettings['record_image']['thumb_dims'] ) ) { /* By DawPi */ if( $this->record_image != (string) $values['record_image'] ) { if ( $this->record_image_thumb ) { try { \IPS\File::get( 'cms_Records', $this->record_image_thumb )->delete(); } catch ( \Exception $e ) { } } $thumb = $values['record_image']->thumbnail( 'cms_Records', $fixedFieldSettings['record_image']['thumb_dims'][0], $fixedFieldSettings['record_image']['thumb_dims'][1] ); } else { $thumb = $this->record_image_thumb; } /* END */ } else { $thumb = $values['record_image']; } $this->record_image = (string)$values['record_image']; $this->record_image_thumb = (string)$thumb; } After doing this the thumb image will only be update if you actually upload a new image to the article, not when you simply save it again for any other reason. This fix eliminates the many 404 Not Found image issues with Google Search Console.

I agree with your analysis--but I don't believe it's "looking for a needle in a haystack"--especially if you realize that the issue began within minutes of the last update. It's already been disclosed here that changes were made to the sitemap, which runs on the cron every 15 minutes. If that is the only change to the tasks in this last update, then that is the likely culprit. What is totally missing in the thread is for someone who who works for IPB and knows the details of the last update to simply read this thread, and quickly figure out what changes may have triggered this. Apparently that isn't going to happen.

I've thought about ways to determine the exact cause, however, the warnings I receive don't match up very closely with a specific task run time, which leads me to believe that the task that is triggering it may be hanging, or taking a while to finish. Is there no way to ask your development team which tasks might be affected by the last update? This might be a better way to narrow it down. Perhaps the sitemap is the only answer?

The cause would be limited to any task changes made in the last update. From what I've learned here the sitemap was changed. What other tasks had code changes in the last update?

A quick update--I shut down all custom applications and plugins on my test site (I am getting these notifications from both my test and live sites ever since the upgrade), but the excessive resource notifications continue from the test site, so I can confirm that they don't appear to be related to any mods that I've done. Since there were coding modifications done to the core sitemap in this update, is it possible that those changes might cause more memory use whenever the sitemap task runs?

This is a very simple fix, but since it is in the JS I'm unable to do it. Within the root_framework.js is this code: <a href='#' data-action='toggleQuote'> Can you please update it with this code: <a href='#' data-action='toggleQuote' aria-label='Toggle Quote'> I ask because my forum users quote very often, and the toggle throws an error each time...some of my forum pages have 5-10 quotes per page. Example of the issue:

I'll do more investigation to try to find out which task might be causing this and report what I find out. Perhaps others will also chime in here if they are having the same issue.

The emails do tell us something--especially if the upgrade made any changes at all in how these tasks are run, or if new tasks were added, or if other updates might somehow interfere with the processing of the tasks. Of course resource warnings can tell us something, otherwise server admins like myself would not be using them. As you know, this runs from the command line each minute, so there are tasks always running, I just am not able to pinpoint a specific task, based on comparing the times of the emails, to a specific task log entry. This does not mean that one of the tasks run isn't causing the resource issue, it just means I can't tell which one--but at least one of them is definitely triggering this, otherwise I would not be getting the warnings. There were other serious issues with this update, including a very basic HTML mistake in a template which still hasn't been fixed, so I'm not sure why you believe that the sudden resource warnings for tasks which started directly after I upgraded might not also be related to the update. This clearly has nothing to do with my server, and everything to do with the update.

Here are the search results for the emails mentioned. As you can see, I got 4 total in October. I upgraded my site on 11/5/2023 at around noon, and afterwards begin being bombarded by the warnings. I could not show all in November here, as they are cut off, but I've also increased my warning threshold to 1200MB to try to stop being flooded by them. I get the impression here that you don't believe that anything in your update could have caused this, but the evidence speaks otherwise. PS - I am the server admin, and nothing else has changed on the server.

I am not seeing anything that would explain this in my logs--there are about 11 errors over the past week, most relate to what appears to be the Twitter login method no longer working (do I need to make changes?). The other clue I have is that the email warning is sent at almost the same time each hour, around 47-48 minutes after the hour, but I don't see that time corresponding specifically to a task that might run at that time. When my server was set at 600MB for this warning I am receiving 30-40 warnings a day, after changing it to 1000MB I am still getting ~25 a day. Again this all started right after the my upgrade.

I recently upgraded from 4.7.13 to 4.7.14 and soon after my server began sending me "Excessive Resource" warnings--a couple of dozen per day, which the task exceeds 600MB. I know I can change the memory level on my server to a higher warning level to stop receiving them, but before doing so I wanted to mention this, and ask what with the recent update my cause this sudden change? Some of the warnings are also about excessive time to complete the process. Has anyone else noticed this?

I recently upgraded from 4.7.13 to 4.7.14 and soon after my server began sending me "Excessive Resource" warnings--a couple of dozen per day, which the task exceeds 600MB. I know I can change the memory level on my server to a higher warning level to stop receiving them, but before doing so I wanted to mention this, and ask what with the recent update my cause this sudden change? Some of the warnings are also about excessive time to complete the process. Has anyone else noticed this?

I just want to mention that the X logo was a white X, so it did not show up at all on the default white background my site uses. After changing it to black it worked.

After fixing this and clearing my cache, the Facebook logo is loading as the X logo, or the X logo is missing. <li class='cUserNav_icon'> The logo is in my resources, but for some reason is not loading properly. Any ideas on how to fix this?

Please also fix the missing alt tags on these images...something like this: {{if \IPS\Settings::i()->site_social_profiles AND $links = json_decode( \IPS\Settings::i()->site_social_profiles, TRUE ) AND \count( $links )}} {{foreach $links as $profile}} <li class='cUserNav_icon'> {{if $profile['value'] == 'x'}} <a href='{$profile['key']}' target='_blank' class='cShareLink cShareLink_x' rel='noopener noreferrer' alt='Visit Us On X'><img src="{resource="logos/x.svg" app="core" location="global"}" width='13' height='12' style='vertical-align: middle'></a> {{else}} <a href='{$profile['key']}' target='_blank' class='cShareLink cShareLink_{$profile['value']}' rel='noopener noreferrer' alt='Visit Us On {$profile['value']}'><i class='fa fa-{$profile['value']}'></i></a> {{endif}} </li> {{endforeach}} {{endif}}

Also, with the change in this template there were Accessibility errors introduced in Page Speed Insights. My score dropped from 90 to 85 with the new template due to these issue:

After upgrading my site from 4.7.13 to 4.7.14, my Twitter/X logo is now showing my Facebook logo--so there are two Facebook logos, one for Facebook and the other for Twitter/X. I noticed there were some template changes with this update, including this one: core → front → global → siteSocialProfiles {{if \IPS\Settings::i()->site_social_profiles AND $links = json_decode( \IPS\Settings::i()->site_social_profiles, TRUE ) AND \count( $links )}} {{foreach $links as $profile}} <a class='cUserNav_icon'> {{if $profile['value'] == 'x'}} <a href='{$profile['key']}' target='_blank' class='cShareLink cShareLink_x' rel='noopener noreferrer'><img src="{resource="logos/x.svg" app="core" location="global"}" width='13' height='12' style='vertical-align: middle'></a> {{else}} <a href='{$profile['key']}' target='_blank' class='cShareLink cShareLink_{$profile['value']}' rel='noopener noreferrer'><i class='fa fa-{$profile['value']}'></i></a> {{endif}} </li> {{endforeach}} {{endif}} Any idea on how I can fix this?

PS - I also noticed that the new svg logo is not included in the Schema.org info in the page source: <script type='application/ld+json'> { "@context": "http://www.schema.org", "logo": { "@type": "ImageObject", "@id": "https://www.mysite.com/#logo", "url": "https://www.mysite.com/uploads/monthly_2023_10/New_Forum_Logo-5.webp.8ae695e2618dfdw8ed62fbe09928af45.webp"

I am testing out the svg logo option after purchasing the app--do you have any sample code for the svg logo? I'm not 100% sure what needs to be inserted into the code area.

They won't be duplicate if the page number is added to the tags.

So I believe the much better solution to this would be to carry over the same meta tags and add "Page 2" or "Page 3", etc. Having no meta tags is not considered to be good SEO.

Do you know if there is a way with this plugin to only use the svg logo aspect, and not use the rest? For example, not use the style sheets day and night part?

Just FYI...and I can't say for sure that the upgrade mentioned above caused this issue, but the evidence I see points that way. Due to this causing, in my case, thousands of 404 not found links throughout my site (Google recorded 15K and counting, and it was going up daily since 7/21), which is just terrible for SEO and google ranking, I had @DawPi create a plugin that fixes the issue. I hope that IPB can look into this to determine if this might have been caused by the update mentioned. Sorry I could not wait for the ticket process, but others with the same issue may find this thread and offer some more support for this possibility.