Forum Replies Created
-
Posts
-
What we found was if PayPal had trouble communicating with their funding source it would send a message that was treated as a bounce and therefore end of subscription. You can ask your members if they have had any delays or “will try again in X days” messages from PayPal.
I just did this as well for the fancy shortcodes and thought I would share the CSS. I think I have all the codes correct now, but the style names are inconsistent, so just copying and changing the number did not work. Here is the code for up to 10 with everything sized to book cover ratio except for the black ones which are square, but obviously you can change the numbers however you like. The important is because I put it in the wp_eStore_custom_style.css and wanted to make sure it overrode the existing.
.thumb-image{
width:131px !important;
height:175px !important;
}
.eStore-category-fancy-thumbnail img {
width:131px !important;
height:175px !important;
}
.eStore-fancy3-thumb img {
width:131px !important;
height:175px !important;
}
.eStore-fancy4-thumb img {
width:150 !important;
height:150px !important;
}
.eStore-fancy5-thumb img {
width:131px !important;
height:175px !important;
}
.eStore_fancy6_thumbnail img {
width:131px !important;
height:175px !important;
}
.eStore-fancy7-thumb img {
width:131px !important;
height:175px !important;
}
.eStore-fancy8-thumb img {
width:131px !important;
height:175px !important;
}
.eStore-fancy9-thumb img {
width:131px !important;
height:175px !important;
}
.eStore-thumbnail-fancy-10 img {
width:131px !important;
height:175px !important;
}
A valid purchase is one that the eStore accepts and inserts into its database, as opposed to a valid IPN that contains an invalid purchase price (for whatever reason) and so is not entered in the eStore database but is passed on to 3rd Party applications.
Ideally, the above case of invalid purchase should send the admin a flag for the problem. Honestly, it would be grand if you could add a status flag into the IPN that you pass, preferably with the reason if something is declared INVALID. I wouldn’t use the IPN valid/invalid tag because it could generate errors if the 3rd Party was expecting a PayPal response there, but a new tag that we could look at would be a great enhancement.
That sounds like something I’d ask for
. So to clarify, we do know that it’s a valid PayPal IPN if it comes from the eStore, but not necessarily a valid purchase.Perfect.
Sorry for the delayed response. Just wanted to say the “Expire After Date” seems to solve the end of term issue. Thanks for the help.
Thanks, kodeexii. My client decided to turn off the caching software, but I’ll keep this solution in mind if that changes. Sorry for the late reply.
Great. I’m a firm believer in having the information necessary to troubleshoot problems quickly. I put mine in the db_access file (under insert, but having a catch for the error in each query would have value).
Well, I said that I, or my host, may have added the index to improve database performance. But since it’s a dead stop for a couple of your options, and hosting companies do sometimes attempt to help in this fashion, it’s worthwhile including a debug message containing the reason an insert has failed. This specific instance wasn’t a bug so much as a misunderstood feature (usernames must be unique, but you’re not using it in that fashion because you allow blank usernames), but because you have mention of database table issues as one of your reasons for reinstall, I’m suggesting pushing the wpdb->last_error into the debug log to help troubleshoot the source of the issue.
Personally, I’d also suggest putting the unique code in as a temporary username rather than having blank usernames allowed by the database, but that’s a design issue rather than a support issue.
A table index on the database, not in a file.
A UNIQUE index requires only one instance of the entry at any one point. But you can index a field for faster searching without making it unique. The indexes improve query response time either way. So I took off the unique requirement for an index on the username field in the database using phpmyadmin, leaving the field indexed.
Does that clarify?
Well, the only thing necessary to fix it was changing that index from UNIQUE, so that was the cause. The other registrations would not have been affected, only one that puts multiple entries with non-unique usernames, in this case a blank.
The tweaks I recommended were merely catches for if there is a problem with the insert caused by database issues. It would allow you to give more specific advice than to reinstall, which since the reinstall did not change or remove the index, had no effect despite the suggestion that it would repair any database issues. However, it is your call, obviously. My code only triggers on a failure, so it has no effect on normal running but will assist in tracing and resolving problems faster. I’m willing to share the specific code if you’d find it useful, though it sounds like you’ve already decided against any failure catches.
Okay, I solved it through putting some more catches in the code, ones I’d recommend you add as well because none of the steps (reinstalling, upgrading eStore, etc. worked).
The problem was this:
The members table had a unique index on the username, which means that only one person could have an “account verification in progress” at any one time. The first spammer to fill out that form blocked everyone afterwards.
I don’t know whether the unique index was something that was added in one of the upgrades, something I did to improve database performance since so many queries use the username, or something my host added to speed up our queries and reduce our impact on the database resources.
What I do know is that the reinstall did not check for conflicting indexes. Nor did the application provide that information at any point.
The catches I put in place are as follows:
1) In the email registration verification function, I checked to see if the member_id was greater than 0. If not, I sent myself an email with the key fields for troubleshooting.
2) In the db_access file, I added a catch for the $wpdb->last_error if true to send that to the admin and add the error message to the debug log.
The second change is what allowed me to figure out what the problem was, but the first allowed me to change the output from “everything is fine” to “there was a problem and we’re working on it” so any problems in the future will not be compounded by the end user and admin thinking it should be fine.
