This is a big PR originally meant to come with a way to generate a poll from existing posts type items (films, songs, places, etc.), as evoked in #155. It has been implemented here, but It eventually also comes with fixes, and other features.
Sorry for the fact that there has been no progressive commits to make it easier to follow the changes, but you will find summarized below the main changes & directions taken.
Also note that this PR has been tested successfully both on a fresh install and on an existing install with the limitations mentioned in the To-do section below.
Main changes
New features
New answer mode: objects (customizable fields related to one or several selected post types). It comes with the default basic design below (here with Twenty Twenty theme) but can of course easily be further customized using custom HTML with dedicated templates variables, CSS and/or PHP filters.
Templates Sets Library: instead of a single templates set for all polls, several templates sets can now be saved and associated with selected poll(s):
a poll can be associated with only one templates set.
function get_poll has a new optional parameter templates_set_id which says whether settings should be retrieved from:
by default, the default text template set, that is the current situation in which WP Polls had only a unique text template set : templates_set_id = 0
the templates set associated to a given group of polls : templates_set_id > 0
all templates sets (in particular it will use the global latest poll ID, instead of the latest poll ID of a template set group) : templates_set_id = -1
new function for devs: get_pollvotes_by_templates_set_id($templates_set_id) (sum of all polls' totalvotes associated to a given templates_set ID).
similarly poll archive can now be called with optional parameter $templates_set_id to display only archive of polls associated to a given templates set.
via PHP: polls_archive($templates_set_id)
via shortcode: [page_polls tpl_id=2] to retrieve for instance polls associated to templates set n°2 .
settings for templates set's specific archive are managed in the templates set's settings, contrary to the general archive settings which are can be partially configured in the General options.
Ability to hide vote results from visitor even after he/she has voted.
Partial UI reorganization
The Templates page is now a more sophisticated page inspired from the Manage Polls page. It manages addition, duplication and deletion of templates, as well as modification of templates' HTML code and options that are now saved in a dedicated table in the database (instead of the wp-options table) to allow templates set-specific settings.
The Options page has been repurposed (what was previously an option is now editable per template basis) and renamed 'General Options'.
Improvements
Consistent behavior of "cancel" button on the "Edit Poll" screen: when clicking the button "Remove Answer", the answers gets removed from the UI, but not anymore from the DB with AJAX. The DB removal process now only happens after submitting the modified Edit form. Consequently, pressing "cancel" and going back to the Edit form actually cancels all unsaved removals.
Preventing the 'Add Poll' and 'Edit Poll' forms from being submitted if they do not contain any question and/nor answer.
In case of form saving error (e.g. no poll question or no poll answers) on the Add Poll Page, the form content is not erased anymore, enabling the user to correct the form (without having to fill it again from scratch) and submit it again.
Limiting checkboxes selection in the UI to the number defined as maximum number of answers in the poll's settings. Note this is implemented via JS and will only works if the answers are contained in a div with the class wp-polls-ans with attribute data-ansmax set with value %POLL_MULTIPLE_ANS_MAX%. It is included in the vote template header of the updated default templates sets (both for text and object type).
Fixes
Fixed limitation of polls ID which would cause bugs from ID n°100 (3 figures) due to $poll_questions_ids = substr($poll_questions_ids, 0, -2); . It is now using array-based logic instead of a string-based one.
Fixed poll expiry timestamp which couldn't not be changed when adding a new poll.
Fixed malformed sprintf() command in polls-add.php responsible for disclosing the shortcode after poll creation.
Fixed warnings due to undefined variables on polls-logs.php
Other minor fixes done on the way and not listed.
Tested for backward compatibility as well as for fresh install.
Previous features remain available. This PR only comes as an extension.
Previous features remain the default choices, and nothing would change in the front-end after udpating WP-Polls from a previous version. Existing configuration (templates and options) will be converted to the default templates set.
Successfully tested on last WP version 6.5.2 (it should be compatible with earlier versions as it makes no use of recent WP functions & features).
Minimum PHP version = 7.4 due to the use of certain features like the coalescent operator.
Update from WP-Polls v.2.77.2 works and takes care of the full migration process.
Fresh install works.
Development's directions:
This PR has been mostly built following the plugin's original coding style and organization for consistency purpose.
2 new tables created in the DB (pollsaof to save answers object fields associated to each poll with object answers, and pollstpl to save templates sets)
a few new entries / modifications in existing tables (e.g. the 'answer type' value which can be either text or object) coming together with a proper migration mechanism from previous plugin's version.
Migration of most options (that used to be accessed via get_option()) to table pollstpl. The array retrieved with get_option('poll_options') has been internally modified but kept as the place to store the 'General Options' settings. Its subkeys (i.e. former options key retrieved with get_option()) are now to be retrieved using the helper wp_polls_get_child_option($subkey).
Some of the existing code as well as the new code has been modularized into new additional PHP and JS helper functions to avoid duplication and makes maintenance a bit easier (a small percentage of the whole code though).
poll_scripts() has been split in 2 functions ( and ):
poll_scripts() with the key static content which is fine being loaded at wp_enqueue_scripts.
poll_templates_scripts() with dynamic content which must be loaded at wp_footer so that $templates_sets_loaded global variable has time to be correctly populated.
Note that everything could have been fired as a single function at wp_footer but as it is a template-dependant hook (although "fairly widely supported"), the rationale behind the split is that it may be more resilient to have the mandatory content for the plugin to work fired at wp_enqueue_scripts (theme-independant hook). That way, even if a theme wasn't supporting the wp_footer hook, the plugin would still work (even if slightly degraded in terms of style).
To-do
[ ] Version number in wp-polls.php was set to 3.00.0 (you might want to change this).
[ ] Readme in the repo has not been updated
[ ] Migration tests:
After upgrade the plugin needs to be desactivated & reactivated so that it perform the new DB upgrades in polls_activate(). New code base with old DB structures will result in errors displayed. Also if the admin tries to uninstall the plugin, he/she will get a message saying it is impossible to remove (due to uninstall.php trying to remove new DB tables that were never created so far). Should plugin desactivation at upgrade be forced (say at plugins_loaded hook for instance), calling for manual reactivation by admin ?
if bulk update via the catalog, plugin is not desactivated. Take additional measures?
if manual single upgrade using a zip file, plugin is not desactivated. Take additional measures?
if auto update via the catalog, plugin is not desactivated. Take additional measures, knowing however that this is most likely unattended by the site admin ?
I was not able to test the widget, since that feature appears to be broken already in 2.77.2 (the poll widget won't get saved after pressing "save"). I did not spend time to fix the widget system.
[ ] Translations will need to be updated as the PR comes with new or modified strings.
This is a big PR originally meant to come with a way to generate a poll from existing posts type items (films, songs, places, etc.), as evoked in #155. It has been implemented here, but It eventually also comes with fixes, and other features. Sorry for the fact that there has been no progressive commits to make it easier to follow the changes, but you will find summarized below the main changes & directions taken. Also note that this PR has been tested successfully both on a fresh install and on an existing install with the limitations mentioned in the To-do section below.
Main changes
New features
get_pollhas a new optional parametertemplates_set_idwhich says whether settings should be retrieved from:templates_set_id = 0templates_set_id > 0templates_set_id = -1get_pollvotes_by_templates_set_id($templates_set_id)(sum of all polls' totalvotes associated to a given templates_set ID).$templates_set_idto display only archive of polls associated to a given templates set.polls_archive($templates_set_id)[page_polls tpl_id=2]to retrieve for instance polls associated to templates set n°2 .Partial UI reorganization
wp-optionstable) to allow templates set-specific settings.Improvements
wp-polls-answith attributedata-ansmaxset with value%POLL_MULTIPLE_ANS_MAX%. It is included in the vote template header of the updated default templates sets (both for text and object type).Fixes
$poll_questions_ids = substr($poll_questions_ids, 0, -2);. It is now using array-based logic instead of a string-based one.sprintf()command in polls-add.php responsible for disclosing the shortcode after poll creation.Tested for backward compatibility as well as for fresh install.
Development's directions:
pollsaofto save answers object fields associated to each poll with object answers, andpollstplto save templates sets)textorobject) coming together with a proper migration mechanism from previous plugin's version.get_option()) to tablepollstpl. The array retrieved withget_option('poll_options')has been internally modified but kept as the place to store the 'General Options' settings. Its subkeys (i.e. former options key retrieved withget_option()) are now to be retrieved using the helperwp_polls_get_child_option($subkey).poll_scripts()has been split in 2 functions ( and ):poll_scripts()with the key static content which is fine being loaded atwp_enqueue_scripts.poll_templates_scripts()with dynamic content which must be loaded atwp_footerso that$templates_sets_loadedglobal variable has time to be correctly populated.wp_footerbut as it is a template-dependant hook (although "fairly widely supported"), the rationale behind the split is that it may be more resilient to have the mandatory content for the plugin to work fired atwp_enqueue_scripts(theme-independant hook). That way, even if a theme wasn't supporting thewp_footerhook, the plugin would still work (even if slightly degraded in terms of style).To-do
wp-polls.phpwas set to 3.00.0 (you might want to change this).polls_activate(). New code base with old DB structures will result in errors displayed. Also if the admin tries to uninstall the plugin, he/she will get a message saying it is impossible to remove (due touninstall.phptrying to remove new DB tables that were never created so far). Should plugin desactivation at upgrade be forced (say atplugins_loadedhook for instance), calling for manual reactivation by admin ?