• Dear Register Plus Redux,
    I have successfully installed the RPR plugin after some tinkering to get it to co-exist with a a Mail Chimp related plug-in that allows for mailing list registration concurrent with wordpress registration (WP-Leads). All good.

    One of the key reasons I implemented RPR is for the Accept Licence checkbox, which i have made required. It works as far as requireing it be checked to submit the form. However, where in the SQL database do i find this field: “accept_license” and the associated checked/true value? And any other values I may end up adding to the registration area?

    I have looked in wp_user and wp_usermeta, but cant seem to identify where that data resides. Is it added to the opaque wp_capabilities field? and if so a translation would be very helpful, i.e.: a:1:{s:10:”subscriber”;b:1;}

    Thanks for your help.

    Justin

    https://www.ads-software.com/extend/plugins/register-plus-redux/

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author radiok

    (@radiok)

    There is no field at this time because if they don’t accept the license the registration fails. I have been meaning to improve this though with a timestamp, “license_accepted” so that if you at some time change your licensing you can disable user login until they accept the new license. I will try to get that in for the next release… but it’s a tad unlikely because I’ve been considering dropping the whole license, disclaimer, privacy policy boxes in favor of a new additional field type called “legal” or some such. At that point you add a new additional “legal” field paste in your terms, specify a revision date, and whether they must be accepted. When the user registers it will record the timestamp in the specified database field. When they login it will compare the timestamp to the revision date and either just display them (if acceptance isn’t required) or mandate that they accept them.

    What are you thoughts?

    Thread Starter Vino247

    (@vino247)

    Dear Radiok,
    Thanks for you detailed ideas on the issue. Your thought about the registration failing if not accepted, was exactly my thought. …Until we spoke with our attorneys. They work with large online corps and told us that the burden is on us to provide a record of acceptance. So even if acceptance is a required field, without some specific record of acceptance (like license_accepted value=”yes”) we don’t have much in the way of the kind of proof courts expect these days.

    If I am understanding your more generic legal field idea correctly: it would be a legal text field with a revision date parameter and an acceptance timestamp, that if required cross checks to see if a newer acceptance is required. This sounds like a great idea.

    Though I would still suggest an additional field like license_accepted value=”yes” to go along with the acceptance_timestamp value=”time/date”, and keep a running pair or triplet every time there is a new revision (i.e. revision_date, acceptance_timestamp, license_accepted).

    I can see from your idea how it could get pretty hairy juggling revision dates of acceptance.

    In our case inorder to keep it short we include links to both the Terms of Use and Privacy Policy, with a required check box for acceptance of the Terms of Use. Technically speaking the Terms of Use is a contract that requires acceptance, while the Privacy Policy does not have that same legal burden, but would require new notices of some kinds of changes as they go into effect.

    Your generic legal field would be great in that regard, so that if the Terms are the same but the Privacy changes or visa versa we would note which of the two changed (or both) everytime we need to get new acceptance one way or the other. Something along the lines of:

    By clicking “Accept,” you agree to our Terms of Use. Our Privacy Policy changed on mm/dd/yyyy. Please review our Privacy Policy for information about our privacy practices.
    [] *Accept
    …Or something like that.

    From our point of view, even having only a single license_accepted value=”yes” field to go with registration date is the baseline of what we are looking for, even if it will start to get crazy with later revisions. In short, an initial “yes” would be a lot better than none at all.

    Please let me know your thoughts.

    I may end up having to figure out something else if you won’t be able to fit something on this into your next release schedule. ??

    Thanks!

    Best Regards,

    Justin

    Plugin Author radiok

    (@radiok)

    Justin, I’m working on this now. I will definitely be storing a yes/no for acceptance. That will use the meta_key provided. The timestamp will be stored as meta_key + “_date”.

    For example, you could define a new “legal” field, “Terms and Conditions” with a meta_key terms_and_conditions. When a new user registers they will check the checkbox and it will write to the database a “Y” for terms_and_conditions and 1367473866 for terms_and_conditions_date (that’s a UNIX timestamp).

    For now, that’s where the buck stops. I do have two additional TODO’s but I’m pretty burned out for the night. They are, A) what happens to all the existing users on your site? They effectively have never agreed under this new schema, so they need to be prompted when they log on to accept. Of course there’s a _slight_ problem with that regarding users who have cookies and are logged in regardless… I could either tie something to the admin interface so when they go to an admin page interrupt them, or find some way to invalidate the cookies… or just not worry about it, they’ll have to log back in eventually right? I’m not even sure that’s a worthwhile issue because I don’t know how long WordPress’ login timeout is. Regardless, I need to code the interupt on login to take them to some special page that says accept and it keeps coming back there until they do.

    Next, I need something similiar for the revision date. This isn’t as super important since no one is using this feature yet so they really shouldn’t have revisions they need to push. But if I don’t do it soon, I never will!

    Finally, hm, I’m on three… Oh well, anyway, finally, I’m considering another field, in our example terms_and_conditions_content which will store the content of the last terms_and_conditions they accepted. This way if you have revised the terms three or four times since they last accepted there is no ambiguity, these are the literal terms they accepted… That’s just an idea because it’s a lot of database cruff so I’ll have to mull that one over a bit longer.

    Regardless, if you have a dev site I’d love for you to install a development build of Redux and test this stuff out. I think it’s… mostly working, but I need to take a look at it with fresh eyes later.

    Thread Starter Vino247

    (@vino247)

    Radiok,
    Thanks for the quick response. Sounds like a good plan. I hear you on the late night, we soft launch next week.

    My initial take is not to get too worried about previously existing users as far as acceptance when the new protocol comes in, as they did at one time agree, and most decent Terms of Use agreements start with a statement on the order of: please check back on our terms and privacy policy regularly. Its only “material” changes that our lawyers tell us meet the threshold for “required” notification of Privacy Changes and/or a new Terms acceptance. And as you say, eventually they will have to log back in.

    Revision date would be great, if you can squeeze it in, but not as key as your buck stoppers.

    I would be most happy to install on my Dev site. The dev is getting put through the paces with lots of version back ups. I can give you credentials behind our access control to view once I install if you like.

    Best,

    Justin

    Plugin Author radiok

    (@radiok)

    Not sure if you already know this, but the development copy is located on the following page: https://www.ads-software.com/extend/plugins/register-plus-redux/developers/

    Thread Starter Vino247

    (@vino247)

    Hi Radiok,
    Thanks. I did not realize that. I will try it out and keep you posted.
    Justin

    Plugin Author radiok

    (@radiok)

    Hey Justin, did you get a chance to try this out yet? I hope it works as you expect.

    Thread Starter Vino247

    (@vino247)

    Hi Radiok,
    Perfect timing. Yes i tried it last night and ran a test. I was not quite sure how it was different, as I could not find revision or accept data in the database after registering a new test user or see any admin settings for those new features.

    And now realize that I probably need to delete the old version through the plugin interface, rather than simply replacing the RPR files via FTP. Perhaps by not deleting and installing fresh, the database is not set up correctly with the new functions?

    Additionally, I got sidetracked with the Media Library not displaying any stored media in the post/page writing “Insert Media” mode, when RPR is activated. This is with both the current release and the development version, the same. So i spent quite a bit of time isolating that side issue. Turns out that there is a conflict i am having between the Add Local Avatar plugin and RPR. Either one runs fine on its own, but the two plug-ins combined cause this Media Library problem so you cant see any of the stored media when inserting into posts/pages. Tried some alternate avatar solutions, etc. and turned into quite a late night. The console error i am getting on this is out of: “/wp-admin/admin-ajax.php”

    ERROR:

    POST https://vino247.com/dev/wp-admin/admin-ajax.php 500 (Internal Server Error) load-scripts.php:2
    send load-scripts.php:2
    v.extend.ajax load-scripts.php:2
    (anonymous function) load-scripts.php:449
    v.extend.Deferred load-scripts.php:2
    _.extend.ajax load-scripts.php:449
    g.model.Query.c.extend.sync load-scripts.php:449
    f.extend.fetch load-scripts.php:432
    g.model.Query.c.extend.more load-scripts.php:449
    g.model.Attachments.Backbone.Collection.extend.more load-scripts.php:449
    f.view.Attachments.f.View.extend.prepare load-scripts.php:451
    f.View.Backbone.View.extend.render load-scripts.php:451
    (anonymous function) load-scripts.php:451
    T.each.T.forEach load-scripts.php:408
    _.extend._attach load-scripts.php:451
    _.extend.set load-scripts.php:451
    _.extend.add load-scripts.php:451
    f.view.AttachmentsBrowser.f.View.extend.createAttachments load-scripts.php:451
    f.view.AttachmentsBrowser.f.View.extend.updateContent load-scripts.php:451
    f.view.AttachmentsBrowser.f.View.extend.initialize load-scripts.php:451
    g.View load-scripts.php:442
    f.View.Backbone.View.extend.constructor load-scripts.php:451
    d load-scripts.php:447
    f.view.MediaFrame.Select.f.view.MediaFrame.extend.browseContent load-scripts.php:451
    g.Events.trigger load-scripts.php:418
    f.controller.StateMachine.(anonymous function) load-scripts.php:451
    _.extend.trigger load-scripts.php:451
    _.extend.render load-scripts.php:451
    _.extend.mode load-scripts.php:451
    _.extend.render load-scripts.php:451
    f.controller.State.(anonymous function) load-scripts.php:451
    f.controller.State.Backbone.Model.extend._postActivate load-scripts.php:451
    g.Events.trigger load-scripts.php:418
    _.extend.setState load-scripts.php:451
    wp.media.editor.add load-scripts.php:452
    wp.media.editor.open load-scripts.php:452
    (anonymous function) load-scripts.php:452
    v.event.dispatch load-scripts.php:2
    o.handle.u load-scripts.php:2

    Anyway, I will give it another go doing a clean install of the development version from your Developer page. But if you have any ideas on the above please let me know.

    Thanks!

    Justin

    Plugin Author radiok

    (@radiok)

    Wow, that is… something… I’ll have to play with that tonight from my development site, I don’t have access to that outside my home office.

    As for the new “terms”. You need to take your existing legal notices and create new additional fields using the same information. I am looking to auto-magically convert legal notices to additional fields for 4.0, but don’t want to make any drastic changes until I am certain the new “terms” are working at least as well as the current model.

    Also, the development build is now synced up with the latest release 3.9.9, so you can install that easier from within you Admin interface. That is until I find something new to monkey around with.

    Thread Starter Vino247

    (@vino247)

    Ok. Thanks.

    Should those new additional fields have any specific names or follow any specific naming convention to fall into place, or not conflict with existing fields?

    Please let me know and i will give it a shot.

    Thanks,

    Best Regards,

    Justin

    Plugin Author radiok

    (@radiok)

    You shouldn’t need to worry about the meta_key in anyway since the previous incarnation wasn’t recording anything to the database, literally anything. So “Privacy Policy” with meta key “rpr_privacy_policy” is totally kosher, or anything else give or take, so long as you aren’t duplicating meta_keys. For 4.0 I’m making a big meta browser which I really don’t want to touch, but need to, so that if you ever want to change the meta_key you can quickly and easily migrate data from one key name to another without having to write your own SQL.

    Thread Starter Vino247

    (@vino247)

    Dear Radiok,
    Sorry for the delay getting back to you. Got pulled away with a bunch of other stuff. As for the new version and the Terms custom field, the core functionality works very well, but with one small hitch and that same strange Insert Media conflict as above.

    I installed v3.9.10 and created the custom “terms” field labeled Terms of Use with the meta key: rpr_terms_accept, with accept as a required field, show on registration checked and show on profile checked, and included my Terms text with links to the full Terms page and full privacy page. Once done, the user registration form looked good and a test worked well: requiring the accept box to be checked, registering the user, recording the Y for rpr_terms_accept and also notating the last revised date and the rpr_terms_accept_date in SQL. This data also appeared on all user profiles as well, and included listing N for rpr_terms_accept on those previously existing, never before accepting users. So all good.

    The small hitch: when i uncheck the “show on profile” check box in the field settings and save the settings, the Terms of Use data still displays on all profiles.

    So I am not sure if this a minor bug? Or, when i first set up the new field if i should do so without the show on profile box checked? Please advise if this is an initial decision thing, or if the check box should be able to toggle on or off after set up.

    Also, regarding the issue of users logging back in after a new terms revision has taken place, have you had a chance to work on an interrupt routine? So that if a user tries to log in having accepted a previous terms, but not the most resent terms revision, they are prompted to accept the new terms?

    I very much look forward to hearing back. And again sorry for the delay on my part.

    Thanks.

    Best,

    Justin

    P.S. still haveing that weird /wp-admin/admin-ajax.php 500 (Internal Server Error) conflict mentioned above, which happens when inserting media in page/post edit mode, and seems to occur when executing load-scripts.php from admin-ajax.php

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘location of additional fields in SQL database’ is closed to new replies.