Some folks have said they can not rate a post as 5 stars, that it only allows them to rate 4 stars max. On the newest Fedora with FireFox, when I click the 5th star (to rate a post), it presents the little red square that pulsates...meaning it's processing the request. However, the little red square never goes away. If I give it a few minutes and back out of the page and go back in, it shows that the post was rated 5 stars as expected.

On Fedora, rating 4 stars works as expected. It doesn't show the red square and immediately shows 4 stars rated. Same with 3 stars rating and less. It rates and shows the star rating immediately and correctly with any rating less than 5.

I believe what the folks are saying is that when rating 5 stars on mobile or desktop, it never completes, so they have to rate a post 4 stars, because that will complete.

I'm still on 10.0.32 until I can get better WiFi and Beer ;)

 
 

Hi,

Likely it's an issue sending out a 'like' notification.

I tested locally and DID find a problem, but it only happens on development mode.

Try replacing RATING_FORM.tpl from the hot-fix in here 0004461: Issues with ratings - Composr CMS feature tracker.

Otherwise, see if there's anything in the Composr error log please, the browser's error console, and if you can, anything weird in the network tab of the browser's tools for the AJAX request (I think this video covers how to do that ).

I replaced RATING_FORM.tpl
I think ultimately I'll need to replace global.css to stop the sliding stars issue, but that's no biggie. I can say for sure that the sliding stars css thing isn't tricking out the mouse clicks. Once you hover over the stars and they slide a bit, they do settle down, and clicking on any of the 5 stars does tell the system specifically which star was clicked. So that part's okay.

Nothing in the servers root error.txt file about it. (except my own coding errors on recent php stuff)
Composr's error file (Admin) says nothing about it. (except my own coding errors on recent php stuff)
Email log shows notifications are going out immediately. (going to business class server last summer solved all of our throttling issues with email)

On the errors inspection, here's a snippet from that which may or may not have value. The stuff about feed_1 and feed_2 is *probably* related to my home made rss feed grabber. *probably*



In the Network tab, I took a screenshot and edited in a big red dot to show where the action is. I believe clicking the 5th star does immediately "work" because the notification email is sent out and the Network tab seems to indicate this too. But the little red square never goes away. After the site slows down a bit, I'll change to the default theme and see if this might be something I introduced in my custom theme. I'll also do the update to 10.0.33 and see if that helps. I'll attach the screenshot of the Network activity. The long load times are not Composr's fault...I'm on a slow WiFi.

Regarding global.css, just adding this to your theme's version will stop the stars bumping about…

I'll try and respond to the rest of your post in a separate reply.

Malatesa said

I replaced RATING_FORM.tpl
I think ultimately I'll need to replace global.css to stop the sliding stars issue, but that's no biggie. I can say for sure that the sliding stars css thing isn't tricking out the mouse clicks. Once you hover over the stars and they slide a bit, they do settle down, and clicking on any of the 5 stars does tell the system specifically which star was clicked. So that part's okay.

Nothing in the servers root error.txt file about it. (except my own coding errors on recent php stuff)
Composr's error file (Admin) says nothing about it. (except my own coding errors on recent php stuff)
Email log shows notifications are going out immediately. (going to business class server last summer solved all of our throttling issues with email)

On the errors inspection, here's a snippet from that which may or may not have value. The stuff about feed_1 and feed_2 is *probably* related to my home made rss feed grabber. *probably*

console

Cookie “client_time” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read Set-Cookie header - HTTP | MDN global_ssl.js:219:323
Cookie “client_time_ref” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read Set-Cookie header - HTTP | MDN global_ssl.js:219:323
Cookie “feed_0” has been rejected because it is already expired. index.php
Cookie “feed_1” has been rejected because it is already expired. index.php
Cookie “feed_2” has been rejected because it is already expired. index.php
Cookie “feed_3” has been rejected because it is already expired. index.php
Cookie “feed_4” has been rejected because it is already expired. index.php
Cookie “feed_5” has been rejected because it is already expired. index.php
Cookie “feed_6” has been rejected because it is already expired. index.php
Cookie “feed_7” has been rejected because it is already expired. index.php
Cookie “feed_8” has been rejected because it is already expired. index.php
Cookie “feed_9” has been rejected because it is already expired. index.php
Some cookies are misusing the recommended “SameSite“ attribute 12
Cookie “feed_0” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read Set-Cookie header - HTTP | MDN index.php

In the Network tab, I took a screenshot and edited in a big red dot to show where the action is. I believe clicking the 5th star does immediately "work" because the notification email is sent out and the Network tab seems to indicate this too. But the little red square never goes away. After the site slows down a bit, I'll change to the default theme and see if this might be something I introduced in my custom theme. I'll also do the update to 10.0.33 and see if that helps. I'll attach the screenshot of the Network activity. The long load times are not Composr's fault...I'm on a slow WiFi.

From “Post #7326”, 8th Oct 2022

I just registered on your site as ChrisGraham. I can see the issue, the AJAX request just stalls, as per your own screenshot.

I have a theory that the PHP Simple XML extension on the server may be corrupt and causing PHP to crash. It's used by this particular AJAX hook and sometimes PHP extensions can cause issues.

Would you like to make my user an admin so I can run some further tests on this? I can probably get it solved pretty quick, but right now I'm just guessing.

You're Admin. Let me know if you need access to the server and I'll make it so. We have auto-backups on everything, so if something blows up, it's okay, everything is fixable.

Okay, I think I have fixed this.

This was one of the hardest issues I've ever tried to fix in my life   .

What is happening is, your server is running HTTP/2, which uses multiplexed connection handling. That is, a connection stays open and multiple HTTP requests are piped through it. However, this connection deteriorates, and becomes 1-way only. The web page can make a request to the server, which fully runs (it's actually in the Apache logs as a normal completed request), but the result never gets back to the web browser.

As the rating is an HTTP POST request - that is, a request that changes data - the browser cannot do an auto-retry in case it double-actions (and it would). So it just stalls forever.

And this is only for JavaScript requests (AJAX) - a normal web page HTTP request would go through fine as it would start a new connection rather than multiplexing.

Actually this problem was very intermittent. It's not related to how many stars, or where the topic is, but more to do with exactly when you click the rating button compared to when the last HTTP request happened.

I have solved it (hopefully!) by adding a new hidden option that primes the multiplexed connection by loading a blank image of the server immediately, and once that loads, it then does the request.

I just got home. Thank you so much Chris! If it works, it works, otherwise we'll let it eventually hash itself out over time. I know what you mean about evasive problems. Back in the day of sneaking into the CSU lab late at night and hacking on the PDP 11/45 and cyber 760 to access arpa, we called those kinds of fixes a kludge. Until there's a better approach to an unpredictable condition, we'd hack a kludge. I don't know if there's any connection to this issue AJAX issue and an issue I had with the Composr chat room (which has been resolved with my own kludge) where the system would report people have left the chat room when they actually were still there. Anyway, thanks very much.
 

Oh cool, would have loved to play on PDPs and arpanet, I'm too young for that stuff.

This hot-fix will fix the chat issue: 0004468: Chat keeps saying user left room - Composr CMS feature tracker