Development issueshttps://lab.civicrm.org/groups/dev/-/issues2024-03-12T13:25:50Zhttps://lab.civicrm.org/dev/core/-/issues/5074Standalone installer header squished on wide screens2024-03-12T13:25:50ZufundoStandalone installer header squished on wide screensOn screens wider than 2000px the installer title overlaps the logo:
![image](/uploads/5bdae7eb821fc67c637939d2abc7f983/image.png)
Minor but it's not the best intro for new people to CiviCRM!
(Maybe it is a good intro :eyes: )On screens wider than 2000px the installer title overlaps the logo:
![image](/uploads/5bdae7eb821fc67c637939d2abc7f983/image.png)
Minor but it's not the best intro for new people to CiviCRM!
(Maybe it is a good intro :eyes: )https://lab.civicrm.org/dev/core/-/issues/5073Standalone default folder structure2024-03-08T10:24:03ZufundoStandalone default folder structureSome wise suggestions from @artfulrobot for clearer folder naming / out-of-the-box security:
> ```
> - civicrm-standalone-X.Y.Z.zip
> - index.php
> - .htaccess
> - robots.txt ➌
> - data/
> - data/ext/....Some wise suggestions from @artfulrobot for clearer folder naming / out-of-the-box security:
> ```
> - civicrm-standalone-X.Y.Z.zip
> - index.php
> - .htaccess
> - robots.txt ➌
> - data/
> - data/ext/.htaccess
> - data/public/.htaccess ➊
> - data/.private/.htaccess ➋
> - core/<ALL-THE-CODES>
> ```
>
> 1. use 'public' not 'upload'. It partners well with 'private', and 'upload' is such a daft relative-to-what? term (not everything you upload through a browser ought to be in a public dir). I think the whole 'persist' 'contribute' etc. is a right mess - or at least I don't understand the logic if there is logic, though last time I looked at it the logic was that at some point in history the first thing to allow uploads was civi contribute so ...
>
> 2. use a dot before _private/_. It's very common, and easy, to ban http access to all 'dot files'. So this gives an extra _likely_ shield against the "oh, I didn't realise nginx ignored .htaccess files" users. Just feels safer, if we're focussing on making this easy.
>
> 3. In terms of sensible defaults, I feel we should have a robots.txt that does its best to ban crawlers, especially AI ones, on everything except specific paths (e.g. event pages). It's one thing to have someone tell you you've accidentally exposed data and someone saw it, it's another to find that your [exposed data now lives in an LLM](https://arstechnica.com/information-technology/2022/09/artist-finds-private-medical-record-photos-in-popular-ai-training-data-set/) training set, ready to be given to anyone with a particular prompt.
Maybe to the nginx point, we could add `nginx-civicrm-site.conf.sample` in the root?
I think the principles for the public / private upload folder names apply to the composer template and the tarball.ufundoufundohttps://lab.civicrm.org/dev/core/-/issues/5072SearchKit: Ghost custom data2024-03-12T15:46:29ZfrancescbassasSearchKit: Ghost custom dataHow to reproduce:
1. Create a custom field for a membership type.
2. Create a membership type and fill the custom field.
3. Change the membership type for the previous membership. Membership no longer have custom field, at least at UI l...How to reproduce:
1. Create a custom field for a membership type.
2. Create a membership type and fill the custom field.
3. Change the membership type for the previous membership. Membership no longer have custom field, at least at UI level, data remains in database tables.
4. Create a SearchKit to list memberships and custom field created in step 1.
5. The SearchKit results show data for non-applicable field for the membership created in step 2.
I suspect it's applicable for custom data groups associated with other entities (contact subtypes, participants, etc)https://lab.civicrm.org/dev/user-interface/-/issues/70Test & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)2024-03-07T13:51:41ZnicolTest & resolve final accordion markup pattern rewrite: CRMDashlet (pattern 2)The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons f...The accordion issue #60 has just one pattern left remaining, which appears in one part of CiviCRM, the dashboard. This is more complex than other accordions as the summary bar needs to be drag-and-drop, as well as have function buttons for refresh, close, and expand-to-modal.
There's a WIP PR for it here: https://github.com/civicrm/civicrm-core/pull/29613 – which has two outstanding issues:
- the expand-to-modal duplicates the title.
- the refresh js in `crmDashlet.component.js` needs to be updated
In addition, testing needs to confirm on several CMS the following still work:
- [ ] drag,
- [ ] drop,
- [ ] expand fullscreen,
- [ ] expand/collapse accordion,
- [ ] refresh,
- [ ] remove dashlet
- [ ] inactive dashlet state (when clicking 'available dashlet')Improve Civi's front-endhttps://lab.civicrm.org/dev/core/-/issues/5070Contribution pending status wrong2024-03-07T18:16:21Zaydunsaidan.saunders@squiffle.ukContribution pending status wrong## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact...## Overview
After creating a Pending Contribution it lists as `Pending (Incomplete Transaction)`, not `Pending (Pay Later)`, but editing and saving with no changes causes it to show correctly.
## Reproduction steps
1. Choose a contact.
2. `Actions` \> `Add Contribution` (or `Contributions` tab \> `Record Contribution`, or API4)
3. Choose any Financial Type and Amount, set Status to `Pending`
4. View the Contributions list
## Current behaviour
The status shows as `Pending (Incomplete Transaction)`
Then `Edit` the contribution, don't make any changes, just hit `Save`
Note that the status is now `Pending (Pay Later)`
## Expected behaviour
Should be `Pending (Pay Later)`
## Environment information
* **CiviCRM:** _Master & 5.70.0 - maybe others_
Reproducible on dmaster.demo.civicrm.org
## Comments
_See_ https://chat.civicrm.org/civicrm/pl/qcmoueddmfbm7bpfq4uauympcwhttps://lab.civicrm.org/dev/core/-/issues/5069standalone: permanent "session already active" errors2024-03-11T20:22:55ZRichstandalone: permanent "session already active" errorsEvery page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* sessi...Every page, including the login form has:
* session_set_save_handler(): Session save handler cannot be changed when a session is active [2]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 567
* session_start(): Ignoring session_start() because a session is already active [8]
/var/www/standalone.localhost/web/core/CRM/Utils/System/Standalone.php line 580
I first encountered this while reviewing https://github.com/civicrm/civicrm-core/pull/29352 but after experiencing it once, I could not get it to repeat, so thought it was a random local thing. But now it's back.
I have some installs that don't have it, and others that do; I'm trying to figure out how to reproduce/what makes the difference.https://lab.civicrm.org/dev/core/-/issues/5068Do we need the qfkey in group urls?2024-03-07T13:49:27ZAndrew WestDo we need the qfkey in group urls?My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace tha...My users are forever emailing each other broken links to Civi groups, due to the qfkey in the URL. This doesn't seem to be needed in most of the rest of Civi - is it worth my investigating how to remove it? Or would we aim to replace that page with a search kit version soon anyway?https://lab.civicrm.org/dev/core/-/issues/5067Docker image - initial version2024-03-08T09:40:10ZMichael McAndrewDocker image - initial versionFor the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future...For the initial image, we will focus on CiviCRM Standalone with a simple implementation of layer 3 (see #5066). While we are retaining a narrow focus for the initial release, the Design principles and scope #5066 are an attempt to future proof this work by considering a wider set of use cases.https://lab.civicrm.org/dev/core/-/issues/5066Docker image - design principles and scope2024-03-13T16:58:38ZMichael McAndrewDocker image - design principles and scope**_This text is draft - feedback welcome_**
We are creating CiviCRM Docker image designed to be used as a building block in the _production hosting_ of CiviCRM (see #5064 for more details). It will support both CiviCRM Standalone and Ci...**_This text is draft - feedback welcome_**
We are creating CiviCRM Docker image designed to be used as a building block in the _production hosting_ of CiviCRM (see #5064 for more details). It will support both CiviCRM Standalone and CiviCRM alongside a CMS.
We expect the image to be used as part of a wider set of tools to create reliable, performant, scalable hosting infrastructure. Creating that infrastructure is outside of the scope of this image and we are agnostic on what tools used to do so. Commonly used tools include Kubernetes, Docker swarm, etc.
The image can also be used as part of a development environment to enable 'dev prod parity'. When we say development environment we are referring specifically to a development environment for production hosting, not a development environment for core CiviCRM development (buildkit etc.).
Note: we will likely encounter limitations in making each CMS 'Docker friendly' that are outside of our control.Note: support for core development workflows (buildkit, etc.) is outside of the scope of this project.
It is based on the following **principles**:
**No surprises**. We'll follow the well trodden path. Use CiviCRM defaults and recommendations, and Docker and cloud best practices, e.g. https://12factor.net/. There are many different opinions about the best way to deploy CiviCRM and we won't be able to please everyone. If you want to do something extra special or clever, then this _might_ not be for you.
**Be conservative about options**. Each option that we add multiplies complexity and increases the chance of bugs and breakages and we'll avoid adding them unless there is a compelling reason. That said, where possible we'll design the image in such a way that it can be used as a base for more opinionated solutions (e.g. by breaking the Docker image into layers).
### Build process
A possible architecture is as follows:
* Layer 1: CiviCRM Dependencies and tools
* Layer 2: CMS/standalone dependencies and tools
* Layer 3: Application source code
Consumers can choose the image that is the most appropriate jumping off point for their infrastructure.
We expect many consumers of this repository will roll their own Layer 3 that makes sense for their own own build process. A simple approach to building a Layer 3 would be to copy a source code tree from a repository. Other options include using CMS tools such as `drush` or `wp` or dependency managers like `composer`.
We could consider swapping the order of Layers 1 and 2 and rely on official CMS builds as the base layer. This would save time but mean we were reliant on the upstream base images and need to deal with any variance between them. It is worth noting that the Drupal and WordPress images on Docker hub are maintained by the Docker community, not the projects themselves.
### Configuration
We should consider patching CiviCRM to allow it to consume settings passed as environment variables (or similar).
### Backing services
All 'backing services', including MySQL, email delivery, payment providers, etc, are outside the scope of this image and are expected to be configured via environment variables or similar.
We may consider creating recommended images for backing services (e.g. MySQL, email services) further down the line.
### Admin processes
We will include existing tools like `cv` and `civix` to assist with the execution of one off admin processes (e.g. upgrades, config changes, etc.) These tools are also useful during development.
There are some admin processes, e.g. backups, snapshots, for which there are currently no official tools. We should consider creating these as part of this project.
We may also include cron for scheduled tasks.
### Port binding
The image wil expose CiviCRM (and the CMS via http on a specific port. Reverse proxies, caches, firewalls, etc. are outside of the scope of this project.
### Concurrency
The image will be designed to support horizontal scaling, i.e. running multiple instances of the image in parallel.
### Logs
All logs (CiviCRM, Apache, PHP) will be sent to stdout/stderr.https://lab.civicrm.org/dev/core/-/issues/5065Docker image - review of existing CiviCRM Docker codebases2024-03-13T21:32:52ZMichael McAndrewDocker image - review of existing CiviCRM Docker codebasesAs part of https://lab.civicrm.org/dev/core/-/issues/5064 we would like to review existing CiviCRM Docker codebases **_that are currently being used for production hosting_** in order to distil existing best practice and also to not repe...As part of https://lab.civicrm.org/dev/core/-/issues/5064 we would like to review existing CiviCRM Docker codebases **_that are currently being used for production hosting_** in order to distil existing best practice and also to not repeat previous mistakes.
If you have an existing CiviCRM Docker based solution that you would be willing to share, please add a link below with some narrative and pointers for us.
Some questions it would be great if you could answer:
- What is working well for you in your current set up?
- What the challenges have you experienced? / what problems are yet to be solved?
- Are the any Docker APIs or features that you are not making use of that you think would be useful
- anything else you think is relevanthttps://lab.civicrm.org/dev/core/-/issues/5064An official CiviCRM docker image2024-03-12T16:30:24ZMichael McAndrewAn official CiviCRM docker imageWe'd like to create an official CiviCRM Docker image that people can use as a building block when creating CiviCRM hosting infrastructure.
This issue is as an overview with links to various sub-tasks, some of which have issues linked be...We'd like to create an official CiviCRM Docker image that people can use as a building block when creating CiviCRM hosting infrastructure.
This issue is as an overview with links to various sub-tasks, some of which have issues linked below.
1. Review existing Docker based set ups and collect best practice #5065
2. Design principles and scope #5066
3. Develop initial version of the image #5067
4. Create publishing infrastructure
5. Sketch roadmap for further development
6. Document how to use and contribute to the project
This project has received funding from SFE's CiviClick project (thank you SFE!) which will help kick start things but won't cover everything we need to do.
SFE are also funding improvements to CiviCRM to make it more Docker friendly and a project to orchestrate CiviCRM using Kubernetes. See https://cloud.software-fuer-engagierte.de/index.php/s/KrTmxnxH5AZYzg4 for the users stories that this work is intended to cater for.https://lab.civicrm.org/dev/core/-/issues/5063Payment Processor shows Machine Name instead of Backend Title in Configure Ev...2024-03-07T13:44:21Za.valllloveraPayment Processor shows Machine Name instead of Backend Title in Configure Event FeeCurrently the Machine Name of the Payment Processor is shown instead of the Backend Title in Configure Event Fee.
![image.png](/uploads/8029ab7c4e2e343a7adcd43b9ff57bbd/image.png)
![image.png](/uploads/15041218f9d5c10911b5b3d4c5e72fcb/...Currently the Machine Name of the Payment Processor is shown instead of the Backend Title in Configure Event Fee.
![image.png](/uploads/8029ab7c4e2e343a7adcd43b9ff57bbd/image.png)
![image.png](/uploads/15041218f9d5c10911b5b3d4c5e72fcb/image.png)
In Event:
![image.png](/uploads/d8ed15dd94db3f41c2c6ac93ed4544cc/image.png)
Additionally, this means that is meaningless to rename the Backend Title since it will not be displayed. Seems that is getting the `name` field instead of the `title` field.
The tests were made in Master.
EDIT: Seems the problem is here: [PseudoConstant.php](https://github.com/civicrm/civicrm-core/blob/2b410a28eb62e3fc0ada7df712e538794cd06efa/CRM/Core/PseudoConstant.php#L978)https://lab.civicrm.org/dev/core/-/issues/5062APIv4: Cannot set multi-select ContactRef field that is part of a multi-recor...2024-03-07T15:44:13ZmmyriamAPIv4: Cannot set multi-select ContactRef field that is part of a multi-record custom fieldsetOverview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom f...Overview
----------------------------------------
Adding multiple Contact References in a field that is part of a multi-record field set fails with APIv4.
Reproduction steps
----------------------------------------
1. Create a custom field set for all Individuals and check "Does this Custom Field Set allow multiple records?"
2. Add a ContactRef field and check "Multi-Select"
3. Try to set it via the APIv4 Explorer
![image](/uploads/44ecbf788a66150425e55a9de8a6212f/image.png)
Current behaviour
----------------------------------------
Failing with error:
```
{
"error_code": 0,
"error_message": "value: \u00013\u000193\u0001 is not of the right field data type: ContactReference",
"status": 500
}
```
Environment information
----------------------------------------
https://dmaster.demo.civicrm.org running 5.72.alpha1
Comments
---
Not an issue if the multi-select ContactRef field is not part of a multi-record custom fieldset.https://lab.civicrm.org/dev/core/-/issues/5061New structure for getFields array in `.entityType.php`2024-03-13T19:23:27ZcolemanwNew structure for getFields array in `.entityType.php`Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
No...Currently getFields reads from a `schema/xml` file with some wonky formatting. The plan in #4999 is to migrate those `.xml` files to `.entityType.php` files. So now we have a clean slate to decide how those files should be formatted.
Note: This will not affect the output of `DAO::fields()` or `APIv(3|4).getFields`, as we'll add a compatibility layer and tests to ensure those remain unchanged. But since we're replacing the underlying source of the data with something new, we get to clean that up.
Here are all the current keys in the schema/xml files, and what we plan to do with it in the new file. Many of the proposed changes would improve consistency with APIv4.getFields.
| Old key from `xml` | What to do | New key in `php` | Notes |
| ------ | ------ | ------ | ------ |
| `<name>` | ⚠️ index by | | Use name as array key, omit from array values |
| `<title>` | ✅ keep | `title` | |
| `<required>` | ✅ keep | `required` | |
| `<add>` | ✅ keep | `add` | |
| `<pseudoconstant>` | ✅ keep | `pseudoconstant` | snake_case all values in array |
| `<default>` | ✅ keep | `default` | |
| `<contactType>` | ✅ keep | `contact_type` | |
| `<deprecated>` | ✅ keep | `deprecated` | |
| `<readonly>` | ✅ keep | `readonly` | |
| `<serialize>` | ✅ keep | `serialize` | |
| `<localizable>` | ✅ keep | `localizable` | |
| `<usage>` | ✅ keep | `usage` | |
| `<component>` | ✅ keep | `component` | Smells bad to have columns belonging to one component in another component's table :nose: |
| `<localize_context>` | ⚠️ rename | `localize_context` | Obscure property only used by 3 fields, but it's easier to keep it. |
| `<type>` | ⚠️ rename | `sql_type` | |
| `<crmType>` | ⚠️ rename | `data_type` | |
| `<length>` | ⚠️ rename | `attributes[maxlength]` | That seems better. |
| `<uniqueName>` | ⚠️ deprecate | `unique_name` | We can't get rid of it yet but we can discourage it & stop indexing by it at every layer except `DAO::fields()` |
| `<uniqueTitle>` | ⚠️ deprecate | `unique_title` | Are title & attributes[label] not enough? |
| `<comment>` | ⚠️ rename | `description` | |
| `<html>` | ⚠️ rename | `attributes` | |
| `<import>` | ⚠️ move | `usage[import]` | |
| `<export>` | ⚠️ move | `usage[export]` | |
| `<foreignKey>` | ⚠️ move+reformat | `entity_reference` | This tag is outside of `<fields>` in the xml but doesn't need to be. Let's move it into the getFields array. |
| `<dynamicForeignKey>` | ⚠️ move+reformat | `entity_reference` | Conceptually the same as above so can share the same name. |
| `<permission>` | ⚠️ reformat | `permission` | Convert `<or>` tags to nested array format used by `CRM_Core_Permisison::check()`. |
| `<drop>` | ❌ remove | | `<drop>` designates a field has been dropped, but in that case let's just [remove it](https://github.com/civicrm/civicrm-core/pull/18244) from the array as nothing else was being done with it. |
| `<rule>` | ❌ remove | | Unused as of [PR#29611](https://github.com/civicrm/civicrm-core/pull/29611). |
| `<headerPattern>` | ❌ remove | | Unused as of [PR#29612](https://github.com/civicrm/civicrm-core/pull/29612). |
| `<dataPattern>` | ❌ remove | | Appears to be unused in `universe`. |
| `<fulltext/>` | ❌ remove | | Apparently unused. Ignored by GenCode when writing DAOs. |https://lab.civicrm.org/dev/core/-/issues/5060Automated reminder to people that didn't subcribe to groups they applied subs...2024-03-14T22:45:20Znikola.mladenovicAutomated reminder to people that didn't subcribe to groups they applied subscription forOverview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would eith...Overview
----------------------------------------
Subscribing for newsletter usually ends up as a one way street, if they want to have subscribers and be under wing of GDPR. If the user doesn't confirm their subscription, they would either have to find original email or resubscribe if they cant find it, but usually users just forget they did subscribe.
Recommended improvement was discussed on Mattermost to check if such feature existed in civicrm and few users did raise concern and that they would like to have this feature request:
[Mattermost chat](https://chat.civicrm.org/civicrm/pl/bg6x9u7qmf8fdkwn8tz4o9ft1r )
Current behaviour
----------------------------------------
Subscribing to newsletter only sends email as user applies for newsletter
Proposed behaviour
----------------------------------------
Scheduled job for example, which would check if there are any users which are pending for some groups, check the date they applied and then send another nudge for user to join in. This feature should be limited to only once per fresh request for all pending users. Proposal for after how much this automated schedueld job would contact users should be a week, 2 weeks, month, 2 months, 3 months.
Comments
----------------------------------------
_Anything else you would like the reviewer to note._https://lab.civicrm.org/dev/core/-/issues/5059FormBuilder Contact Blocks break with various modifications2024-03-02T23:35:31ZJoeMurrayFormBuilder Contact Blocks break with various modificationsOverview
----------------------------------------
_Address block for individual contact on wpmaster does not render properly on simple FB form, but does on dmaster._
Reproduction steps
----------------------------------------
1. On wpma...Overview
----------------------------------------
_Address block for individual contact on wpmaster does not render properly on simple FB form, but does on dmaster._
Reproduction steps
----------------------------------------
1. On wpmaster 5.72.alpha1 rebuilt as http://demo-248-8hhyk.test-1.civicrm.org:8001/, click on **Administer > Customize Data and Screens > FormBuilder**.
2. Click on New Submission Form.
3. Set Title = test, Permission to Generic: Allow all users, Page Route civicrm/test , Accessible on Front End of Site = true.
4. Click Individual 1 tab, set Security to Form-Based, then drag Contact Address(es) block into bottom of Individual 1 canvas.
4. Form renders improperly.
![2024-03-02_18-26-12](/uploads/fa4edb46a99b74179ce9e17875ecd750/2024-03-02_18-26-12.png)
1. On dmaster, click on **Administer > Customize Data and Screens > FormBuilder**.
2. Click on New Submission Form.
3. Set Title = test, Permission to Generic: Allow all users, Page Route civicrm/test , Accessible on Front End of Site = true.
4. Click Individual 1 tab, set Security to Form-Based, then drag Contact Address(es) block into bottom of Individual 1 canvas.
4. Form renders properly.
![2024-03-02_18-09-55](/uploads/e3c5cbe752876a2e35cab1e70f703ba4/2024-03-02_18-09-55.png)colemanwcolemanwhttps://lab.civicrm.org/dev/core/-/issues/5058FormBuilder "magic" links should log in the user so that User-based Entity se...2024-03-07T13:41:11ZKeith NunnFormBuilder "magic" links should log in the user so that User-based Entity security behaves as expectedOverview
----------------------------------------
When sending a link to a Form Builder form to a user by token (e.g. {afform.afformSubmissionLink}), the generated URL provides information that allows the form to auto-populate. It should...Overview
----------------------------------------
When sending a link to a Form Builder form to a user by token (e.g. {afform.afformSubmissionLink}), the generated URL provides information that allows the form to auto-populate. It should also log in the specific contact who received the link similarly to the behaviour of the contact_id and checksum tokens when used together.
Reproduction steps
----------------------------------------
1. create a new basic submission form
1. set 'Expose to:' to include 'Message Tokens'
1. set 'Individual 1' Security to 'User-based'
1. set 'Autofill' to 'current user'
1. Go to a contact summary page and merge document to use the exposed token.
1. Follow the link in the merged document
Current behaviour
----------------------------------------
Sometimes the form will throw an error, other times if the overall display permissions are open enough, the form will display and auto-populate, but any changes to the Individual 1 contact record will fail.
Expected behaviour
----------------------------------------
CiviCRM should recognize the user as a logged-in contact because we have sent them a 'magic' link.
Environment information
----------------------------------------
https://wpmaster.demo.civicrm.org test environment via firefox 123
Comments
----------------------------------------https://lab.civicrm.org/dev/user-interface/-/issues/69Fix Additional Payment div tag issue in Accordion2024-03-07T13:40:03ZshaneonabikeFix Additional Payment div tag issue in AccordionBased on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in pr...Based on this discussion [here on pull 29448](https://github.com/civicrm/civicrm-core/pull/29448) we need to modify the divs to ensure that the Check is placed inside the Payment Details (rather than outside).
This problem existed in previous versions before. The issue lies in ```templates/CRM/Contribute/Form/AdditionalPayment.tpl``` and can be seen below.
![paymentdetails](/uploads/aea5250221b5177befc50ba34d82df5a/paymentdetails.png)
@nicol comments:
> This closing div closes the crm-accordion-body too soon so the check field is outside the border. This </div> should be removed, and the one below (line 106) brought back.
cc @nicol @noah @herbdoolhttps://lab.civicrm.org/dev/core/-/issues/5057Make descriptions visible in drop down2024-03-07T13:39:27ZyashodhaMake descriptions visible in drop downAll the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be help...All the select2 drop-down are mostly option values which do have a description field in the database.
It will be useful to use this for display in select2 drop-downs.
We already show description for entities like events. It will be helpful to choose options for the user(if options do indeed explanation and are configured as such)https://lab.civicrm.org/dev/core/-/issues/5056Theming of remote oEmbed / iFrame2024-03-07T13:38:52ZJoeMurrayTheming of remote oEmbed / iFrameWe are adding the ability to publish eEmbed / iFrame functionality from CiviCRM to remote sites. (https://github.com/totten/civicrm-core/blob/master-oembed/ext/oembed/README.md#issues--todos). The backend CiviCRM site is a provider or pu...We are adding the ability to publish eEmbed / iFrame functionality from CiviCRM to remote sites. (https://github.com/totten/civicrm-core/blob/master-oembed/ext/oembed/README.md#issues--todos). The backend CiviCRM site is a provider or publisher of content, typically forms. We're going to call front end sites that consume this content consumer sites.
Two prototypical use cases are:
1. An organization uses a Standalone backend CiviCRM instance to publish public facing pages on their public WordPress site (contribution page, newsletter subscription page, event registration pages) which is the only consumer site.
2. An organization publishes some content that it encourages aligned partners to display on their sites, e.g. a FormBuilder based petition that needs to appear on many consumer sites with different themes including colour schemes, fonts, etc.
In both cases there is a need to make the content inside the oEmbed/iFrame look okay or even good on the consumer sites.
There is a need to develop approaches to theming the content that will be presently remotely on consumer sites.
In case 1, it may be reasonable for the organization to create a theme on the backend publisher site that matches the front end theme. However, the backend CiviCRM publisher may be a locked down site like Spark which does not provide this level of access.
As of March 1, 2024 it is possible on backend site to select a site-wide theme, and for parameters in the oEmbed/iFrame requests to include width and height for the window of content.
@kcristiano has had success in using css on a consumer site to theme the content inside an iFrame (target the selectors).
Many sites that publish pages in iFrames for remote consumption allow small theming choices to be made, eg foreground and background colour, etc.
As of March 1, 2024, selected content on a CiviCRM site can expose urls for oEmbed and iFrame references to that content.
It might be desirable to have a consumer choose to make some small theming adjustments to the CiviCRM content that will be rendered on their site, adjusting the url for the oEmbed or iFrame. The url could get key-value pairs for the theming adjustments or perhaps they could be stored in a record in a database or used to create a css file on disk that would be requested with a single key-value pair in the url.
What are the considerations and desiderata for providing a simple usable approach to end users to get an iFrame reference that provides some theming of the content? For example, what is a reasonable set of end user oriented settings that are not overwhelming that could be made available? Foreground colour, background colour, font, etc?
Should there be a different set that would make available a fairly full set of tags for CiviCRM forms, including h1, h2, etc all the way to styling of selects, buttons, checkboxes, etc.?JoeMurrayJoeMurray