WordPress issueshttps://lab.civicrm.org/dev/wordpress/-/issues2023-11-22T11:10:32Zhttps://lab.civicrm.org/dev/wordpress/-/issues/144Attempting to create a pretty URL on a subpage results in non-pretty URL2023-11-22T11:10:32ZshaneonabikeAttempting to create a pretty URL on a subpage results in non-pretty URLI discovered a strange issue today with regards to pretty CiviCRM Urls via the implemention ```CRM_Utils_System::url``` for Wordpress
## To recreate
1. Create a subpage called ```Profile```
2. In ```functions.php``` create a function l...I discovered a strange issue today with regards to pretty CiviCRM Urls via the implemention ```CRM_Utils_System::url``` for Wordpress
## To recreate
1. Create a subpage called ```Profile```
2. In ```functions.php``` create a function like
```php
civicrm_initialize();
$url = '';
$result = get_user_participation($current_user, $event_id);
if (!empty($result) && isset($result['values'][0]['participant_id'])) {
$pid = $result['values'][0]['participant_id'];
$eligible = CRM_Event_BAO_Participant::getSelfServiceEligibility($pid, '', FALSE)['eligible'];
if ($eligible) {
$checksum = \Civi\Api4\Contact::getChecksum(FALSE)->setContactId($result['values'][0]['contact_id'])->execute()->first()['checksum'];
$url = CRM_Utils_System::url("/civicrm/event/selfsvcupdate", "reset=1&pid=$pid&cs=$checksum", TRUE, FALSE, TRUE);
}
}
return $url;
}
3. Override the ```Profile``` page within your theme by creating ```Profile.php``` (Note: I didn't test if we use a shortcode here)
```
4. Call the function above to output the URL
## Result
The logic in the code determines if we have a [basepage](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Utils/System/WordPress.php?ref_type=heads#L324), and if it doesn't find one well it resorts to creating a non-pretty path.
I don't think that I'm proposing we change this, but it could be good to be able to override this maybe in the function call? To force it to make pretty links regardless, because on some subpages for sure we would want to have nice links.
Ironically, the link generated doesn't work in this case either. When it's a pretty link it's fine but otherwise no dice. It could be a configuration issue with my client I'm not sure.https://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.haystackhaystack