CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/issues2022-11-16T20:07:08Zhttps://lab.civicrm.org/dev/core/-/issues/3982SearchKit: dropdowns for country and state don't work2022-11-16T20:07:08Zaydunsaidan.saunders@squiffle.ukSearchKit: dropdowns for country and state don't workOverview
----------------------------------------
In SearchKit, the dropdowns for 'Address (primary) Country', 'Address (billing) Country', 'Address (primary) State/Province', 'Address (billing) State/Province' don't work.
Reproduction ...Overview
----------------------------------------
In SearchKit, the dropdowns for 'Address (primary) Country', 'Address (billing) Country', 'Address (primary) State/Province', 'Address (billing) State/Province' don't work.
Reproduction steps
----------------------------------------
1. Create a new SearchKit search
2. Search for Contacts
3. Add 'Where': 'Address (primary) Country' '='
Current behaviour
----------------------------------------
The Country list dropdown just spins and does not complete.
![image](/uploads/756beb13ac0db4147fb703d2dc37692b/image.png)
Expected behaviour
----------------------------------------
List of countries
Environment information
----------------------------------------
* __CiviCRM:__ _Master_colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3981Example data leaks from the live database2022-11-11T02:29:04ZeileenExample data leaks from the live databaseThe example data has been adding a pseudo-contact-id. However, if a token is used that is not in the example data it resolves to a 'real live' contact's data.
e.g the contact ID for 'Barb' in the sample data is 100
In my current develo...The example data has been adding a pseudo-contact-id. However, if a token is used that is not in the example data it resolves to a 'real live' contact's data.
e.g the contact ID for 'Barb' in the sample data is 100
In my current developer database Contact 100 is 'Pennsylvania Action Partnership'
![image](/uploads/d394dd447748aca86a4b752c903e5ffc/image.png)
If I go to view the contribution invoice and replace the subject with the token for 'addressee' there is no defined value for 'Barb' so it goes to the database & resolves the value for contact 100.
![image](/uploads/3b2b66050b0c08369cd2dc20d074479b/image.png)
![image](/uploads/fd1024d0ef6042ef853c45387906153b/image.png)
I tried to understand why there is a pseudo-contact-id and I can think of two reasons
1) perception a placeholder value would be less confusing.
2) something didn't work otherwise.
I tried changing the 100 to 0 and apart from tests with a specific expectation it appears to work. Arguably another false value would be better - but it would have to be REALLY BIG to be sure no-one's db has it & I think you could just as well make the case that 0 is less confusing.5.56.0https://lab.civicrm.org/dev/core/-/issues/3980SearchKit displays: be able to add description so end user knows the context2022-11-21T19:39:52ZherbdoolSearchKit displays: be able to add description so end user knows the contextCurrently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results ...Currently on SearchKit displays we can set the name which ends up being used for the title and the URL. I've tried to add additional information there for end users so they understand the context of the results. E.g. "Only shows results for the current campaign". But that's awkward to stuff that all into the title. And also means one has to be careful that on the first save *not* to add those notes to the name so as to prevent an ungainly URL.
(The other option is to embed the SK into an afform, but that's a lot of extra work for just a bit of description.)
So a separate description field would be ideal.https://lab.civicrm.org/dev/core/-/issues/3979civi/core/Locale->uf doesn't get set usually2022-11-23T18:18:41ZDaveDcivi/core/Locale->uf doesn't get set usuallyThis started as what I thought was a simple php 8.1 warning: `CRM_Core_I18n::singleton()->setLocale('en_US')` gives one of those "don't pass null as a string parameter" warnings. But then I looked into a bit.
1. Unit tests don't catch t...This started as what I thought was a simple php 8.1 warning: `CRM_Core_I18n::singleton()->setLocale('en_US')` gives one of those "don't pass null as a string parameter" warnings. But then I looked into a bit.
1. Unit tests don't catch this because the error is happening when [setting the UF locale](https://github.com/civicrm/civicrm-core/blob/98b99133c1b5b8f7c093c8426f26316444420695/CRM/Utils/System/DrupalBase.php#L453), and in the unit test UF it [doesn't do anything](https://github.com/civicrm/civicrm-core/blob/98b99133c1b5b8f7c093c8426f26316444420695/CRM/Utils/System/Base.php#L519).
2. The only way the parameter is not null is if the `uf` member of \Civi\Core\Locale gets set. But that only happens when code is doing things in a way that nobody (currently) does things. It doesn't happen by calling `CRM_Core_I18n::singleton()->setLocale()`.
3. In drupal 7 in a stock install, these get swallowed and don't even appear on screen. You can see them if you comment out [this line](https://git.drupalcode.org/project/drupal/-/blob/9f59535277d2bcaf7ad4555b12e62ddc4fac372f/includes/bootstrap.inc#L2692), and then do e.g. `cv ev "CRM_Core_I18n::singleton()->setLocale('en_US');"`.
4. Looks like it's from https://github.com/civicrm/civicrm-core/commit/1190626dc6669a5a9242ab788a64d058e42dd9cb.
5. I'm a little scared to touch setLocale().5.56.0tottentottenhttps://lab.civicrm.org/dev/core/-/issues/3978Sample data price sets not showing correctly2022-11-17T22:54:04ZeileenSample data price sets not showing correctlyPer https://lab.civicrm.org/dev/core/-/issues/3685#note_83376
Note the issue is the FinancialType ACls require a financial type ID - it should be there BUT the financial type ID code should not require itPer https://lab.civicrm.org/dev/core/-/issues/3685#note_83376
Note the issue is the FinancialType ACls require a financial type ID - it should be there BUT the financial type ID code should not require it5.55.2https://lab.civicrm.org/dev/core/-/issues/3977Payment processor handling of `billing-country-5` inconsistent2022-11-11T02:07:08ZeileenPayment processor handling of `billing-country-5` inconsistentThis is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pu...This is a follow on from https://lab.civicrm.org/dev/core/-/issues/3918 / https://github.com/civicrm/civicrm-core/pull/24232 / https://github.com/civicrm/civicrm-core/pull/24903
The original PR https://github.com/civicrm/civicrm-core/pull/24903 did not explain what problem was being solved & it didn't come out in the review process.... so I think in the first instance we should establish that.
This is my best guess to reverse engineer the point of the original change ...
All calls to `doPayment` are expected to pass through the documented parameters https://docs.civicrm.org/dev/en/latest/extensions/payment-processors/create/#billing-fields - in this case the relevant parameter is `billing_country-5`. That parameter is a bit of a pig so some/ most code ALSO passes `country` - and this seems to be done consistently enough that `Paypal` and `Authorize.net` (our oldest processors) are using `country`.
I do think it is important that when payment processors are sending out an array the contract of what keys they should pass out is clear. If we want to deprecate `billing_country-5` in favour of 'country' that seems OK (we would need to update the docs) - but at the moment there seems to be some code that passes `country` in a format that is not correct - which led to the regression.
I feel like in the first instance we should find & fix (with tests) the reported instances of that that came up in https://lab.civicrm.org/dev/core/-/issues/3918
Looking at the code for `setBillingCountry` and the validation - I have a feeling that code may only be hit from the unit tests? In which case the case for reducing the validation seems strong enough.
One thing we COULD do in the test suite is register a hook on all unit tests for `alterPaymentProcessor` & validate the `country` field in it - that might track down any errant ones
I should note that `PropertyBag` isn't a subsitute for us fixing core code to pass the contract parameters5.56.0https://lab.civicrm.org/dev/core/-/issues/3976Upgrades slow as a result of snapshot code2022-11-10T06:58:52ZeileenUpgrades slow as a result of snapshot codeThe addition of the snapshot code causes queries to run that are slow on a large database - eg. `SELECT COUNT(*) FROM civicrm_contact` - this is for a database update with NO changes to any of the large tables it is doing slow queries on...The addition of the snapshot code causes queries to run that are slow on a large database - eg. `SELECT COUNT(*) FROM civicrm_contact` - this is for a database update with NO changes to any of the large tables it is doing slow queries on.
All the messaging about the snapshot is about how to turn it ON - not about how to stop it from doing it's 'activation test'
Note the test is an arbitrary check on the size of some tables thought to possibly signal a large database - but then it turns it ALL off or ALL on after some slow queries. This means the sorts of updates we would have found this useful on (scheduled reminders) may be unnecessarily de-activated.
@tottenhttps://lab.civicrm.org/dev/core/-/issues/3975Search kit does not refresh correctly on delete2022-11-27T23:27:08ZeileenSearch kit does not refresh correctly on deleteTo reproduce - start with the below search (I don't think the search is 'special' - just where I hit it)
- go to the LAST page
- Note the number of rows in the total
- ![image](/uploads/a4ad196fbacefe1b79a7d4cb6aa1ede9/image.png)
- use ...To reproduce - start with the below search (I don't think the search is 'special' - just where I hit it)
- go to the LAST page
- Note the number of rows in the total
- ![image](/uploads/a4ad196fbacefe1b79a7d4cb6aa1ede9/image.png)
- use an action to delete the last record
- Note the new count
- ![image](/uploads/26b3429dab37d1c4baf02923464b3b4a/image.png)
```
[
[
"SavedSearch",
"save",
{
"records": [
{
"name": "languages",
"label": "languages",
"form_values": null,
"mapping_id": null,
"search_custom_id": null,
"api_entity": "OptionValue",
"api_params": {
"version": 4,
"select": [
"id",
"label",
"value",
"name"
],
"orderBy": [],
"where": [
[
"option_group_id:name",
"=",
"languages"
]
],
"groupBy": [],
"join": [],
"having": []
},
"expires_date": null,
"description": null
}
],
"match": [
"name"
]
}
]
]
```colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/3974PHP8: fatal error when viewing event info page with OpenStreetMaps as mapping...2022-11-07T23:25:39ZJonGoldPHP8: fatal error when viewing event info page with OpenStreetMaps as mapping provider and a location with no geocode### Replication Steps
* On PHP 8.1, configure Civi with OpenStreetMaps as the Mapping Provider, but no (working) geocoding provider. On a civibuild site, setting *Geocoding Provider* to **Google** will do the trick.
* Edit an event to c...### Replication Steps
* On PHP 8.1, configure Civi with OpenStreetMaps as the Mapping Provider, but no (working) geocoding provider. On a civibuild site, setting *Geocoding Provider* to **Google** will do the trick.
* Edit an event to create a new address (which won't have a geocode since geocoding is disabled).
* Configure the event to show a map.
* Go to the Event Info page.
### Expected Result
No map, because no geocode.
### Actual Result
Fatal Error.
### Comments
This happens because of this line in `<civiroot>/templates/CRM/Contact/Form/Task/Map/OpenStreetMaps.tpl`:
```
{if count($locations) gt 1}
```
It expects `$locations` to always be set.
I imagine an alternative solution is to add an `isset()` to the template. I can do the other fix if preferred though.5.57.0JonGoldJonGoldhttps://lab.civicrm.org/dev/core/-/issues/3973SearchKit: be able to choose *which* Actions are available on a display2023-03-02T16:50:05ZherbdoolSearchKit: be able to choose *which* Actions are available on a displayThe Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that sh...The Actions for SearchKit displays seem to be automatically chosen based on the entities. And it's an all or nothing deal. In my case, I was hoping to allow staff to *only* download the results and nothing else. But there a bunch that show up, including delete, update. Even if the search is using a GROUP BY, which doesn't make much sense I think.https://lab.civicrm.org/dev/core/-/issues/3972SearchKit: allow custom fields to be used in the JOIN conditions (like they'r...2023-03-29T15:54:36ZherbdoolSearchKit: allow custom fields to be used in the JOIN conditions (like they're available in where)As far as I can tell, the custom fields on the entity that is joined are not available for the JOIN conditions. But they are visible in the WHERE.
Here's a scenario: there's a custom field on a contact. Create a new SearchKit with prima...As far as I can tell, the custom fields on the entity that is joined are not available for the JOIN conditions. But they are visible in the WHERE.
Here's a scenario: there's a custom field on a contact. Create a new SearchKit with primary being Address. Then JOIN the Contact. Add a condition for the join and search the contact's custom field. It's not available. Then check for that same custom field in the WHERE - it should be available.
This is useful when using GROUP BY and cannot use the WHERE. And where it would be inconvenient/impossible to add the field as a column and use HAVING. For example, if the added field has a transformation to COUNT then HAVING won't help.https://lab.civicrm.org/dev/core/-/issues/3971SearchKit data segmentation: add Clone and Export actions2022-11-10T07:04:03ZherbdoolSearchKit data segmentation: add Clone and Export actionsCurrently there are Edit and Delete actions. It would be useful to also have Clone and Export actions, just like the main SearchKit tab.Currently there are Edit and Delete actions. It would be useful to also have Clone and Export actions, just like the main SearchKit tab.https://lab.civicrm.org/dev/core/-/issues/3970SearchKit data segmentation: ability to AND/OR conditions per item2022-11-10T16:53:45ZherbdoolSearchKit data segmentation: ability to AND/OR conditions per itemI'm guessing that the conditions are currently AND. I have a use case for needing an OR if this is possible.
For example, a field either has a specific string OR that same field is blank.I'm guessing that the conditions are currently AND. I have a use case for needing an OR if this is possible.
For example, a field either has a specific string OR that same field is blank.https://lab.civicrm.org/dev/core/-/issues/3969Notice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civi...2023-01-17T02:01:54ZyodatakNotice: Undefined offset: 1 in /var/www/html/civicirm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
N...Overview
----------------------------------------
I got this error showing in civicrm on PHP7.4 and civicrm 5.55.0, Wordpres 6.1 , Nginx
Reproduction steps
----------------------------------------
Go to a report and on top this show
Notice: Undefined offset: 1 in /var/www/html/civicrm/wp-content/plugins/civicrm/civicrm/CRM/Utils/Date.php on line 908https://lab.civicrm.org/dev/core/-/issues/3968unsupported operand types in BAO/Navigation.php, orderByWeight2022-11-07T10:27:07Zsebalisunsupported operand types in BAO/Navigation.php, orderByWeightHi,
when trying out if a Wordpress+Civi test instance would survive a PHP upgrade to 8.0, I found that the CiviCRM menu had gone missing. It turned out that a fatal PHP error occured in the AJAX call that retrieves the menu structure. I...Hi,
when trying out if a Wordpress+Civi test instance would survive a PHP upgrade to 8.0, I found that the CiviCRM menu had gone missing. It turned out that a fatal PHP error occured in the AJAX call that retrieves the menu structure. It originated in line 323 of CRM/Core/BAO/Navigation.php, which is in the orderByWeight function:
`return $a['attributes']['weight'] - $b['attributes']['weight'];`
Perhaps PHP 8 is treating such issues more seriously than 7 – sorry but I simply don’t know. In any case, I was able to overcome this by adding explicit type casts:
`return (int) $a['attributes']['weight'] - (int) $b['attributes']['weight'];`
This was complete guesswork and maybe I should have cast to float instead – again, I don’t know. But I thought this might be worth reporting so you can decide how to best safeguard that line. For now I am happy to have my menu back with this temporary and local patch.
By the way, this was observed in version 5.54.1 but I notice that the line is unchanged in the master, 5.55 and 5.56 branches.5.56.0https://lab.civicrm.org/dev/core/-/issues/3967Deduping with multiple fields doesn't work with more than 999 contacts using ...2022-11-04T19:17:46ZlarsssandergreenDeduping with multiple fields doesn't work with more than 999 contacts using MariaDB 10.3+After upgrading to MariaDB 10.3 or later, finding dupes with a rule than uses multiple fields creates queries that runs for hours when checking 1000 contacts, but works fine for 999 contacts.
Here are the steps to replicate:
- MariaDB 1...After upgrading to MariaDB 10.3 or later, finding dupes with a rule than uses multiple fields creates queries that runs for hours when checking 1000 contacts, but works fine for 999 contacts.
Here are the steps to replicate:
- MariaDB 10.3+
- Create a dedupe rule with First Name and Last Name
- Use the rule on a group with 1000 or more contacts (or use the Deduper extension to limit to 1000 contacts)
- Result: query runs for a very long time
- Use the rule on a group with 999 or fewer contacts
- Result: results returned quickly as expected
Turns out this is due to a setting that was added to MariaDB in 10.3: [In Predicate Conversion Threshold](https://mariadb.com/docs/reference/mdb/system-variables/in_predicate_conversion_threshold/), which converts the long list of ids in the query that CiviCRM builds to a temp table when the length of the list of ids exceeds the setting, which is 1000 by default. Changing the setting to 0 fixes the issue by disabling the conversion.
Not clear why the temp table is so slow. I'm going to try creating temp tables with indexes explicitly to see if that helps. If not and nothing else suggests itself as a solution, will at least add some documentation unless others have thoughts on how to resolve this so it doesn't require adjusting settings for everyone using MariaDB.https://lab.civicrm.org/dev/core/-/issues/3966Contact ID, External ID and CRM User ID should only be shown once on the cont...2022-11-10T07:07:58ZlarsssandergreenContact ID, External ID and CRM User ID should only be shown once on the contact pageCurrently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm...Currently, out of the box, Contact ID and External ID are shown both in the Contact footer, which is visible on all Contact tabs and in the ID, Type, Tags block which is shown on the Contact Summary tab. [A PR](https://github.com/civicrm/civicrm-core/pull/24883) will add CRM User ID to the footer as well.
![image](/uploads/4aa3cf01bb4ed418a9c8aaae4ee30dd5/image.png)
I think we should not be duplicating this data on the Contact page. Either it should be shown in a block or it should be shown in the footer, but not both by default as that just wastes space and contributes to an overly busy UI that discourages adoption of CiviCRM.
I think it makes sense to separate the Tags block from the IDs and Contact Type block, as these are very different pieces of data and some may want to see one and not the other.
Some options:
1) Show Contact ID, CRM User ID, External ID and Contact Type in the footer. Remove the Summary tab block with these items, leaving just the Tags block. Or, if we want to give people the option to show the IDs and Contact Type as a block, keep it available, but not visible by default (like the Open ID block, which still exists, but isn't shown by default on new installs). The downside of showing this data in the footer is it is not configurable like the blocks are. The advantage is that the footer is less prominent than a block, which fits with the lower importance of this data, and the footer is visible on all Contact tabs, not just the Summary.
2) Remove all of these items from the footer and only show them in a block.
3) Make the footer only visible to those with Administer CiviCRM permission (as a convenience for admins) and also show the IDs in a block for everyone.
4) Keep everything as is, there are good reasons to duplicate this information.https://lab.civicrm.org/dev/core/-/issues/3965Adding mailing events (unsub, open, clicks, etc) to API42023-10-16T00:28:23ZlarsssandergreenAdding mailing events (unsub, open, clicks, etc) to API4I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Even...I'd like to add mailing events to API4 so we can use them in SearchKit, to improve the A/B Mailing report page, and so on.
This would be all the [Mailing Events here.](https://github.com/civicrm/civicrm-core/tree/master/CRM/Mailing/Event/DAO) Not sure they are all essential, but might as well do them all at once, as they will all be very similar.
Having poked around at this, I see a few issues that I think I need some help with before starting on this.
We have, for example, TrackableURLOpen, which links to a TrackableURL and also to the Queue entity, which links to the Job entity, which links to the Mailing entity. I don't think we want to have users building queries with joins on all of these entities in SearchKit in order to get useful information back. Ideally, we'd have an entity that has a get action that would return:
- id from TrackableURLOpen
- timestamp from TrackableURLOpen
- URL from TrackableURL
- contact id from Queue
- mailing id from Job
Can we do this by adding all these entities to the API, adding entity bridges to connect them all and then adding an abstract entity that wraps everything up together, with a get function that gets all the fields above from the API (and a getfields function as well). Or is there a less manual way to do this?
Also, I see that the Queue entity already exists in API4, but it isn't the Mailing_Event_Queue entity. Is there a way to specify the full class for an entity so that we don't get a collision? It looks like it just expects the last word from the classname as the API class and that won't work in this case. This might be helpful in general here, because adding an entity called just Opened is going to be confusing (versus naming it something like MailingEventOpened).https://lab.civicrm.org/dev/core/-/issues/3964Activity import: source_record_id field not importable2022-12-12T16:43:41ZSandor SemseyActivity import: source_record_id field not importableOverview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to th...Overview
---
During activity import (**Contacts >> Import Activities**) Source Record ID field cannot be mapped and imported. In my understanding that is because this field is not marked as importable. If I add the `import => TRUE` to the relevant DAO, `source_record_id` can be mapped and imported successfully.
I haven't found any references except for this unresolved StackExchange question (https://civicrm.stackexchange.com/questions/33639/importing-signatures-into-petition) and a related issue (https://lab.civicrm.org/dev/core/-/issues/1380) where the OP wants to import petition signatures into Civi.
I checked the oldest available version of Civi on GitHub and this field wasn't marked as importable even then. So this seems quite historical.
I wonder, is there any reasons why this field can't be imported?
Example use-case
---
Importing petition signatures from other systems to CiviCRM.
Current behaviour
---
Not possible to import `source_record_id` for activities.
Proposed behaviour
---
Possible to import `source_record_id` for activities.
Comments
---
I'm happy to open a PR if it gets approved.https://lab.civicrm.org/dev/core/-/issues/3963Mix of auto renewing membership types and non-auto renewing membership types ...2024-03-15T21:08:28ZEdselopezMix of auto renewing membership types and non-auto renewing membership types not handled properly in pricesets.Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue ...Overview
----------------------------------------
On a membership price set, it is possible to specify a mix of auto renewing memberships as well as non auto renewing memberships, but allow the selection of only one at a time (by virtue of it being a radio select). It seems CiviCRM doesn't know how to handle this properly, as it assumes that multiple options can be selected.
The code here https://github.com/civicrm/civicrm-core/blob/master/CRM/Price/BAO/PriceSet.php#L1290 seems to fetch the HTML type (which should be the deciding factor on if the payment processor is compatible with handling multiple concurrent transactions) but doesn't really do anything with it.
Reproduction steps
----------------------------------------
1. Create a membership price set
2. Add a price field of type radio
3. Proceed to create selections having membership types selected, but be sure to include a mix of auto renewing membership types and non-auto renewing membership types
4. Add the price field on a contribution page and click save.
Current behaviour
----------------------------------------
(I have tested this for PayPal - Website Payments Standard, but it should be replicable for any payment processor which doesn't support "MultipleConcurrentPayments".
Error shown when trying to save
"Price Set
The membership price set associated with this online contribution allows a user to select BOTH an auto-renew AND a non-auto-renew membership. This requires submitting multiple processor transactions, and is not supported for one or more of the payment processors enabled under the Amounts tab."
Expected behaviour
----------------------------------------
The contribution form should recognize that the price field is a single select field, and therefore allow me to save the configuration.
Environment information
----------------------------------------
* __Browser:__ _Firefox 59.0.1/Chrome 78.0.3904/Safari 13_
* __CiviCRM:__ _Master/5.20.0/5.19.1/5.18.2/..._ <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP:__ _7.0/7.1/7.2/7.3/...__
* __CMS:__ _Backdrop 1.5/Drupal 7.30/Joomla 3.3/WordPress 4.5/..._
* __Database:__ _MySQL 5.7.7/MariaDB 10.4/..._
* __Web Server:__ _Apache 2.4/Nginx 1.16/..._5.69.5seamusleeseamuslee