WordPress issueshttps://lab.civicrm.org/dev/wordpress/-/issues2020-11-24T15:11:13Zhttps://lab.civicrm.org/dev/wordpress/-/issues/81Synchronising WordPress Users and CiviCRM Contacts2020-11-24T15:11:13ZhaystackSynchronising WordPress Users and CiviCRM ContactsWhilst trying to clean up some logic in the CiviCRM-WordPress plugin I have come across a mismatch in how the CiviCRM-Drupal module and the CiviCRM-WordPress plugin synchronises the CMS User to the corresponding CiviCRM Contact. See [thi...Whilst trying to clean up some logic in the CiviCRM-WordPress plugin I have come across a mismatch in how the CiviCRM-Drupal module and the CiviCRM-WordPress plugin synchronises the CMS User to the corresponding CiviCRM Contact. See [this Mattermost thread](https://chat.civicrm.org/civicrm/pl/u95r1msnwinmdpne3kmjrwd8kh) for preliminary discussion.
There are currently two different types of call to `CRM_Core_BAO_UFMatch::synchronize()` happening:
1. In `CiviCRM_For_WordPress::initialize()` (set up the session)
2. In `CiviCRM_For_WordPress::invoke()` and `CiviCRM_For_WordPress_Users::sync_user()` (do a full User->Contact sync)
This is the reason for the behaviour that @totten identified and that I don't think should happen at that point, i.e.:
> If you access a `civicrm/*` page, then it autocreates a Contact.
As per the Mattermost discussion, it seems to me that the types of call should be:
1. In `CiviCRM_For_WordPress::initialize()` and `CiviCRM_For_WordPress::invoke()` (set up the session)
2. In `CiviCRM_For_WordPress_Users::sync_user()` (do a full User->Contact sync)
This pattern reverts the types of calls to their pre-4.6 state. My fault for the change back then :blush:
My proposal is to keep the calls to `CRM_Core_BAO_UFMatch::synchronize()` in both `CiviCRM_For_WordPress::initialize()` and `CiviCRM_For_WordPress::invoke()` but to make the calls indirectly via a new method in the `CiviCRM_For_WordPress_Users` class. The reason for this is that:
1. It is possible that some code calls `civi_wp()->initialize()`, `civicrm_wp_initialize()` or `civicrm_initialize()` before the WordPress User has been properly set up. I've seen this in the wild, though I can't remember where. When this happens, I don't think `CRM_Core_BAO_UFMatch::synchronize()` should be called. The `CiviCRM_For_WordPress_Users` class can keep track of the state of the WordPress User and make sure the call occurs only at the appropriate time.
2. If no calls have succeeded by the time `CiviCRM_For_WordPress::invoke()` runs, then `CRM_Core_BAO_UFMatch::synchronize()` will be called correctly when it's most definitely needed. The `CiviCRM_For_WordPress_Users` class will know if it's been called already.
I don't think this change will have any adverse effects (in fact it should have marginally beneficial effects by only calling `CRM_Core_BAO_UFMatch::synchronize()` when needed) but if anyone knows of code that expects Contacts to be created a `civicrm/*` page then shout here.haystackhaystackhttps://lab.civicrm.org/dev/wordpress/-/issues/74IPN/webhook URLs should not be localized2020-09-04T10:33:07Zmattwiremjw@mjwconsult.co.ukIPN/webhook URLs should not be localizedOn a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https...On a site with polylang enabled Stripe displays an error that the webhook path is not setup correctly because it returns the first, default locale URL.
Example: https://sitename.org/en/civicrm/payment/ipn/1/
But the non-localized https://sitename.org/civicrm/payment/ipn/1/ also works as well as other locales.
Calls to `CRM_Utils_System::url()` generate a localized URL and there doesn't seem to be a way to ask for a specific locale (or default) - see https://lab.civicrm.org/extensions/mjwshared/-/blob/master/CRM/Mjwshared/WebhookTrait.php#L27
Not sure what the solution is here - @haystack @kcristiano - it causes Stripe to display errors about webhook configuration when it doesn't need to. Updating the webhook works too but is not actually necessary.https://lab.civicrm.org/dev/wordpress/-/issues/69Add support for Capability Manager2020-08-03T18:42:42ZAndrew WestAdd support for Capability ManagerAs mentioned in [#68](https://lab.civicrm.org/dev/wordpress/-/issues/68) we're a bit nervous of the WordPress Access Control page. instead we use [PublishPress Capabilities](https://wordpress.org/plugins/capability-manager-enhanced/), wh...As mentioned in [#68](https://lab.civicrm.org/dev/wordpress/-/issues/68) we're a bit nervous of the WordPress Access Control page. instead we use [PublishPress Capabilities](https://wordpress.org/plugins/capability-manager-enhanced/), which used to be Capability Manager (and something before that, I think). It's got about 90k installations. It shows all the WP capabilities for a given role, but one role at a time - so avoiding issues with max_input_vars.
By default the Civi capabilities are mixed in with 'Additional Capabilities', which makes it hard to tell them apart from capabilities added by other plugins:
![image](/uploads/d1651bd8856939ffbd3a50983423d5f2/image.png)
So we added a filter which separates it out:
![image](/uploads/619922931af42cee6d163375252f4be7/image.png)
It's a few lines:
```
function add_civicrm_category_to_capability_manager($capabilities) {
civicrm_initialize();
$permissions = array_keys(CRM_ACL_Form_WordPress_Permissions::getPermissionArray());
sort($permissions);
capabilities['CiviCRM'] = $permissions;
return capabilities;
}
add_filter('cme_plugin_capabilities','add_civicrm_category_to_capability_manager',10,1);
```
Is this too specific to add to Core?https://lab.civicrm.org/dev/wordpress/-/issues/68Add a warning to WordPress Access Control if max_input_vars is too low2020-08-13T00:11:07ZAndrew WestAdd a warning to WordPress Access Control if max_input_vars is too lowI haven't trusted the WordPress Access Control page since I saved a change and all hell broke loose with permissions. I think this was because max_input_vars was too low in our PHP settings. This had the effect of assigning spectacular a...I haven't trusted the WordPress Access Control page since I saved a change and all hell broke loose with permissions. I think this was because max_input_vars was too low in our PHP settings. This had the effect of assigning spectacular access to roles that shouldn't have had it.
We have 23 roles and 95 permissions, so there are in theory at least 2185 variables on the page. The default for max_input_vars is 1000. I'm not sure whether empty checkboxes are submitted as variables, though.
Is this worth warning people about? It's a security risk if you don't notice.
I've written a quick check for it. Does this seem sensible? I can submit a PR, but just wanted to run it past people here.
```
//check that we aren't above max_input_vars
$maxInputVars = ini_get('max_input_vars');
$varsOnThisPage = count($permissionsArray) * count($wp_roles->role_names);
if ($varsOnThisPage > $maxInputVars) {
CRM_Core_Session::setStatus("Submitting this page may have unexpected consequences for role permissions. " .
"You should increase the max_input_vars parameter in your PHP settings. " .
"There are $varsOnThisPage options on this page, but your max_input_parameter is $maxInputVars.", 'Warning', 'alert');
}
```
(I know this particular page is in Core rather than this plugin, but the WP repo seemed like a sensible place to ask)