Home › Forums › Andy Burnett
About: Andy Burnett
Sorry, I've not written a description yet. I'll get to it soon!
Topics I'm Subscribed To
Topics I've Started
My Latest Replies (From Various Topics)
Author | Replies |
---|---|
Author | Replies |
Posted: Monday Jan 13th, 2014 at 5:00 am #62580 | |
|
|
Thanks Sylvia – I think that’s exactly what we’d do if we didn’t have the whole site already built, running and full of users :). I was hoping to avoid a complete redesign and ‘re-levelling’, but I’m assuming from the quietness here that’s pretty much the only solution that doesn’t involve lots of custom code (e.g. hacking the auto-demotion scripts to set a flag in the user profile or something). In fact, I’ve noticed s2 does put a message in the ‘Notes’ section – it would be really nice if that code could check for a custom profile field called ‘expired’ or something and set it to ‘1’ or ‘true’… Hoping someone at s2 is still reading here :) |
|
Posted: Friday Aug 16th, 2013 at 10:16 am #56031 | |
|
|
OK – I _think_ I’ve temporarily fixed this by changing the slug of the ‘Sign In’ page from ‘login’ to ‘log-in’. At least there’s no 404s now on logging out. Not sure what else might be broken now though :) I’m going to start from a clean install of WP and try to work out if/when/how this unravels… Still be interested if you have any pointers, but not urgent now. Thanks. |
|
Posted: Friday Jun 14th, 2013 at 7:34 am #51954 | |
|
|
Well, it’s a little confusing – I don’t think it had timed out, as the user was still having problems, and when a colleague of mine went in to view the user’s record a while later, the warning was there. When this subsequently happened to 2 other users, I also didn’t see the warning in their profiles, but resetting their IP ban fixed it for them. Perhaps it isn’t being updated instantly, or some other caching effect? |
|
Posted: Friday May 10th, 2013 at 5:35 am #49681 | |
|
|
Apologies for the long post – this is more involved than I originally thought. I knew the import format had changed, and we have updated our import spreadsheet accordingly. I originally used the help page to format the new spreadsheet, but when this didn’t work, I exported our data via the s2 Export Users option using this process:
and no custom profile field data was brought back in – even though it was there in the exported csv file. However, I think this problem might have a slightly obscure root cause. We’ve modified the imports-in.inc.php file (via mu-plugins) to process list servers on import. There’s a support thread here about what we’ve done, including the additional code, and all has been working fine. However, this particular user I was exporting / importing above was for a membership level that doesn’t have an associated Mailchimp list, and so the import routine logs an error that it was unable to process the list sign-up. I wondered if this was causing the problem, so I edited the csv data to associate that user with an s2 level which did have a Mailchimp list (and hence the list signup should work fine). When I imported this data, I got a different error: Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/tctc4me/public_html/learn.tctc4.me/wp-content/mu-plugins/s2hacks.php on line 59 The relevant function we’ve attached to that hook is to ensure the custom fields are passed over to Mailchimp, and here’s the code:
So, $fields isn’t an array, which I guess means where it is initialised with $fields = $vars[‘fields’]; isn’t returning an array for some reason. I then realised that imports-in.inc.php has been upgraded since we patched it for list server processing. I replaced the imports-in.inc.php file on our server with the latest one from s2, and lo and behold the import worked fine (albeit with no list integration, obviously). I then applied our list integration patch to the new version of imports-in.inc.php, and now custom fields are imported properly (regardless of whether there’s a MC list associated with the user’s level), so that’s at least one thing fixed. But I am now stuck with the ‘isn’t an array’ message on the merge function above. The patch to imports-in.inc.php is below, and it’s inserted at line 330 of the current version of imports-in.inc.php:
Perhaps these two things are unconnected, and I know it’s only a warning from the merge filter. It does look like it’s working, in that the custom fields are being updated and sent across to Mailchimp. Is it just that we need to check for an empty result when initialising the $fields variable? And secondly, is there a more reliable way to achieve the the patch to imports-in.inc.php? Obviously we’ll need to check if this file has been upgraded each time we update the plugin – something I hadn’t thought to do, and it would be great if there was some way to automate this. Or perhaps there’s a hook available now which could do this? Many thanks. |
|
Posted: Friday Apr 26th, 2013 at 10:56 am #48496 | |
|
|
Thanks – I think I’ve got what I need working now. I’ve got a function which already checks various profile fields for default values hooked against the ws_plugin__s2member_during_configure_user_registration_front_side action. I’ve added the following at the beginning of that function:
The array $cFields[] is then merged back into the users profile with a call to array_merge() and update_user_option(). So now I can put any combination of profile fields in the URL as parameters. However, this looks like a recipe for injection attacks! I’m wondering what the best way to defend this might be… Is there a way of getting an array of the current valid profile fields, so I can restrict processing to only those fields? Is there anything else I should be doing to minimise the risk of people putting random code into the URL? |
|
Posted: Thursday Jan 3rd, 2013 at 9:18 am #36108 | |
|
|
Thanks for the analysis and advice – I would certainly agree we are trying to do more than the mailchimp filter is designed for, and so separating that code out makes sense. The only concern I now have is that those user fields are needed on the mailchimp side as well, so we need to be sure the custom fields are updated before any calls to the mailchimp api. I presume things would happen in the right order, but do you know for sure if ws_plugin__s2member_during_configure_user_registration_front_side is called before ws_plugin__s2member_mailchimp_merge_array? In general, is there an easy way to know in what order these filters are applied? Thanks again! PS – off topic: I can’t find the tag to put those filter names in ‘code hilite inline’ format as you did – the code tags always create a block for me – is there a trick? Tx! |
|
Posted: Saturday Dec 22nd, 2012 at 9:01 am #35313 | |
|
|
Hmm – $today is defined in the existing script, and used in the date comparison (strtotime($today)) in the if statement. Just thought it sensible to do that rather than make 2 calls to date(). Re caching – do you mean a plugin doing that? If so, no – just standard WP. Here’s a full list of the plugins we’re using: amr users I don’t think any of them do any caching. Also, I was just looking at the WP codex, and the notes for update_user_option() say this:
This probably explains why I couldn’t get anything to work when I originally had the code using ‘wp_s2member_custom_fields’ – it would have ended up as ‘wp_wp_s2member_custom_fields’! But from what I can see of that function, it should be working. Is there anything else I can check – on the db side for example? Thanks, David. |
|
Posted: Thursday Dec 20th, 2012 at 6:53 am #35131 | |
|
|
Re the default fields – those options only seem to take effect if the field is visible to the user. This is pure metadata and is set to Invisible during and after registration. The default value is set in the options, but comes in as an empty string in this filter. Re the date – thanks, I’ll change that to call empty(). Out of interest, what’s the advantage of a second call to date() in the assignment, rather than just using $today, which is already assigned? More importantly, yes, the output included ‘fields updated’. To test, I created a user account with a ‘Start Date’ of 2012-12-19 and role of ‘Subscriber’. I then promoted that user to ‘s2 Level 1’ – here’s the full output when the debugging ‘echos’ are uncommented:
What’s really odd is the last call to get_user_option() uses a different array ($dField[]) and does load the correct data. But it only seems to persist like that until the end of the function. The userlist on WP still shows 2012-12-19 for that user. I can change the ‘Start Date’ from the Edit User page on WP, and then it does stick. |
|
Posted: Tuesday Dec 18th, 2012 at 4:35 am #34886 | |
|
|
Here’s the full code (note the verification I mentioned in the original post is all commented out):
|
|
Posted: Thursday Dec 13th, 2012 at 8:29 am #34462 | |
|
|
Thanks – is this on a roadmap / timeline anywhere? Just wondering if we can wait for the next release, or whether we need to fix it sooner than that… Thanks. |
|
Posted: Thursday Dec 13th, 2012 at 5:06 am #34458 | |
|
|
Well, it’s tested in the sense that I imported some users and they ended up subscribed to a MC list! So, not really tested, but at least on the face of it, it’s working. I’m sure there are extreme cases where things might not work as expected, but for now it’s OK. I was just covering bases to see if you could spot anything obvious I’d missed. The redundancy I was referring to was just that most of the parameters can be derived from the user_id that is passed in, so I wasn’t sure why the function expected all the other parameters to be passed in separately, rather than just look them up – which is all I’ve done. Again, just wondering if I’d misunderstood something. Thanks. |
|
Posted: Tuesday Dec 11th, 2012 at 7:33 am #34231 | |
|
|
Regarding user deletions and the setting you mentioned (Dashboard -› s2Member® -› API / List Servers -› Automate Unsubscribes/Opt-Outs), I have ticked the top-level box labelled ‘Anytime a User is deleted ( including manual deletions )’. I just deleted 16 users, but only the very first was unsubscribed from the MailChimp list, and the API logs from MC show only a single call was made. Could you confirm if this is a bug, and if it is, if there’s any more information I can dig out of logs, etc. which might show what went wrong? Thanks! Update: I just deleted a few more test users, this time in 2 goes, and saw 2 calls to the MC API, removing 1 user each time. So I suspect something which should be in a loop isn’t :)
|
|
Posted: Monday Dec 10th, 2012 at 3:09 pm #34174 | |
|
|
Thanks – it is weird, as I can run it through ‘php.exe -l’ with no problems, which is all SublimeLinter does… Ho hum – someone else’s problem now :) Back to the issue at hand – I’ve added the following code to imports-in.inc.php in 2 places (at lines 216 and 332 of the original file), just before the ‘imported’ variable is incremented in each case. I think this is all that’s needed – any chance you could comment on whether I missed something? There seems to be a fair bit of redundancy in the parameters passed to process_list_servers (e.g. ‘level’ and ‘role’ – aren’t they pretty much the same thing?). Also, we obviously don’t have an IP address for imported users, so I’ve just left that blank. Many thanks!
|
|
Posted: Monday Dec 10th, 2012 at 9:59 am #34139 | |
|
|
On a related but separate issue, I’m having problems with SublimeText and imports-in.inc.php – specifically it’s causing SublimeLinter to freeze! Would you be happy for me to post the contents of just that php file to the SublimeLinter support group so I can ask why? It’s making editing it a pain, as I have to remember to turn off linting before starting! Thanks!
|
|
Posted: Friday Dec 7th, 2012 at 7:14 am #33862 | |
|
|
Regarding the list processing on import, I couldn’t find any filter related to user importation – did I miss something? I’m not sure where else we’d hook that code to, as I can’t tell if there’s another way to distinguish regular users from imported users, other than as it’s happening… Thanks. |
|
Posted: Friday Dec 7th, 2012 at 6:48 am #33859 | |
|
|
Thanks – I’ll take a look at that and see how we get on. We’re only talking about a few tens of users at a time to import, but we might be doing it on a regular basis (rather than hundreds or thousands once in a blue moon). Does that principle apply to bulk deletes via the WordPress system too? I’ve noticed quite a discrepancy between the WP list and MC list as we’ve been testing this… |
|
Posted: Thursday Dec 6th, 2012 at 9:24 am #33705 | |
|
|
Thanks – if you could share the hackey solution, that would be great – we can decide if it’s worth the risk / effort, or if we can work around it until it’s fixed properly (I presume from your message that it is on the fix list, just that it won’t be quick?). I have a related question on processing list on imported users, but I’ll start a new thread so it can have an accurate title – perhaps it’s connected with this issue? |
|
Posted: Thursday Nov 15th, 2012 at 9:33 am #31689 | |
|
|
Yup – that’s what I was referring to in the original message. I ticked the main box which then ticked the 3 sub-boxes. |
|
Posted: Thursday Nov 15th, 2012 at 3:56 am #31664 | |
|
|
As we will have multiple members to approve at any one time, I made the role change from the main user list via the dropbox (Change Role to …), rather than from within the Edit User screen of an individual user. However, having checked the specific user I was changing to test this with, the checkbox ‘Allow List Transitioning’ was checked. I’ve retried it from within the ‘Edit User’ screen, and the list transitioning works as expected, so it appears that it’s just not being processed when done from the main user list screen via the dropbox. Could you confirm this? Thanks. |
|
Posted: Wednesday Nov 14th, 2012 at 6:41 am #31552 | |
|
|
Thanks – I guess that would be doable. I also found this code from Raam – is that the kind of thing we’d need?
|
|
Posted: Friday Sep 28th, 2012 at 3:30 pm #26885 | |
|
|
Hmm – still a bit confused as to what the internal conflict is, and so how we’d know if we were suffering problems as a result. If I do pick a page and ignore the error, what are the symptoms of the conflict? Thanks, Andy. |
|
Posted: Friday Sep 28th, 2012 at 8:06 am #26828 | |
|
|
Hmm – that’s a shame. It will make me the bottleneck if he can’t post things too, and he won’t get notifications of replies… Is there no way just to elevate his account as if he’d paid? If it’s a ‘number of people’ thing, it would be better that he has access to the support forums rather than me… Thanks, Andy |