bseddon

The issues with disabling a rating on a post and the columns in the post list in the backend appear to be addressed.

I am seeing a new problem in the new ‘stars.php’ file. The error log reports:

PHP Notice: Undefined variable: itemParticipants in stars.php on line 170

The variable is used before it is assigned. I’ve made the assumption it is OK to initialize the variable to an empty string before the preceding for-loop.

Another pre-existing problem exists in ‘google_rich_snippets.php’. I sometimes see errors in the log because the global $post variable is not assigned. As a result the call to $post->ID fails.

My fix has been to add the following line immediately after ‘global $post’:

if (!isset($post->ID)) return;

I’m sorry if I missed your documentation showing how to add your plugin to other post types.

Because I could not find the documentation I thought it would be useful to others to know how your plugin can be used to add ratings to their own custom posts or the custom posts of other plugins. Of course, maybe I’m the only person who uses custom post types.

If I was an idiot and missed the documentation, please post a link here.

Have you looked at how the Mage Rating plugin allows a user to select the post types it will support? It uses a plugin settings page to present the registered post types and allows the administrator to select one or more post types.

OK, I get it. It works only if you use the WordPress comment template. If another template is used it’s necessary to ensure the template calls the actions

‘comment_form_logged_in_after’ or
‘comment_form_after_fields’

It would be really helpful to note this in the documentation as the three step installation guide is a little misleading. That is, unless you have a default WordPress installation and use one of the themes included with WordPress or other theme that calls comment_form() in its comment template.

The software licensing extension to EDD is really only for WordPress plugins. It pays lip service to other types of software but apart from exposing an API that any software could call doesn’t really support anything other than WordPress.

In our scenario we sell client software. Clients can buy single use licenses, they can by corporate unlimited use licenses. They can pay annually or buy a perpetual license. They can request a trial. Each of these is a ‘feature’ that we can attach to any download. However, the same download may be a trial for one user or a perpetual license for another. So we want the ability to have the ‘features’ attached to the license so we are able to vary them by license (and we’ve created a plugin to do that). However we want to initialize the license by copying features from the download to the license.

So we have a choice. We can use an existing plugin which already offers the ability to attach features to a download or roll our own. It seemed rational to choose an existing plugin.

But our rationale is not really relevant. What I’m trying to do is illustrate that in a scenario we’ve encountered and have tried to describe, there is a problem. My scenario is a little more obscure. But what if I want to include the features in my PDF receipt so the buyer can see what they purchased. The same problem occurs and for the same reason.

We have a solution because we can edit your taxonomy.php file and change the taxonomy registration priority. But next time the download info plugin is updated we lose that change and run the risk that we introduce an error unless we remember to make the change.

If you can’t see the need to make the change, that’s OK. But please let me know so we know to merge your plugin into our own so we can avoid future issues.

<<I’m not sure is it about purchase process.>>

OK, i was not being precise and simply recommending a change because we experience a conflict and know the cause (because we spent many hours studying it) and how it can be solved.

You can review a detailed description of the problem and why a change to the priority of the features taxonomy registration is a solution here:

https://easydigitaldownloads.com/support/topic/edd-actions-have-no-defined-priority/#post-86028

Here’s a summary. The EDD ‘edd_complete_payment’ action causes the EDD Software Licensing ‘store_licence’ to fire and it’s this action we hook to copy feature definitions from the download to the license.

Ulimately ‘edd_complete_payment’ occurs because ‘edd_post_actions’ is registered as an action with a default priority. Because EDD uses a default priority and you use a default priority WordPress runs the actions in the order they are registered. EDD wins because it comes before your plugin alphabetically. The result is that by the time our code is run, your taxonomy is not registered.

This issue has nothing to do with post types or custom taxonomies but about the action hooks and priorities you and Pippin have chosen to use. I can see that you would both think that choosing ‘init’ as the action and using a default priority is a reasonable thing to do. However I represent a scenario in which that reasonable assumption is tested.

Yes, or some other mechanism to ensure the taxonomy is registered before the purchase process is run. I raised the issue on Pippin’s forum first to suggest he uses a priority like 100 to give other EDD plugins like yours chance to run. He was not so keen and correctly observed that it’s not really a general solution (though it would work in this case).