CiviCRM Core issueshttps://lab.civicrm.org/dev/core/-/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/5037Standalone: installation of CiviCRM in another language2024-03-12T13:23:06ZjaapjansmaStandalone: installation of CiviCRM in another languageThe installer for CiviCRM standalone gives an error message when you select another language then English.
The installer is capable of downloading the translation files however this is not implemented yet in the standalone installer.The installer for CiviCRM standalone gives an error message when you select another language then English.
The installer is capable of downloading the translation files however this is not implemented yet in the standalone installer.jaapjansmajaapjansmahttps://lab.civicrm.org/dev/core/-/issues/4571Proposal: Add possibilty to assign custom CSS classes to containers in Form B...2024-03-12T13:14:12ZTobias Voigttobias.voigt@civiservice.deProposal: Add possibilty to assign custom CSS classes to containers in Form BuilderOverview
----------------------------------------
This issue intends to achieve more control and flexibility in styling the frontend appearance of form builder forms. To achieve this we suggest to add the possibility of assigning custom ...Overview
----------------------------------------
This issue intends to achieve more control and flexibility in styling the frontend appearance of form builder forms. To achieve this we suggest to add the possibility of assigning custom CSS classes to containers in the configuration backend / GUI of Form Builder.
This is meant to be an addition to the [Form Builder Roadmap](https://lab.civicrm.org/dev/core/-/issues/3761).
Current behaviour
----------------------------------------
Currently it is possible to select a predefined CSS class from the 'style' dropdown menu ("Panel Pane"). When this style is selected, an additional class is added to the div container ("af-container-style-pane").
![Screenshot](/uploads/306fe60b466b20d838972ff125ebb988/Bildschirmfoto_vom_2023-09-13_16-48-18.png)
Proposed behaviour
----------------------------------------
We propose to give users the possibilty to add custom CSS classes to form builder containers in a new input (text) field to allow more control and flexibility in styling the frontend appearance of form builder forms.
![Mockup](/uploads/047b3bc36039cf5f138dc9342834e25c/mockup-custom-css-classes.png)
Comments
----------------------------------------
Some major parts of the relevant code seems to be in these files:
https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemStyle.component.js
https://github.com/civicrm/civicrm-core/blob/master/ext/afform/admin/ang/afGuiEditor/afGuiMenuItemStyle.htmlhttps://lab.civicrm.org/dev/core/-/issues/3674mailing acl permission check via php api2024-03-12T05:03:17ZAlanDixonmailing acl permission check via php apiWhen trying to send mail via cv api job.process_mailing, or drush (using drush civicrm: https://www.drupal.org/project/civicrm_drush/issues/3290970#comment-14578047), CiviCRM generates an error "API permission check failed for Group/get ...When trying to send mail via cv api job.process_mailing, or drush (using drush civicrm: https://www.drupal.org/project/civicrm_drush/issues/3290970#comment-14578047), CiviCRM generates an error "API permission check failed for Group/get call; insufficient permission: require access CiviCRM"
There are two sort-of work arounds with cv: either of "cv api job.execute" (if that job is enabled) or "cv --user=admin api job.process_mailing" (where admin is the cms username of an admin-permissioned user).
When inserting breakpoints to try and understand what's going on, it appears that the failure is happening here:
https://github.com/civicrm/civicrm-core/blob/8ce670176eac89314f9d593fc5245d62e32e8204/CRM/Mailing/BAO/Mailing.php#L2238
It's unclear to me why the two work-arounds avoid this.
Conclusion: the process_mailing job is demanding too many permissions when invoked via the php api.https://lab.civicrm.org/dev/core/-/issues/3683Not possible to choose primary phone numbers without specific address type2024-03-12T05:03:16ZMariaVNot possible to choose primary phone numbers without specific address typeWe have noticed that it is not possible to choose the primary phone number in a profile:
![grafik](/uploads/694bacb4693b362759835664b0403fd3/grafik.png)
As you can see in the screenshot, it is necessary to choose an address type as wel...We have noticed that it is not possible to choose the primary phone number in a profile:
![grafik](/uploads/694bacb4693b362759835664b0403fd3/grafik.png)
As you can see in the screenshot, it is necessary to choose an address type as well.
For example: Creating an individual search view with the primary number is not working.
If I choose address type "Mobile", only primary numbers of this type will be shown but it could be that other primary numbers have i.e. the type "Work".
While with e-mail adresses I have this option:
![grafik](/uploads/e09c2e45b05fc88ae72bef30fe0a7da2/grafik.png)
There I can choose just primary and I think it should be the same way with phone numbers.
So I am wondering if there is any reason why it is different with phone numbers?
Thanks in advance for any support!https://lab.civicrm.org/dev/core/-/issues/5040Events - Registration Confirmation and Receipt (on-line) template fails to co...2024-03-12T00:54:25ZspalmstromEvents - Registration Confirmation and Receipt (on-line) template fails to compileOverview
----------------------------------------
The default `Events - Registration Confirmation and Receipt (on-line)` fails to compile, giving this error:
`"Syntax error in template "eval:{crmScope extensionKey=""}<!DOCTYPE html..."...Overview
----------------------------------------
The default `Events - Registration Confirmation and Receipt (on-line)` fails to compile, giving this error:
`"Syntax error in template "eval:{crmScope extensionKey=""}<!DOCTYPE html..." on line 471 "{capture assign=selfservice_preposition}{if 0 && > 0}{ts}before{/ts}{else}{ts}after{/ts}{/if}{/capture}" - Unexpected "> ""`
|----------------------------------------------------------|
Reproduction steps
----------------------------------------
1. Attempt to register for an event.
1. Enter details.
1. Click on Review.
1. Click on Register.
1. You get an error message.
Current behaviour
----------------------------------------
This error message is generated internally, but was only visible when debugging because of [Call to SmartyCompilerException fails in <drupal root>/vendor/civicrm/civicrm-packages/smarty3/vendor/smarty/smarty/libs/sysplugins/smarty_internal_templatecompilerbase.php on template compiler error.
](https://lab.civicrm.org/dev/core/-/issues/5039)
```
"Syntax error in template "eval:{crmScope extensionKey=""}<!DOCTYPE html..." on line 471 "{capture assign=selfservice_preposition}{if 0 && > 0}{ts}before{/ts}{else}{ts}after{/ts}{/if}{/capture}" - Unexpected "> ""
```
Expected behaviour
----------------------------------------
You get a registration confirmation page.
Environment information
----------------------------------------
* __Browser:__ _MS Edge_ but probably irrelevant
* __CiviCRM:__ _5.70.1_
* __PHP:__ _8.3.1__
* __CMS:__ _Drupal 10.2.3_
* __Database:__ _MySQL 8.0.36_ but probably irrelevant.
* __Web Server:__ _IIS_ but probably irrelevant.
Comments
----------------------------------------
The 'offending' code is somewhere here, I suspect (lines 461 - 471) but I haven't been able to discover it.
```
{if {event.allow_selfcancelxfer|boolean}}
<tr>
<td colspan="2" {$valueStyle}>
{capture assign=selfservice_preposition}{if {event.selfcancelxfer_time|boolean} && {event.selfcancelxfer_time} > 0}{ts}before{/ts}{else}{ts}after{/ts}{/if}{/capture}
{ts 1="{event.selfcancelxfer_time}" 2="$selfservice_preposition"}You may transfer your registration to another participant or cancel your registration up to %1 hours %2 the event.{/ts}
{if {contribution.paid_amount|boolean}}{ts}Cancellations are not refundable.{/ts}{/if}<br/>
{capture assign=selfService}{crmURL p='civicrm/event/selfsvcupdate' q="reset=1&pid={participant.id}&{contact.checksum}" h=0 a=1 fe=1}{/capture}
<a href="{$selfService}">{ts}Click here to transfer or cancel your registration.{/ts}</a>
</td>
</tr>
{/if}
```5.71.0https://lab.civicrm.org/dev/core/-/issues/2990CiviCampaign - Move data into a single table2024-03-11T20:47:07ZcolemanwCiviCampaign - Move data into a single tableBackground
------------
CiviCampaign is an optional component (disabled by default on new installs). It allows contributions, events, etc. to be associated with a campaign.
Campaigns are basically like tags. The campaign itself contain...Background
------------
CiviCampaign is an optional component (disabled by default on new installs). It allows contributions, events, etc. to be associated with a campaign.
Campaigns are basically like tags. The campaign itself contains a bit more data (type, start & end date, description, goal) than a Tag, but the mechanism for linking an entity with a campaign is a very simple foreign key.
How it works now
-------------
"Tagging" an entity with a campaign works via a column on that entity's table. E.g. `civicrm_contribution_page.campaign_id`. There are currently 10 entities with such a column, allowing them to be "tagged" with a campaign_id.
The problem
-----------
This design involves tight coupling between CiviCampaign and other components, as it involves adding a column to their tables. It also limits the possibilities for which entities can have a campaign_id.
The solution
----------
There is another common pattern in CiviCRM, which is to add a small "bridge" table to join two entities, which is a good alternative to adding a column. `civicrm_entity_tag` is one example. It includes `tag_id`, `entity_id` and `entity_table` columns, and an OptionGroup `tag_used_for` which lists all the possible values for `entity_table`. Importantly, it's easily added-on by extensions; if an extension provides a new entity type which should be taggable, is just adds it to the option list.
The migration
------------
If CiviCampaign were a greenfield project designed today, we wouldn't think twice about structuring the data with a bridge table instead of littering our database with `campaign_id` columns. As a brownfield problem, fixing the structure may be more trouble than it's worth, but I thought I'd at least articulate how it might be possible:
- APIv4 has a new concept of "Extra" calculated fields, which could provide a faux `campaign_id` column for backward compatibility.
- CiviCampaign could implement a post-hook to save campaign_id if it's passed into "create" params. This would keep create and update working as if that column still exists.
- APIv3 would require some hacking to make a pseudo-field to fill in for a missing `campaign_id`.
Random musings
-----------
While researching this, I stumbled across a table called `civicrm_campaign_group`. I have no idea what it does but it looks very similar to how I imagined the new bridge table would be. It includes a `campaign_id`, `entity_id` and `entity_table` column. Why does this table exist??https://lab.civicrm.org/dev/core/-/issues/4934Standalone: messages from Civi don't appear as expected2024-03-11T18:54:28ZAndy ClarkStandalone: messages from Civi don't appear as expectedMessages from Civi don't appear as expected e.g. when testing outbound email, check the mail() button and click 'Send and Save email' and no message will appear. This is 100% reproducible. Sometimes messages will appear a couple of scre...Messages from Civi don't appear as expected e.g. when testing outbound email, check the mail() button and click 'Send and Save email' and no message will appear. This is 100% reproducible. Sometimes messages will appear a couple of screens after they have been created, but not always. Using the 5.69.2 version of Standalone.RichRichhttps://lab.civicrm.org/dev/core/-/issues/3669Thank-you letter for soft credit contributions2024-03-11T05:03:25ZmasettoThank-you letter for soft credit contributionsOverview
----------------------------------------
When printing the thank-you letters for soft credits, it does not print all soft credit contributions.
Reproduction steps
----------------------------------------
1. Create a contributio...Overview
----------------------------------------
When printing the thank-you letters for soft credits, it does not print all soft credit contributions.
Reproduction steps
----------------------------------------
1. Create a contribution for Household and create a soft credit for each of household members (I have 2 household relations: Head of Household and Household member).
1. Go to Find contributions and search only "Soft credits only"
1. Check the soft credit contributions just created
2. Select "Thank-you letters" action
3. Choose a Template
4. Click on Preview button o Make Thank-you letters button
Current behaviour
----------------------------------------
Print only one page.
If in search result there are others unselected rows, it prints information about other contributions, not in selection!
Expected behaviour
----------------------------------------
Should print one page for each soft credit.
Environment information
----------------------------------------
* __Browser:__ _Firefox 101.0.1
* __CiviCRM:__ 5.50.3
* __PHP:__ _7.4
* __CMS:__ Drupal 9
* __Database:__ MySQL 8.0.27-0ubuntu0.20.04.1
* __Web Server:__ _Apache 2.4https://lab.civicrm.org/dev/core/-/issues/3692Replace all calls to deprecated method CRM_Core_PseudoConstant::activityType()2024-03-11T05:03:24ZherbdoolReplace all calls to deprecated method CRM_Core_PseudoConstant::activityType()There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And cha...There are calls to `CRM_Core_PseudoConstant::activityType()` (deprecated) in many places such as `$activityTypes = CRM_Core_PseudoConstant::activityType(TRUE, FALSE, FALSE, 'name');` ~~but the actual method accepts no parameters. And changes to that method predate the migration from SVN... so some guesswork needs to be done~~.
Update: oops I just noticed it has `func_get_args()` so it is accepting parameters after all.
In some cases it seems that it can be replaced with `CRM_Core_PseudoConstant::getKey('CRM_Activity_BAO_Activity', 'activity_type_id', 'ACTIVITYNAME')` but in other cases it actually does need a list of activity types. And in some cases needs to filter out disabled components, which is what the original method is doing.https://lab.civicrm.org/dev/core/-/issues/4753Afform - Custom fields of type YesNo (boolean): Defaults not displayed and ch...2024-03-10T20:37:04Zmattwiremjw@mjwconsult.co.ukAfform - Custom fields of type YesNo (boolean): Defaults not displayed and changes not savedTo reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = t...To reproduce set up a simple submission form:
1. Add Individual
2. Add "is_deceased" field (a Yes / No radio field) (optional)
3. Add a contact custom field of type "YesNo" (optional)
Create a contact and set the contact is_deceased = true and custom field "YesNo" = true
Load the form with URL parameter eg. #?Individual1=169 to load that contact
See that is_deceased field is set to Yes but the customfield is not set.
Now set the customfield to "No" and submit the form.
Reload the form and see that it did not save the value of the custom field :-(
So two issues:
1. Custom field value is not displayed: It is retrieved via prefill as a bool but the field is added with radios that have values 0,1.
2. Custom field value is not saved: It is converted to int (0 or 1) once submitted whether submitted as "false" or 0.
I've been round and round trying to work out how this should be fixed but have hit a dead end!
The display issue can be "fixed" by either not passing the options to the form or by passing them with true/false instead of 0,1. But the value still doesn't save.
@colemanw Any ideas?https://lab.civicrm.org/dev/core/-/issues/3708Feature request - Add link type to case activity setup2024-03-10T05:03:23ZkristinecFeature request - Add link type to case activity setupOverview
----------------------------------------
In CiviCase, create an option to add an internal/external link on the list of activity types.
Example use-case
----------------------------------------
1. Click on **Administer -> CiviC...Overview
----------------------------------------
In CiviCase, create an option to add an internal/external link on the list of activity types.
Example use-case
----------------------------------------
1. Click on **Administer -> CiviCase -> Case Types -> Edit Housing Support**.
2. Click on **Activity Types** tab
Current behaviour
----------------------------------------
Currently, admins can only add activity types in civicrm (using the "Add activity type" dropdown).
Proposed behaviour
----------------------------------------
Admin users could really benefit from an "add link type" setting. I propose two fields: title and path/url. This would allow admins to link to webforms/afforms in the future for additional data entry but leveraging their features (e.g., conditional fields, layout control, etc.). For example, user clicks on a case and in the dropdown, sees "Benefits Evaluation", but this is an internal path link rather than a civicase form.
Comments
----------------------------------------
Not sure if this would be considered an extension or part of civicore. Also, wouldn't mind marking this as a paid issue in case others might be interested in contributing![Link_Type](/uploads/fb77e6502f97f54e0ef323cd6abaf71e/Link_Type.png).https://lab.civicrm.org/dev/core/-/issues/3715vounteer singup form not working properly2024-03-10T05:03:22Zdev@inboundvounteer singup form not working properlyOverview
----------------------------------------
On submission of volunteer signup form. we get a fatal error. "This page isn’t working" and "HTTP ERROR 500" and messages like "www.site.com is currently unable to handle this request."
...Overview
----------------------------------------
On submission of volunteer signup form. we get a fatal error. "This page isn’t working" and "HTTP ERROR 500" and messages like "www.site.com is currently unable to handle this request."
And sometime it gives an eroor like "Could not find valid value for needs"
Reproduction steps
----------------------------------------
1. Click on volunteer now -> selected an opportunity.
1. Entered **First Name** and **Last Name** and clicked **submit**.
1. Got an error "**Fatal error: This page isn’t working and HTTP ERROR 500".
Current behaviour
----------------------------------------
Currently there is fatal error occurred when we submit volunteer signup form. sometime it says the could not find valid value for need.
And when i tried to search for the opportunity it gives an error message like "need 1 bu found 25"
![Screenshot_2022-07-05_at_11.49.27_AM](/uploads/cbe07cd6cfa94e1bf6bb9abcd8e18744/Screenshot_2022-07-05_at_11.49.27_AM.png)
Expected behaviour
----------------------------------------
There should be no error when we submit the volunteer singup form.
And when we search for opportunities then it should display available opportunites list.
And there should be option to check volunteer singup form fields, we should able to add,edit this form fields.
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ Version 103.0.5060.53
* __CiviCRM:__ Version 5.17.0 <!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __CiviEvent Widget:__ Version 3.2
* __civiVolunteer :__ Version 4.7.31-3.2.3.1
* __CMS:__ WordPress 5.0.15https://lab.civicrm.org/dev/core/-/issues/4829Standalone: Authx jwt should not generate a cookie2024-03-09T18:36:02ZbgmStandalone: Authx jwt should not generate a cookieRelated to this PR: https://github.com/civicrm/civicrm-core/pull/28407
We silenced the test for Standalone for now, but if I understand correctly, when doing a request with jwt for authx, it should not generate a cookie.
(This is very ...Related to this PR: https://github.com/civicrm/civicrm-core/pull/28407
We silenced the test for Standalone for now, but if I understand correctly, when doing a request with jwt for authx, it should not generate a cookie.
(This is very low priority, very low impact)https://lab.civicrm.org/dev/core/-/issues/3696Should MessageTemplate.send support tplParams with Smarty disabled?2024-03-09T05:03:24ZRichShould MessageTemplate.send support tplParams with Smarty disabled?The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - whi...The api3 MessageTemplate.send action has supported `tplParams` since its inception in 2013, exposed explicitly in the api spec since 2015.
They allow a way to specify content for arbitrary email template parameters: `{$paramname}` - which are different to `[entity.tokens]`. It's **super useful** for transactional mail where you want to include extra info as a one-off.
The api has done this by assigning the given key value pairs as Smarty variables.
More recently (2020) the api action added support for disabling Smarty, since it wasn't playing nicely with message template content generated by Mosaico.
Without Smarty, `tplParams` does not work.
## I would like to see support for `tplParams` without Smarty.
I think the concept of a message template is that it is a flexible template for emails. (Adding token support for one-off context-sensitive use-cases is very inefficient and is likely to end up with hackish situations where the data that needs to be in the email does not need to be in the database.)
I mistakenly thought that it used to work this way, and so I wrote a PR to fix what I saw as a regression, adding tests to boot. https://github.com/civicrm/civicrm-core/pull/19062 however this stalled, because it turns out it wasn't a regression, and so was felt to need more discussion. Hence this post.
The PR is a minor change and I can't see that it has any negative consequences/side effects (very few people will disable smarty anyway), but it does mean the tplParams feature is supported with/out Smarty, which I think is valuable.
There could be nicer ways to specify such content, but this isn't a proposal about a whole new way of doing things.
Thoughts?https://lab.civicrm.org/dev/core/-/issues/3718Profile listings fail to show email addresses when their location type Name d...2024-03-09T05:03:24ZspalmstromProfile listings fail to show email addresses when their location type Name differs from its Display NameOverview
----------------------------------------
If you create a location type and have different Names and Display Names, then a profile listing uses it fails to display the data.
Reproduction steps
-----------------------------------...Overview
----------------------------------------
If you create a location type and have different Names and Display Names, then a profile listing uses it fails to display the data.
Reproduction steps
----------------------------------------
1. Create a new location type with Name say TestingTesting and Display Name 'Testing Testing'.
2. Create a listing profile to display that location type.
3. Assign an email address of that type to a user.
4. Use the profile to display that user.
Current behaviour
----------------------------------------
Erik Adams detail viewed:
![image](/uploads/f1cda7c22218f4983bad7b1afadbeec6/image.png)
The email address does not show in the listing:
![image](/uploads/bacb9d89a6156a1504a64b7781be4838/image.png)
Expected behaviour
----------------------------------------
_What should happen._
![image](/uploads/c08545abfca4db63e1e3143ac52698b6/image.png)
Environment information
----------------------------------------
<!-- Some of the items below may not be relevant for every bug - if in doubt please include more information than you think is neccessary. -->
* __Browser:__ _MS Edge_ but probably not relevant
* __CiviCRM:__ _ 5.52.alpha1._ It is the Demo system<!-- If this problem relates to an upgrade, then specify both old and new versions -->
* __PHP__ _Whatever Demo is running_
* __CMS:__ _Drupal 9_ the version Demo is running.
* __Database:__ _Whatever Demo is running_.
* __Web Server:__ _Whatever runs Demo_
Comments
----------------------------------------
I have spent a few hours attempting to debug on a local system, but haven't been able to discover where the SELECT statement is being created. What appears to be happening is that the SELECT statement is has the Name of the Location Type as a column, whilst the Profile is expecting the Display Name, so when they don't match, the latter displays nothing.
You should note that if the Name is say Testing_Testing and the Display Name is 'Testing Testing', that the data are displayed. This is because somewhere in the Profile display spaces are replaced by underscores. It is how I was able to obtain the expected behaviour.
I am flagging this up in the hope that someone with more expertise than I can more easily identify where the solution lies.https://lab.civicrm.org/dev/core/-/issues/4987standalone: agree distribution format(s)2024-03-08T23:55:45ZRichstandalone: agree distribution format(s)Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Mo...Options:
**OPTION 1** Encourage composer-template
**OPTION 2** Encourage tar-ball (with current structure)
**OPTION 3** Encourage tar-ball (with composer-like structure)
(And is it one of those options -- or two of those options)
Moved from [chat](https://chat.civicrm.org/civicrm/pl/4pwoodpzufd4z8x5wqguwhprbw) to save an unwieldy thread therein.
@totten
> i guess in theory # 1+# 3 sounds better than # 1+ # 2. but
>
> 1. even drupal.org appears to be following a structure like # 1+# 2
> 2. the workflow of "download+extract full tarball for composer-project" is a little weird for upgrades. (you need to delete+reset some folders -- but not other folders)
> 3. i'm not entirely sure how to reconcile # 3 with the regular RC workflow. i'm sure it can be sorted; but it's more of a conversation
>
@demerit (sorry, don't know your handle here)
> tarball tarball tarball
...
@wmortada
> For initial installation, having a tarball that a user can just download and install is preferable because it is easier and lowers the barrier to entry. But is this going to make upgrades more tricky for them? What could we do to make upgrades easier in this scenario?
@artfulrobot
> composer rules out hosting where you dont have shell access. Personally I'm cool with that, because you kinda need shell access to do things properly. Ftp for fun, shell for serious. (What a t shirt slogan!).
>
> I dont like messy things like unpack this tarball, replace directories a, b, c swap out file d.
>
> But I also don't love composer esp when it requires scripts to run. I tend to have my php as not owned by www-data, so the scripts won't run as www-data. Also in staging, where the httpd is in a container, I like to be able to manage the codebase from outside the container, but this will probably use a different php version. I'm happy to change my ways, though
>
> Other projects I work with:
>
> Nextcloud: provides a fairly solid upgrade script, even a web ui for upgrades, though they encourage CLI invocation to avoid timeouts. Files owned by www-data so the code writes the code. The CLI call to upgrade handles everything: checks, downloads, checksum checks, backups, moving files, running db migrations. It's solid and reliable, and there's a 'repair' command, in case something goes wrong (eg you tried your luck on the web ui method...)
>
> Roundcube mail: provides an upgrade script as part of the new release. So you download tar, extract to tmp/ run a script from there like install-to.php /path/to/installation/dir/
>
> I sometimes deploy by git too. I guess I could composer offline, commit, push, pull. I sometimes find composer flaky. There's one package that won't download or such. And it's slow (a zillion http requests) and can't be run offline.
>
> But it let's you add bits to your site, e.g. if you have civi as part of a bigger project. Which is nice.
>
> Tarballs are nice. Can be signed. Single download. Works offline.
>
> Barrier to entry: hmmm. Idk tbh. You need CLI access at mo, and as long as there's a reliable few commands to run that can be copy pasted it makes no difference?
>
> I'd quite like to be able to upgrade by git pull! Is that any more realistic in standalone? Probably red herring :blowfish:
>
> Let's not do this though...
> curl https://civicrn.org/gimmestandalone | sudo bash
@clarkac
> Please don't do anything that rules out hosting without shell access. That would discourage people from getting started with Civi, as I did and I've helped around 15 charities to get Civi - all hosted without shell access. I'm sure there are many in amongst the 4,000 D7 sites that don't have shell access.
>
> # 2 on the list is similar to what I do with upgrades with D7 - after backing up, delete the CiviCRM code folder and unpack the tarballs into it. That's so easy, and adding some more to that would be no problemhttps://lab.civicrm.org/dev/core/-/issues/4793Manage Premiums notices2024-03-08T20:20:54ZJoeMurrayManage Premiums noticesOn dmaster just now (5.69.alpha1), navigating to Administer > CiviContribute > Premiums (Thank-you gifts) https://dmaster.demo.civicrm.org/civicrm/admin/contribute/managePremiums?reset=1 titled Manage Premiums, I get notices:
Warning: U...On dmaster just now (5.69.alpha1), navigating to Administer > CiviContribute > Premiums (Thank-you gifts) https://dmaster.demo.civicrm.org/civicrm/admin/contribute/managePremiums?reset=1 titled Manage Premiums, I get notices:
Warning: Undefined array key "cost" in include() (line 38 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%3F/3F3/3F34E079%%ManagePremiums.tpl.php).
Warning: Undefined array key "financial_type" in include() (line 38 of /srv/buildkit/app/private/dmaster/default/civicrm/templates_c/en_US/%%3F/3F3/3F34E079%%ManagePremiums.tpl.php).5.69.0https://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/3089Meta: Create list of items for moving a core component to an extension2024-03-08T05:07:35ZDaveDMeta: Create list of items for moving a core component to an extensionIt's never really been fully done before. Some of the Grant things are likely to come up again if it's not documented. Partial list just quickly compiled from tickets. Doesn't include the things that did work (which would still need doin...It's never really been fully done before. Some of the Grant things are likely to come up again if it's not documented. Partial list just quickly compiled from tickets. Doesn't include the things that did work (which would still need doing), and might be missing some PRs that had no tickets.
* https://lab.civicrm.org/dev/core/-/issues/3069
* https://lab.civicrm.org/dev/core/-/issues/3076
* https://lab.civicrm.org/dev/core/-/issues/3056
* https://lab.civicrm.org/dev/core/-/issues/3057
* https://lab.civicrm.org/dev/core/-/issues/3087
* https://lab.civicrm.org/dev/core/-/issues/3093
* https://lab.civicrm.org/dev/core/-/issues/3100
* https://github.com/civicrm/civicrm-buildkit/pull/677
* https://lab.civicrm.org/dev/core/-/issues/3101
* https://github.com/colemanw/webform_civicrm/pull/719
* extendedreports
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/commit/6184de98c5b9f40475ab4164c993b19d68561240
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/pull/503
* https://github.com/eileenmcnaughton/nz.co.fuzion.extendedreport/pull/506
* civicrm_entity
* https://github.com/eileenmcnaughton/civicrm_entity/pull/364
* an unresolved cache(?) issue
* https://github.com/twomice/com.joineryhq.jsumfields/pull/23
* https://github.com/civicrm/civicrm-drupal/pull/653
* https://github.com/civicrm/civicrm-drupal/pull/656
* https://github.com/civicrm/civicrm-core/pull/22905
* https://lab.civicrm.org/dev/core/-/issues/3118
* https://lab.civicrm.org/dev/core/-/issues/3119
* https://lab.civicrm.org/dev/core/-/issues/3159
* https://github.com/civicrm/civicrm-core/pull/23116
* https://github.com/civicrm/civicrm-core/pull/23118
* https://github.com/civicrm/civicrm-core/pull/23115
* https://lab.civicrm.org/dev/core/-/issues/3161
* https://github.com/civicrm/civicrm-core/pull/23336
* https://lab.civicrm.org/dev/core/-/issues/3485
* https://lab.civicrm.org/dev/core/-/issues/3492
* https://lab.civicrm.org/dev/core/-/issues/3503
* https://github.com/civicrm/civicrm-core/pull/24191
* https://github.com/civicrm/civicrm-core/pull/26118
Round 2:
* https://github.com/civicrm/civicrm-core/pull/26497
* https://github.com/civicrm/civicrm-core/pull/26499
Late to the party:
* https://lab.civicrm.org/dev/core/-/issues/5075