WordPress issueshttps://lab.civicrm.org/dev/wordpress/-/issues2022-11-17T07:25:06Zhttps://lab.civicrm.org/dev/wordpress/-/issues/134Clean URLs system check fails via API or cv2022-11-17T07:25:06ZJonGoldClean URLs system check fails via API or cvAs of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots afte...As of CiviCRM 5.55, there is a check if Clean URLs are enabled.
Unfortunately, it does so by checking whether the `get_option()` function exists. This is fine via the web UI where WP boots first, but with `cv` or the API, WP boots after CiviCRM. Since `CIVICRM_CLEANURLs` is a constant, once it's set to `0`, it's fixed at `0`.
E.g. in `cv`, `Civi\Cv\Util\BootTrait::_boot_full()` contains the following code!
```php
PharOut::prepare();
$output->writeln('<info>[BootTrait]</info> Call standard cv bootstrap', OutputInterface::VERBOSITY_DEBUG);
\Civi\Cv\Bootstrap::singleton()->boot($this->createBootParams($input, $output));
$output->writeln('<info>[BootTrait]</info> Call core bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Core_Config::singleton();
$output->writeln('<info>[BootTrait]</info> Call CMS bootstrap', OutputInterface::VERBOSITY_DEBUG);
\CRM_Utils_System::loadBootStrap(array(), FALSE);
```
`\Civi\Cv\Bootstrap::singleton()->boot()` runs and `civicrm.settings.php` is evaluated before WP is booted at `\CRM_Utils_System::loadBootStrap(array(), FALSE)`.
### Next Steps
Maybe `CIVICRM_CLEANURLS` should be part of the `$civicrm_setting` global variable instead of a constant?https://lab.civicrm.org/dev/wordpress/-/issues/133WPML URL Integration for CiviCRM2024-02-19T18:33:21ZshaneonabikeWPML URL Integration for CiviCRM## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or oth...## Overview
When using WPML language plugin in conjunction with CiviCRM the generated translated URLs are incorrect. All the translated URLs point to the CiviCRM page rather than the proper translated CiviCRM event, contribution, or other page.
This isn't ideal and confusing for most users as they attempt to navigate to the translated CiviCRM page.
There is already integration for Polylang, but not integration presently for WPML.
WPML handles URLs in three different ways:
+ Attaching a language parameter to the end of the url ```lang=xyz```
+ Attaching a language in the path of the url ```https://test.dev/fr/civicrm/event/info/?reset=1&id=1```
+ Allowing for different domains for each language ```https://fr.test.dev/civicrm/event/info/?reset=1&id=1```
## Before
Viewing the page ```https://test.dev/civicrm/event/info/?reset=1&id=1```, and clicking on the WPML language link will take you to ```https://test.dev/civicrm/```
## After
The new code (I will attach the PR to this ticket shortly) will provide the proper integration for the defined scenarios above.
## Testing
I have tested this in the following scenarios, but maybe others want to test a bit larger?
+ Multiple domains while viewing (Events page)
+ Language placed in the URL (Events page)
+ Language within the proper path
+ Multisite installation with one site using WPML and CiviCRM Events
I don't believe that the path construction is any different for Contribution and other CiviCRM public pages, but I could be wrong.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)