Can this be used for members/subscribers only?

Hi @jhebbel,

there is a different type of giveaway where only logged-in users can enter.

For now, there is no other way but I will note your questions as feature requests for future versions.

I’ll expand on the second question a bit so you can understand my feature request fully. Users are able to donate money to the software I write and my site applies a role to those who do that give them things such as forum badges and early access to alpha builds. I have 2 levels and roles for each, donor and elite donor. I would also like this to be able to give extra submissions to these roles.

Is there a hook at the time the user enters the giveaway that I can attach to in my own code and modify the number or entries applied depending on the users role?

I see the “giveasap_register_user” action, so my guess is I would hook that, but unfortunately you operate on email and not user ID (which is regrettable as emails can change, user ID’s don’t, not to mention DB and cache is performance is better when doing lookups by ID), so I would take the email from that hook and use giveasap_get_user_by_email to get the user ID, then with that do my own checks to determine if the user warrants any additional entries then call giveasap_update_user_entry and +1 the entries remembered from giveasap_register_user.

Does this stand up to basic sanity checks?

Also, a filter here on giveasap_register_user prior to the DB actions would simplify this a great deal and probibly also simplify your implementations as well. I added the following, to simplify my plan:

if(has_filter('giveasap_get_base_number_entries')) {
	$entry = apply_filters( 'giveasap_get_base_number_entries', $entry, $giveaway_id, $email, $ref_id )
}

• This reply was modified 6 years ago by jhebbel.
• This reply was modified 6 years ago by jhebbel.
• This reply was modified 6 years ago by jhebbel.

Sorry to keep beating on this thread, but going over some of the code I have found a lot of instance where you aren’t using a lot of the functionality of WP, in many instance you are using the DB directly instead of going through wordpress provided functions that take advantage of additional caching like object based caching.

For instance giveasap_get_user_by_email should make use of get_user_by( 'email', $email ); then revert to the DB operation if the user is not a registered user but instead a basic email entry.

Hi @jhebbel,

the function giveasap_get_user_by_email should not be using get_user_by since we are checking a separate table of entries (people who entered a giveaway). We are getting a user from that table (a subscriber) and not a user from the WordPress users database.

That’s another thing, this all should be using meta and not direct DB access to again, take advantage of people’s various object caching plugins. Not to mention using full statements with wpdb opens you up to SQL injection vulnerabilities.

I have 95k users, I just hope this can scale nicely without bringing my site to it’s knees.

Hi @jhebbel,

it used postmeta at first. I’ve changed it to a separate table so it scales better and does not make the postmeta table bigger since that table is already used for a lot of data. Also, when storing that into a postmeta row, you need to get that data, update it with a new subscriber and save it again. If there are more than 1 subscription at the same time, some data might be lost.

Also, additional data can be stored into a separate meta table for each subscriber which helps with data management and collection.

The SQL statements are prepared before being processed.

If you’re questioning this plugin and you think it should not be coded as it is, feel free to use a different one. People have run giveaways for thousands of users without any issues so far. I guess it should be fine handling yours also.

Also, since this plugin is using separate tables, it won’t slow your site due to postmeta slow queries.

Unfortunately since you bypass all caching by interacting with the DB directly, it doesn’t scale better, in fact it even has a hard limit due to most SQL imposing hard limits on result sizes to avoid memory issues and DoS, ive run into this issue in other plugins as well, and the meta used should be user meta, not post meta, meaning there should be no locking issues.
I did not see the wpdb->prepare in there at first, so I guess it is safe from injection.

As you well know, you are the only giveaway plugin in town and I dont have the time to write one ground up, hence my usage of wordpress to begin with as I would much rather be using Drupal.

Nothing personal, caching is just a major thing I have to account for when choosing plugins due to the traffic I have to deal with.

• This reply was modified 6 years ago by jhebbel.

With all due respect, you can still cache the requests with OP Cache, but just like Woo-Commerce coupons, you are still going to make unique calls and requests to the db, so it is fine for scaling when you host WordPress in large environments like I do, which receive 25,000 to 250,000 users per day.

I use dedicated cloud storage blocks that can be cloned and attached to auto-scaled servers with dedicated database servers. The database is 16gb.

I have scaled WordPress Woo-Commerce sites receiving thousands of orders an hour, in which that you cannot cache many things, and it was very scalable.

That is subjective to the planner and the planner’s budget.

• This reply was modified 5 years, 11 months ago by jasonbrogdon.

I’ve already gone through modifying it so now it operates off of user and post meta and now takes advantage of full object caching. It has sped the plugin times up a fair amount especially when I want more complex queries like showing user what giveaways they are entered in in their profile etc, unfortunately it also means I am painted into a corner as far as updating though.