Partial fix of api explorer #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
colemanw
force-pushed
the
api4-in-core
branch
from
1acd225
to
40a6e65
Compare
|
Ok got it. |
totten
pushed a commit
that referenced
this pull request
Oct 30, 2019
Updating Fork with Commits on Base
totten
pushed a commit
that referenced
this pull request
Nov 12, 2019
Proposed updates to Gitlab issue template
totten
added a commit
that referenced
this pull request
Feb 18, 2020
Overview -------- This fixes a recent regression in which `xml/GenCode.php` fails to execute in certain configurations. Initial report: civicrm/civicrm-buildkit#503 Before ------ * If the folder `l10n` exists in its traditional location, and if you run `./bin/setup.sh -g`, then it correctly executes. * If the folder `l10n` does not exist in its traditional locacation, and if you run `./bin/setup.sh -g`, then it fails with an error like this: ``` + php -d mysql.default_host=127.0.0.1:3306 -d mysql.default_user=dmasterciv_abcde -d mysql.default_password=abcd1234 GenCode.php schema/Schema.xml '' Drupal civicrm_domain.version := 5.23.alpha1 Parsing schema description schema/Schema.xml Extracting database information Extracting table information PHP Fatal error: Uncaught RuntimeException: Invalid configuration: the [cms.root] path must be an absolute URL in /home/me/.../Civi/Core/Paths.php:174 Stack trace: #0 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'cms.root') #1 /home/me/.../Civi/Core/Paths.php(176): Civi\Core\Paths->getVariable('cms.root', 'url') #2 /home/me/.../Civi/Core/Paths.php(151): Civi\Core\Paths->toAbsoluteUrl('/', 'civicrm.root') civicrm#3 /home/me/.../Civi/Core/Paths.php(224): Civi\Core\Paths->getVariable('civicrm.root', 'path') civicrm#4 /home/me/.../Civi/Core/Paths.php(84): Civi\Core\Paths->getPath('l10n') civicrm#5 [internal function]: Civi\Core\Paths->Civi\Core\{closure}() civicrm#6 /home/jo in /home/me/.../Civi/Core/Paths.php on line 174 ``` After ----- You can run `./bin/setup.sh -g` with or without the `l10n` folder. Comments -------- There's an argument to be made that this shouldn't be necessary: when running `GenCode`, it should only create PHP files, and none of the output should depend on the CMS URL - because that's liable to change when you deploy the PHP code. If someone did try to generate URL at such an early stage, it's arguably good to generate an error. In point of fact, `GenCode` is not actually using the CMS URL. The oddity stems from the contract of `CRM_Utils_System_*` (specifically, `getCiviSourceStorage()` and `getDefaultFileStorage()`) which do double-duty providing both path and URL. To avoid duplicate work, `Civi\Core\Paths` uses the same grain of information - it tracks the pairs of path+URL. A more aggressive fix might be to split `getCiviSourceStorage()` and `getDefaultFileStorage()` so that it's possible to get the path and URL separately; then revise `Civi\Core\Paths` to take advantage of the finer-grained contract. However, splitting those things would be a more invasive patch, and we're currently in RC.
totten
added a commit
that referenced
this pull request
Aug 24, 2020
…esources
This is a very subtle behavioral change. To understand it, we must consider
the traditional ordering in `CRM_Core_Resources::addScriptUrl()` and
`CRM_Core_Region::add()`. Compare these two examples:
```
Civi::resources()->addScriptUrl('http://example.com/foo.js', 100, 'page-footer');
Civi::resources()->addScriptUrl('http://example.com/bar.js', 100, 'page-footer');
CRM_Core_Region::instance('page-footer')->add([
'scriptUrl' => 'http://example.com/foo.js',
'weight' => 100,
]);
CRM_Core_Region::instance('page-footer')->add([
'scriptUrl' => 'http://example.com/bar.js',
'weight' => 100,
]);
```
You might expect this to output `<SCRIPT>`s in the same order. After all,
the examples use the same URLs, the same weights, and the same
procedural/natural order. Moreover, `Civi::resources()` is just a wrapper
for `CRM_Core_Region`. Surely they were the same!
They were not. The output order would differ.
The reason is that the ordering had two keys (`weight,name`), and the
secondary-key (`name`) was hidden from us:
* In `CRM_Core_Resources::addScriptUrl()`, the default `name` was the URL.
This was handy for de-duping resources.
* In `CRM_Core_Region::add()`, the default `name` was a numeric position.
This made it behave like procedural/natural-ordering.
Of course, the goal in this branch is to make various collections support
the same methods and the same behaviors. But they didn't agree before, so
something has to give. Either:
1. Standardize on the behavior of `Resources::addScriptUrl()` and change `Region::add(scriptUrl)`.
2. Standardize on the behavior of `Region::add(scriptUrl)` and change `Resources::addScriptUrl()`.
3. Embrace a split. All `CRM_Core_Resources::add*()` behave one way, and all `CRM_Core_Region::add*()` behave another.
4. Embrace a split. All rich adders (`*::addScriptUrl()`) behave one way, and all generic adders (`*::add()`) behave another.
This developmental branch has been using `civicrm#3`. The patch changes it to `civicrm#4`.
Both splits achieve backward compatibility wrt `Resources::addScriptUrl()`
and `Region::add(scriptUrl)`. The difference is that `civicrm#4` allows us to have
the same behavior in all collections (regardless of subtype), which means
that collections can be more interoperable and share more code. From my
POV, it's still quirkier than `#1` or `#2`, but it's not as quirky as `civicrm#3`.
seamuslee001
pushed a commit
that referenced
this pull request
Sep 3, 2020
…esources
This is a very subtle behavioral change. To understand it, we must consider
the traditional ordering in `CRM_Core_Resources::addScriptUrl()` and
`CRM_Core_Region::add()`. Compare these two examples:
```
Civi::resources()->addScriptUrl('http://example.com/foo.js', 100, 'page-footer');
Civi::resources()->addScriptUrl('http://example.com/bar.js', 100, 'page-footer');
CRM_Core_Region::instance('page-footer')->add([
'scriptUrl' => 'http://example.com/foo.js',
'weight' => 100,
]);
CRM_Core_Region::instance('page-footer')->add([
'scriptUrl' => 'http://example.com/bar.js',
'weight' => 100,
]);
```
You might expect this to output `<SCRIPT>`s in the same order. After all,
the examples use the same URLs, the same weights, and the same
procedural/natural order. Moreover, `Civi::resources()` is just a wrapper
for `CRM_Core_Region`. Surely they were the same!
They were not. The output order would differ.
The reason is that the ordering had two keys (`weight,name`), and the
secondary-key (`name`) was hidden from us:
* In `CRM_Core_Resources::addScriptUrl()`, the default `name` was the URL.
This was handy for de-duping resources.
* In `CRM_Core_Region::add()`, the default `name` was a numeric position.
This made it behave like procedural/natural-ordering.
Of course, the goal in this branch is to make various collections support
the same methods and the same behaviors. But they didn't agree before, so
something has to give. Either:
1. Standardize on the behavior of `Resources::addScriptUrl()` and change `Region::add(scriptUrl)`.
2. Standardize on the behavior of `Region::add(scriptUrl)` and change `Resources::addScriptUrl()`.
3. Embrace a split. All `CRM_Core_Resources::add*()` behave one way, and all `CRM_Core_Region::add*()` behave another.
4. Embrace a split. All rich adders (`*::addScriptUrl()`) behave one way, and all generic adders (`*::add()`) behave another.
This developmental branch has been using `civicrm#3`. The patch changes it to `civicrm#4`.
Both splits achieve backward compatibility wrt `Resources::addScriptUrl()`
and `Region::add(scriptUrl)`. The difference is that `civicrm#4` allows us to have
the same behavior in all collections (regardless of subtype), which means
that collections can be more interoperable and share more code. From my
POV, it's still quirkier than `#1` or `#2`, but it's not as quirky as `civicrm#3`.
totten
pushed a commit
that referenced
this pull request
Oct 13, 2020
Overview ---------------------------------------- Fix use of legacy leaky method in tested code Before ---------------------------------------- dao->query() After ---------------------------------------- CRM_Core_DAO::executeQuery() Technical Details ---------------------------------------- This is too low volume to really leak but it uses the leaky legacy method and has test cover in CRM_Import_DataSource_CsvTest.testToCsv with data set #0 CRM_Import_DataSource_CsvTest.testToCsv with data set #1 ----------------------------------------
totten
added a commit
that referenced
this pull request
Oct 21, 2020
Overview -------- The test appears to have a random failure. Making it more readable may help figure out why. Before ------ `testDeleteByCacheKey()` and the related `testFillArray()` both have some assertions in these two forms: ``` // Form #1, more verbose $all = ...getSelections($cacheKey, $action); $this->assertEquals([...expected...], array_keys($all)...); // Form #2, more pithy $this->assertSelections([...expected...], $action, $cacheKey); ``` After ----- The verbose form is replaced with the pithier form. In the pithier form, some of the default inputs are made explicit. Comment ------- It is confusing that the method `getSelections()` has a parameter `$action` which can be `get` or `getall` -- and that `getall` does not (in fact) return selections. It returns all! (The fact that the contract is weird makes the unit-test helpful imho...)
totten
pushed a commit
that referenced
this pull request
Mar 22, 2021
Add `resetPaths` as per issue civicrm#2458 #1
totten
added a commit
that referenced
this pull request
Jul 21, 2021
totten
added a commit
that referenced
this pull request
Oct 8, 2021
Use-case: 1. Open the editor a message template (eg `#/edit?id=17&lang=fr_FR`). This renders the edit screen. 2. Click on the "Preview" icon. 3. Close the "Preview" dialog. 4. Change the URL to navigate internally to another template (eg `#/edit?id=17&lang=de_DE`). This renders the edit screen again. 5. Click on the "Preview" icon. Before: * It subsequently opens two copies of the "Preview" dialog (each with slightly different options). Initially, you see one dialog. When that close, you will see the other dialog. * As you proceed through closing the dialogs, you may get console warnings because the dialogs have the same name -- and they consequently trip-up each other. After: * It only opens one copy of the "Preview" dialog. Technical Details: * When rendering the setup screen (`#1`/`civicrm#4`), it registers a listener which will handle the "Preview" clicks. But the listener is not properly unregistered. Consequently, old listeners hang around. So the click at step `civicrm#5` calls both the old+new listeners, creating two dialogs.
totten
added a commit
that referenced
this pull request
Oct 8, 2021
Use-case: 1. Open the editor a message template (eg `#/edit?id=17&lang=fr_FR`). This renders the edit screen. 2. Click on the "Preview" icon. 3. Close the "Preview" dialog. 4. Change the URL to navigate internally to another template (eg `#/edit?id=17&lang=de_DE`). This renders the edit screen again. 5. Click on the "Preview" icon. Before: * It subsequently opens two copies of the "Preview" dialog (each with slightly different options). Initially, you see one dialog. When that close, you will see the other dialog. * As you proceed through closing the dialogs, you may get console warnings because the dialogs have the same name -- and they consequently trip-up each other. After: * It only opens one copy of the "Preview" dialog. Technical Details: * When rendering the setup screen (`#1`/`civicrm#4`), it registers a listener which will handle the "Preview" clicks. But the listener is not properly unregistered. Consequently, old listeners hang around. So the click at step `civicrm#5` calls both the old+new listeners, creating two dialogs.
totten
pushed a commit
that referenced
this pull request
Nov 30, 2021
totten
added a commit
that referenced
this pull request
Nov 30, 2021
…ion-fix)
Overview
--------
Fixes a recent regression that prevents you from uninstalling extensions via
CLI. This specifically affects extensions which use managed entities.
Steps to reproduce
------------------
```
cv en afform
cv dis afform
cv ext:uninstall afform
```
Before
-------
```
[bknix-max:~/bknix/build/dmaster/web/sites/all/modules/civicrm] cv en afform && cv dis afform && cv ext:uninstall afform
Enabling extension "org.civicrm.afform"
Disabling extension "org.civicrm.afform"
Uninstalling extension "org.civicrm.afform"
Error: API Call Failed: Array
(
[entity] => Extension
[action] => uninstall
[params] => Array
(
[keys] => Array
(
[0] => org.civicrm.afform
)
[debug] => 1
[version] => 3
)
[result] => Array
(
[error_code] => unauthorized
[entity] => Extension
[action] => uninstall
[trace] => #0 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(147): Civi\API\Kernel->authorize(Object(Civi\Api4\Provider\ActionObjectProvider), Object(Civi\Api4\Generic\DAODeleteAction))
#1 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/Api4/Generic/AbstractAction.php(234): Civi\API\Kernel->runRequest(Object(Civi\Api4\Generic\DAODeleteAction))
#2 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(85): Civi\Api4\Generic\AbstractAction->execute()
civicrm#3 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(467): civicrm_api4('OptionValue', 'delete', Array)
civicrm#4 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(303): CRM_Core_ManagedEntities->removeStaleEntity(Object(CRM_Core_DAO_Managed))
civicrm#5 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(134): CRM_Core_ManagedEntities->reconcileUnknownModules()
civicrm#6 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(409): CRM_Core_ManagedEntities->reconcile()
civicrm#7 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager.php(483): CRM_Core_Invoke::rebuildMenuAndCaches(true)
civicrm#8 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/v3/Extension.php(183): CRM_Extension_Manager->uninstall(Array)
civicrm#9 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_uninstall(Array)
civicrm#10 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
civicrm#11 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
civicrm#12 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/api.php(22): Civi\API\Kernel->runSafe('Extension', 'uninstall', Array)
civicrm#13 phar:///home/me/bknix/bin/cv/src/Command/BaseCommand.php(49): civicrm_api('Extension', 'uninstall', Array)
civicrm#14 phar:///home/me/bknix/bin/cv/src/Command/ExtensionUninstallCommand.php(63): Civi\Cv\Command\BaseCommand->callApiSuccess(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), 'Extension', 'uninstall', Array)
civicrm#15 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Command/Command.php(257): Civi\Cv\Command\ExtensionUninstallCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
civicrm#16 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(850): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
civicrm#17 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRunCommand(Object(Civi\Cv\Command\ExtensionUninstallCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
civicrm#18 phar:///home/me/bknix/bin/cv/src/Application.php(46): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
civicrm#19 phar:///home/me/bknix/bin/cv/vendor/symfony/console/Application.php(124): Civi\Cv\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
civicrm#20 phar:///home/me/bknix/bin/cv/src/Application.php(15): Symfony\Component\Console\Application->run()
civicrm#21 phar:///home/me/bknix/bin/cv/bin/cv(27): Civi\Cv\Application::main('phar:///Users/t...')
civicrm#22 /home/me/bknix/bin/cv(14): require('phar:///Users/t...')
civicrm#23 {main}
[is_error] => 1
[error_message] => Authorization failed
)
)
```
After
-----
Works
Comment
-------
I encountered this while working on E2E test-coverage for other changes.
The E2E test coverage had worked on a previous iteration of 5.45.alpha1 but
failed when I rebased. Consequently, this means
You can see a prior draft of the E2E test [here](https://github.com/totten/shimmy/blob/master-reorg/shimmy/tests/phpunit/E2E/Shimmy/LifecycleTest.php#L56-L77).
However, it's being reworked as a core patch.
I'd suggest accepting this without a test - because (a) it's a regression and (b) there will be coverage from the pending change.
totten
pushed a commit
that referenced
this pull request
Nov 3, 2022
TypeError: call_user_func(): Argument #1 ($callback) must be a valid callback, non-static method CRM_Case_Page_AJAX::addClient() cannot be called statically
totten
added a commit
that referenced
this pull request
Mar 11, 2023
The `$sqlFile` may or may not be needed, which produces a warning: ``` Deprecated: file_exists(): Passing null to parameter #1 ($filename) of type string is deprecated in /.../tools/bin/scripts/set-version.php on line 105 ```
totten
pushed a commit
that referenced
this pull request
Jul 22, 2023
[PHP Deprecation] trim(): Passing null to parameter #1 () of type string
totten
pushed a commit
that referenced
this pull request
Mar 11, 2024
Gives inline accordion the light utility class
totten
added a commit
that referenced
this pull request
Apr 18, 2024
After running regen, toward the end of the process, there are some warnings like: ``` Generating Membership Generating MembershipPayment Generating MembershipLog Deprecated: strtr(): Passing null to parameter #1 ($string) of type string is deprecated in /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php on line 1563 Call Stack: 0.0035 423192 1. {main}() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:0 1.0962 56966984 2. CRM_Core_CodeGen_GenerateData->generateAll() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:86 2.6564 102240512 3. CRM_Core_CodeGen_GenerateData->generate($itemName = 'MembershipLog') /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:84 2.6564 102240560 4. CRM_Core_CodeGen_GenerateData->addMembershipLog() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:113 2.6592 102261720 5. CRM_Core_CodeGen_GenerateData::repairDate($date = NULL) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1580 30.7495 102266384 6. strtr($string = NULL, $from = ['-' => '', ':' => '', ' ' => '']) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1563 Deprecated: strtr(): Passing null to parameter #1 ($string) of type string is deprecated in /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php on line 1563 Call Stack: 0.0035 423192 1. {main}() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:0 1.0962 56966984 2. CRM_Core_CodeGen_GenerateData->generateAll() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:86 2.6564 102240512 3. CRM_Core_CodeGen_GenerateData->generate($itemName = 'MembershipLog') /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:84 2.6564 102240560 4. CRM_Core_CodeGen_GenerateData->addMembershipLog() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:113 30.7583 102263704 5. CRM_Core_CodeGen_GenerateData::repairDate($date = NULL) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1580 30.7583 102263704 6. strtr($string = NULL, $from = ['-' => '', ':' => '', ' ' => '']) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1563 Generating PCP Generating SoftContribution Generating Pledge Generating PledgePayment ```
totten
added a commit
that referenced
this pull request
Apr 18, 2024
After running regen, toward the end of the process, there are some warnings like: ``` Generating Membership Generating MembershipPayment Generating MembershipLog Deprecated: strtr(): Passing null to parameter #1 ($string) of type string is deprecated in /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php on line 1563 Call Stack: 0.0035 423192 1. {main}() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:0 1.0962 56966984 2. CRM_Core_CodeGen_GenerateData->generateAll() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:86 2.6564 102240512 3. CRM_Core_CodeGen_GenerateData->generate($itemName = 'MembershipLog') /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:84 2.6564 102240560 4. CRM_Core_CodeGen_GenerateData->addMembershipLog() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:113 2.6592 102261720 5. CRM_Core_CodeGen_GenerateData::repairDate($date = NULL) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1580 30.7495 102266384 6. strtr($string = NULL, $from = ['-' => '', ':' => '', ' ' => '']) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1563 Deprecated: strtr(): Passing null to parameter #1 ($string) of type string is deprecated in /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php on line 1563 Call Stack: 0.0035 423192 1. {main}() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:0 1.0962 56966984 2. CRM_Core_CodeGen_GenerateData->generateAll() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/sql/GenerateData.php:86 2.6564 102240512 3. CRM_Core_CodeGen_GenerateData->generate($itemName = 'MembershipLog') /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:84 2.6564 102240560 4. CRM_Core_CodeGen_GenerateData->addMembershipLog() /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:113 30.7583 102263704 5. CRM_Core_CodeGen_GenerateData::repairDate($date = NULL) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1580 30.7583 102263704 6. strtr($string = NULL, $from = ['-' => '', ':' => '', ' ' => '']) /home/totten/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/CodeGen/GenerateData.php:1563 Generating PCP Generating SoftContribution Generating Pledge Generating PledgePayment ```
totten
added a commit
that referenced
this pull request
Aug 29, 2024
Before
------
If you run this test on Standalone, it fails: like so
```
CRM_Activity_BAO_ActivityTest::testSendEmailWillReplaceTokensUniquelyForEachContact3
Exception: CRM_Core_Exception: "rename(/home/homer/buildkit/build/build-1/web/public/custom/test_email_create.txt,
/home/homer/buildkit/build/build-1/web/private/attachment//test_email_create.txt): No such file or directory"
#0 /home/homer/buildkit/build/build-1/web/core/CRM/Contact/Form/Task/EmailTrait.php(867): civicrm_api3("Activity", "create", (Array:9))
#1 /home/homer/buildkit/build/build-1/web/core/CRM/Contact/Form/Task/EmailTrait.php(788): CRM_Contact_Form_Task_Email->createEmailActivity(6, "subject:Mr. Joe Red II", "html:Mr. Joe Red II", "text:Mr. Joe Red II {$contact.first_name}", "", 1, (Array:1), NULL)
...
After
-----
Passes
Comments
--------
I believe this makes standalone behave the same way as Drupal.
However, the underlying scenario is a bit weird -- it seems that `rename()`
puts the file into the same place where it already is. Which is weird.
If the purpose is to create an example file and put it through the same paces as
day-to-day workflows, then you'd probably need to put the sample file somewhere
else (like sys_get_temp_dir()).
totten
pushed a commit
that referenced
this pull request
Sep 5, 2024
CRM_Event_Page_EventInfoTest::testFullMessage
Exception: CRM_Extension_Exception_MissingException: "Failed to find extension: civi_mail"
#0 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Extension/Container/Basic.php(143): CRM_Extension_Container_Basic->getRelPath("civi_mail")
#1 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Extension/Mapper.php(233): CRM_Extension_Container_Basic->getPath("civi_mail")
#2 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Resources.php(261): CRM_Extension_Mapper->keyToBasePath("civi_mail")
civicrm#3 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Resources.php(311): CRM_Core_Resources->getPath("civi_mail")
civicrm#4 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/Civi/Angular/Manager.php(208): CRM_Core_Resources->glob("civi_mail", (Array:3))
civicrm#5 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/Civi/Angular/Manager.php(114): Civi\Angular\Manager->resolvePatterns((Array:59))
civicrm#6 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check/Component/Env.php(1178): Civi\Angular\Manager->getModules()
civicrm#7 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check/Component.php(76): CRM_Utils_Check_Component_Env->checkAngularModuleSettings(FALSE)
civicrm#8 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(215): CRM_Utils_Check_Component->checkAll((Array:0), FALSE)
civicrm#9 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(185): CRM_Utils_Check::checkStatus()
civicrm#10 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(93): CRM_Utils_Check::checkAll()
civicrm#11 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Page.php(267): CRM_Utils_Check->showPeriodicAlerts()
civicrm#12 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Event/Page/EventInfo.php(325): CRM_Core_Page->run()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This resolves many of the problems with the api explorer in core, but unfortunately I got stuck and it still doesn't work. The page now loads angular but is still a WSOD, with this cryptic error message in the console: