Quick & dirty hack would be to hide the button block via CSS. You can target it specifically for the user page only like this:
div.matchinfo:not(.input) .buttonblock {
display: none;
}
A ‘cleaner’ way would be to only output the button on the prediction form, but this requires some extra coding (and understanding of how filters in WordPress work). The prediction form filters have an argument $is_user_page as you can see in the second link of this example. You can use it to make a difference in the HTML template (the example does this), or in the template parameters (these parameters define the values that are used in the %placeholders% in the templates). In your case I would opt for the params. Because then you can combine a check to only show the button for matches that are still editable and when you are not on the user page.
p.s. there is also an auto-save option in the plugin settings. That one uses automatic AJAX calls on every change on the form.
Thread Starter
bruine
(@bruine)
Goodmorning Antoine,
Option 1:
div.matchinfo:not(.input) .buttonblock { display: none; }
Worked for me. Many thanks.
Option 2:
Needs more time for me. Somehow it didn’t work for me after activating this Plugin.
Maybe I have conflict somewhere. I will look in to this later.
I have to understand and find this first:
You can use it to make a difference in the HTML template (the example does this), or in the template parameters (these parameters define the values that are used in the %placeholders% in the templates
Option 3:
Wow. Didnt see this option. This also worked.
Is this option a reliable option ?
Finding: Using a Phone and Laptop I have seen items not changing.
But maybe because I was online with 2 devices. Sorry for that.
Regards, Edwin
Regarding 3: Because it is an asynchronous save there is always a possibility that something goes wrong without the user noticing it. Especially on slow connections the save might take longer than expected. Or something goes wrong and the user clicks away thinking it saved successfully before checking the result. There are some visual indicators during the save, but still, they can miss it. So, if they want to be absolutely sure, then they have to double check when this option is activated.
Using multiple devices should not make a difference. There might be race conditions (which request is handled first?), but I can see no reason why someone would want to do that. And if it then goes wrong, well, it is their own predictions that they are messing with 😉
The save button is less error-prone because the feedback to the user is more direct.