jardokraka

v1.74 has fixed the issue for me. Thanks, developer.

Not working for me either.

Unfortunately, this solution doesn’t work for me, pls see my report here.

johnnybang, there is no way of contacting you through here on www.remarpro.com. Please do provide details, thanks in advance.

Also, shouldn’t users be allowed to change/update their vote?

When this function performs correctly, if I cast a vote, I can’t change my mind later on (can’t vote more than once). Updating your vote shouldn’t count as a separate vote, I would suppose.

Having the same issue. I am trying to use the ‘logged by username’ logging method, and only registered users are allowed to vote.

Issue: users are able to vote again when the page is refreshed.

The solution posted here doesn’t seem to work for me, the issue persists.

If I switch to ‘logged by cookie’, things work as expected, but that’s not a reliable method.

Latest WP version, tested in the current versions of FF and Chrome.

Not a stupid question at all, it turns out :).

Yes it’s a static frontpage, and comments were open on it.

Thanks again, I’m all good now.

I updated to v2.2, thanks. The plugin still loads the files listed above on the frontpage (is_front_page) which it probably shouldn’t. It doesn’t load the files on the homepage (is_home) though.

The plugin loads these files on all pages, not just where there are open comments:

wp-includes/js/quicktags.min.js?ver=3.5.1
wp-content/plugins/basic-comment-quicktags/quicktags.js?ver=1.8
wp-content/plugins/basic-comment-quicktags/quicktags.css?ver=2.0

This worked great, thank you very much.

Exactly. Ability to display the submitted comment without refreshing the page is the only thing missing.

Could you please add this functionality?

Thank you very much for your work on this plugin.

@philippetrov — thank you very much.

I second this request, very much.

And, thank you very much for your work on this plugin.

Steve,

Thank you very much for these additions. This is definitely a step in the right direction.

Let me explain what I’m trying to accomplish. Since there’s no option in the admin to specify which months are to be displayed on the website, I can use css to hide the months I don’t need:

div.wp-availability-month {
	display: none;
}

div.wp-availability-month.month-previous,
div.wp-availability-month.month-current,
div.wp-availability-month.month-next {
	display: block;
}

Now that I’ve gotten around to actually implementing it (it works great, thank you yet again!), it has occured to me that it makes much more sense (in my particular use case) to display just the current month and several months ahead (what’s the point of showing past months?).

Perhaps you could add month-next-1 (for the month after the next one) and month-next-2 (and maybe so forth)? Perhaps you could come up with a better naming convention.

Ideally I’d expect this to be configurable through the plugin settings, as right now I’m just hiding unneeded div’s via css, but they’re still in the code; on the other hand, this is such a lightweight plugin with no bloat, and that’s good. Just a little bit more flexibility would make it perfect, imo.

While we’re at it, I have a question. It’s November now, and I have a suspicion that when it’s December soon, only one month will be displayed (as it’s the only one remaining for this year), requiring me to switch to year 2013 to be able to see availability for Jan 2012. Is that so?

I am trying to find a way to display availability for a period a few months ahead, so that, say, 3-4 concurrent months are displayed at all times — the current one plus a a few more.

That is to say, in December I would like to be able to show December 2012, Jan 2013, Feb 2013, and maybe March 2013.

Again, thank you very, very much.

having the same problem with autopublishing and granting extended permissions to SFC on the plugin settings page. both ‘User ID and Access Token found!’ and ‘Application Access Token found!’ are green.