Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Further test fixes #1

Merged
merged 1 commit into from
Oct 10, 2016
Merged

Conversation

seamuslee001
Copy link
Collaborator

No description provided.

@colemanw colemanw merged commit 4335f07 into colemanw:CRM-19448-fix Oct 10, 2016
colemanw pushed a commit that referenced this pull request Aug 25, 2017
Regenerate DAOs and Upgrade step to fix current installs
colemanw pushed a commit that referenced this pull request Sep 13, 2017
There appears to be some application logic which follows a process like this:

 1. Read the case
 2. Tweak the data
 3. Save updated case

The problem is comes if step #4 resaves a timestamp loaded in step #1, which
is fairly likely to happen if you read+save the same record.

This was specifically observed on the "Manage Case" screen when editing
activities, but the data-flow is pretty common, so make a general fix to the
BAO.
colemanw pushed a commit that referenced this pull request Feb 9, 2019
Update master from upstream
colemanw pushed a commit that referenced this pull request Mar 14, 2019
…ct PSR-16

Suppose someone calls `ArrayDecorator::get()` or `FastArrayDecorator::get()`
with an invalid key (e.g.  passing `float` or an `array` instead of a
`string`).  This patch improves error-reporting for that scenario.

This is primarily about fixing multiple test failures in `E2E_Cache_ArrayDecoratorTest` reported on `wp-demo`. These
generally look like

```
1) E2E_Cache_ArrayDecoratorTest::testGetInvalidKeys with data set #1 (true)
array_key_exists(): The first argument should be either a string or an integer

/Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm/CRM/Utils/Cache/ArrayDecorator.php:102
/Users/totten/bknix/build/wpmaster/wp-content/plugins/civicrm/civicrm/packages/Cache/IntegrationTests/LegacySimpleCacheTest.php:409
/Users/totten/bknix/civicrm-buildkit/extern/phpunit5/phpunit5.phar:598
```

Before
------

The ArrayDecorator first checks its front cache (`array_key_exists`) to see if the key is defined.  In the `wp-demo`
environment, this produces a warning and causes the test to fail.

The condition *is* erroneous, but PSR-16 specifies that the error should be reported as exception.

After
-----

The condition is reported as the expected exception. The test passes on `wp-demo`.

Comment
-------

This brings the code in `(Fast)ArrayDecorator.php` into alignment with most of the other `CRM/Utils/Cache/*.php`
drivers; in most drivers, it is typical to validate the key at the start of most functions.
colemanw pushed a commit that referenced this pull request May 27, 2019
colemanw pushed a commit that referenced this pull request Jun 11, 2019
This avoids fails when the expectations were calculated right at the end of a day but then are compared with the new day's values.

Results in this case look like

CRM_Report_FormTest::testGetFromTo with data set #1 ('20190606000000', '20190606235959', 'this.day', '', '')
fail on data set [ this.day ,  ,  ]. Local php time is 2019-06-07 00:00:13 and mysql time is 2019-06-07 00:00:13
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => '20190606000000'
-    1 => '20190606235959'
+    0 => '20190607000000'
+    1 => '20190607235959'
colemanw pushed a commit that referenced this pull request Aug 5, 2019
colemanw pushed a commit that referenced this pull request Aug 26, 2019
dev/core#1186 add in unit test to lock in fix from dmeritcowboy in #1
colemanw pushed a commit that referenced this pull request Oct 26, 2019
Updating Fork with Commits on Base
colemanw pushed a commit that referenced this pull request Nov 11, 2019
Proposed updates to Gitlab issue template
colemanw pushed a commit that referenced this pull request Feb 19, 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')
  #3 /home/me/.../Civi/Core/Paths.php(224): Civi\Core\Paths->getVariable('civicrm.root', 'path')
  #4 /home/me/.../Civi/Core/Paths.php(84): Civi\Core\Paths->getPath('l10n')
  #5 [internal function]: Civi\Core\Paths->Civi\Core\{closure}()
  #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.
colemanw pushed a commit that referenced this pull request Sep 4, 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 `#3`. The patch changes it to `#4`.

Both splits achieve backward compatibility wrt `Resources::addScriptUrl()`
and `Region::add(scriptUrl)`.  The difference is that `#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 `#3`.
colemanw pushed a commit that referenced this pull request Oct 9, 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
----------------------------------------
colemanw pushed a commit that referenced this pull request Oct 24, 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...)
colemanw pushed a commit that referenced this pull request Mar 16, 2021
colemanw pushed a commit that referenced this pull request Oct 11, 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`/`#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 `#5` calls both the old+new listeners, creating two dialogs.
colemanw pushed a commit that referenced this pull request Dec 1, 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()
 #3 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(467): civicrm_api4('OptionValue', 'delete', Array)
 #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))
 #5 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/ManagedEntities.php(134): CRM_Core_ManagedEntities->reconcileUnknownModules()
 #6 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Core/Invoke.php(409): CRM_Core_ManagedEntities->reconcile()
 #7 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/CRM/Extension/Manager.php(483): CRM_Core_Invoke::rebuildMenuAndCaches(true)
 #8 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/api/v3/Extension.php(183): CRM_Extension_Manager->uninstall(Array)
 #9 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_extension_uninstall(Array)
 #10 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(149): Civi\API\Provider\MagicFunctionProvider->invoke(Array)
 #11 /home/me/bknix/build/dmaster/web/sites/all/modules/civicrm/Civi/API/Kernel.php(81): Civi\API\Kernel->runRequest(Array)
 #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.
colemanw pushed a commit that referenced this pull request Oct 29, 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
colemanw pushed a commit that referenced this pull request Mar 13, 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
```
colemanw added a commit that referenced this pull request Jul 21, 2023
colemanw pushed a commit that referenced this pull request Jul 21, 2023
[PHP Deprecation] trim(): Passing null to parameter #1 () of type string
colemanw pushed a commit that referenced this pull request Oct 24, 2023
colemanw pushed a commit that referenced this pull request Mar 6, 2024
Gives inline accordion the light utility class
colemanw pushed a commit that referenced this pull request Apr 19, 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
```
colemanw pushed 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()).
colemanw pushed a commit that referenced this pull request Sep 8, 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")
#3 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Resources.php(311): CRM_Core_Resources->getPath("civi_mail")
#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))
#5 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/Civi/Angular/Manager.php(114): Civi\Angular\Manager->resolvePatterns((Array:59))
#6 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check/Component/Env.php(1178): Civi\Angular\Manager->getModules()
#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)
#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)
#9 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(185): CRM_Utils_Check::checkStatus()
#10 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Utils/Check.php(93): CRM_Utils_Check::checkAll()
#11 /home/homer/buildkit/build/build-3/web/sites/all/modules/civicrm/CRM/Core/Page.php(267): CRM_Utils_Check->showPeriodicAlerts()
#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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants