WP-Polls

Check Settings -> Header That Contains The IP . If it names a header such as HTTP_X_FORWARDED_FOR, make sure the proxy in front of WordPress always overwrites that header. Anything a visitor can set themselves can be changed on every request, and WP-Polls has no way to tell a real proxy from a forged header.

Before 3.0.0 WP-Polls also used the entire header value as the voter’s identity. X-Forwarded-For is a list, client, proxy1, proxy2 , so a visitor could append one more entry and count as somebody new. It now reads only the first address in the list.

If you are not behind a proxy, leave the setting blank.

WordPress is behind a proxy or a CDN and every request reaches it from the proxy’s address. Name the header your proxy sets under Settings -> Header That Contains The IP — HTTP_CF_CONNECTING_IP for Cloudflare — or, to trust the usual set of proxy headers without naming one, add this to wp-config.php :

define( 'WP_POLLS_TRUST_PROXY', true );

Sites that need to decide per request can use the wp_polls_trust_proxy filter, which defaults to that constant.

That is deliberate and unchanged: WP-Polls stores wp_hash() of the address, so the logs can tell two voters apart without keeping their IP addresses.

3.0.0 rebuilt the poll bar. It used to be one <div class="pollbar"> sized by an inline width; it is now a track holding a fill:

<div class="wp-polls-bar" aria-hidden="true"><div class="wp-polls-bar-fill" style="width: 42%;"></div></div>

The Result Body and Result Body (Voted) templates are rewritten to that markup on upgrade, including customised ones . There was no way to keep them: the class names and the stylesheet changed with the markup, so a customised copy of the old template would have rendered a bar with no rules left to match it. Re-apply your changes on the Templates tab, keeping the two wp-polls-bar elements.

If you re-add a bar by hand, use %POLL_ANSWER_PERCENTAGE% for the width. %POLL_ANSWER_IMAGEWIDTH% was removed in 3.0.0 and is no longer substituted, so a template still containing it emits the literal token into the style attribute and the bar renders with no width at all.

If your theme ships its own wp-polls.css , the bar rules are not in it — they used to be generated by PHP into an inline <style> block, and they now live in the plugin’s stylesheet. Either copy the .wp-polls-bar rules across, or delete your copy and override these instead, which is the supported way now:

.wp-polls { --wp-polls-bar-height: 8px; --wp-polls-bar-background: #d8e1eb; --wp-polls-bar-border: #c8c8c8; --wp-polls-bar-radius: 3px; }

It is because of rounding issues. To make it always round up to 100%, the last poll’s answer will get the remainding percentage added to it. To enable this feature, add this to your theme’s functions.php: add_filter( 'wp_polls_round_percentage', '__return_true' );

The stylesheet and the voting script load only on pages that show a poll, a polls archive or the poll widget; a page without one carries neither. WP-Polls will load wp-polls.css from your theme’s directory if it exists. If it does not exist, it loads the css/wp-polls.css that ships with WP-Polls. This will allow you to upgrade WP-Polls without worrying about overwriting your polls styles that you have created. A theme copy made before 3.0.0 has no poll bar rules in it, because they used to be generated by PHP. See My poll bars lost their styling above.

The head pass looks for the poll widget, a [poll] or [page_polls] shortcode and the two blocks, and anything rendering after it — a template tag, a poll in a loop page — asks for the assets as it renders and gets them from the footer.

Neither reaches poll markup fetched over admin-ajax.php or the REST API into a page that itself shows no poll: the fetch has no footer to enqueue into, and the page carried nothing for the head to find. The symptom is a poll that will not vote, under a “Loading …” that never goes away.

Say so from the page that will hold the poll:

add_filter( 'wp_polls_needs_assets', '__return_true' );

Anywhere the poll can be predicted this early will do. Code that already runs later in the page — a the_content filter inserting a placeholder, say — can call WP_Polls_Display::request_assets() instead, which is the same request the render paths make and is picked up by the footer pass.

Courtesy Of TreedBox.com Set --wp-polls-bar-background on the answer rather than styling the bar itself. The bar reads that custom property, so this works whichever poll bar style is configured, and it keeps working if the markup changes again. Add to the end of your wp-polls.css : .wp-polls-ul li:nth-child(01) { --wp-polls-bar-background: #8fa0c5; } .wp-polls-ul li:nth-child(02) { --wp-polls-bar-background: #ffff88; } .wp-polls-ul li:nth-child(03) { --wp-polls-bar-background: #ff8a3b; } .wp-polls-ul li:nth-child(04) { --wp-polls-bar-background: #a61e2a; } .wp-polls-ul li:nth-child(05) { --wp-polls-bar-background: #4ebbff; } .wp-polls-ul li:nth-child(06) { --wp-polls-bar-background: #fbca54; } .wp-polls-ul li:nth-child(07) { --wp-polls-bar-background: #aad34f; } .wp-polls-ul li:nth-child(08) { --wp-polls-bar-background: #66cc9a; } .wp-polls-ul li:nth-child(09) { --wp-polls-bar-background: #98cbcb; } .wp-polls-ul li:nth-child(10) { --wp-polls-bar-background: #a67c52; } .wp-polls-ul li:hover { --wp-polls-bar-background: #ff0000; } .wp-polls .wp-polls-bar-fill { transition: background-color 0.7s ease-in-out; } Before 3.0.0 this was written against .pollbar , the single element the bar used to be. That class no longer exists, so the old snippet colours nothing.