We had one site that had 'lost' all it angular pages, eg CiviMail and System Status.
In our case the angular cache files were returning 404 on the New Mailing page. (and 'inspector' was showing a lot of red angular errors)
It was building the cache files in sites/default/files/civicrm/images, but then searching for them in sites/default/files/civicrm/...
We got this on one of the db upgrades. For us, it was due to few entries in civicrm_relationship table which were attached to permanently deleted contact ids. You can follow the below steps to complete the upgrade process.
Take a separate back up for civicrm_relationship table.
Check invalid entries using -
I was able to solve this, at least for now, on my WordPress 4.8/Civi 4.7.22 site using this suggestion from Tim Otten:
another work-around should be going to "Administer => System Settings => Debugging" and disabling the "Asset Cache"
Of course in the long term we'd like to take advantage of the Asset Cache. But for now at least we have our angular-based ...
The equivalent would be any of these:
Navigate to civicrm/admin/extensions/upgrade?reset=1
Navigate to "System Status" or "Manage Extensions". Those pages will link to the above.
On CLI, run cv ext:upgrade-db (Download cv from https://github.com/civicrm/cv)
It depends on the upgrade i.e from 6.x to 7.x to 8.x. If its a simple and internal version i.e 7.12 to 7.29 than you can perform update directly and you won't have problem in CiviCRM but if its from 6 to 7/8 then you will need to replace the CiviCRM files with same version for D7 or D8 and then clear CiviCRM cache(probably delete template_c).
Note: Backup ...
First of all, I should say that this is a job for someone who is reasonably technically minded and comfortable with using the command line. If this doesn't sound like you, then I would suggest that you look for help with this - perhaps from the person that installed CiviCRM in the first place.
You can find detailed instructions in the Administrator Guide. ...
Best to review the tables which are largest in your DB, and also identify which queries during the upgrade take the longest. This is a chicken-and-egg problem, which means you might review the tables you "lighten" as you work through the upgrade process.
Here's something I was using a few years ago on fairly heavy DB. This would exclude data in those tables ...
In the latest version, you can also rebuild the multilingual schema yourself by navigating to API Explorer http://www.site-name/civicrm/api#explorer
Select Entity = System, Action = rebuildmultilingualschema and click on Execute button.
If you aren't able to access the API explorer UI, try using the cv command from the terminal.
cv api System....
If I understand correctly, you first installed 4.6.0 and then loaded a DB dump for 4.3.4 on top of the 4.6.0 system. Doing so would put the database in an inconsistent state — some elements from 4.6.0 (e.g. the table civicrm_mailing_abtest) are still present, but other elements are replaced by the 4.3.4 version (e.g. the table civicrm_domain).
This thread helped me:
How to find and/or fix missing indices?
I've aggregated the SQL listed there below, copy it and run it via phpMyAdmin:
ALTER TABLE civicrm_prevnext_cache DROP INDEX index_all;
ALTER TABLE civicrm_option_value DROP FOREIGN KEY FK_civicrm_option_value_option_group_id;
ALTER TABLE civicrm_option_value DROP INDEX ...
Apparently the people before me who was using the website had the files on another server and gave me a different server credentials. Thank you all who took the time to try and help I am sorry for the weird question.
This is a core bug and Eileen has send a PR for the fix. Will you be able to try by applying the patch from here?
If the patch works for you than please comment your test result on PR so that it will speed up process of merging into core and having it available in next release.
Issue causing this:
In PHP logs I found out Symphony was mentioned along with Flexmailer. We had alpha outdated version of Flexmailer causing issues. Disabling it/ updating it seems to work as solution.
After that I could update CiviCRM smoothly and works!
Hopefully someone will need this in the future!
You could use the extension CiviRules to do that.
You need to set up two different Rules, one for each process.
Select a trigger and condition with your requirements (group contact is added, and contact is changed, would be the triggers I think)
Dependent on your preference, you could create one of these actions:
a scheduled activity assigned to a ...
Please follow the steps in the link one by one
I guess this helps !!!
You are correct that latest.civicrm.org/versions.json is the canonical source for CiviCRM version information.
The file is quite new and the release-publishing script has not yet been updated to write to it (an issue has been filed for this), so at the moment it must be updated by hand.
I agree that the file should be under version control.
If anyone is ...
I feel your pain.
There is no way to do it through the modules panel.
However, I believe the instructions you are following are unnecessarily complex. What we do is back up, then delete the civicrm directory, upload the new version and then run the update script. We don't bother disabling and enabling extensions. We use maintenance mode if it's during ...
You can apply this PR - and reload System status page. This will let you know in advance which indices are already present in DB and would result in DB error on hitting Update Indices button. So what need to be done is -
Apply this PR.
Reload System status page.
Some duplicate indices would be shown above Update Indices button including a message of what ...
Currently updating contribution to add/update soft credits are not supported. I feel Updating soft credit was missed during initial implementation. We will need to submit a core fix to have it working for Contribution Batch update.
I had a similar issue and posted here: https://github.com/veda-consulting/uk.co.vedaconsulting.gdpr/issues/50
I have not had a chance to see why the tokens were not working for me, but I can add them manually:
Aivars, If the problem you facing is something related to report then i would suggest to fix the report rather wasting time exporting-importing data/structure from 2 different instances. The problem you facing has nothing to do with db structure. The error in report might be
Any installed extension might be conflicting with report code, so you can probably ...
You should find release notes for all versions linked from https://civicrm.org/blog/tags/release (this page is linked from the download page). Maybe they haven't added in the latest yet: 5.18.0 not there either
https://lab.civicrm.org/dev/core/blob/master/release-notes.md links to all the release notes including 5.18.0 and 5.18.1
Fantastic, like Jon G - Megaphone Tech mentioned in the comments: I replaced the formerly working shortlink including my domain name with the internal link using the auto-generated "clients" structure for $civicrm_root (and in the following line with the templates_c link) in my civicrm.settings.php file and now finally the CiviCRM menu appears ...
It sounds like you're using some very old-school approaches to system management. You can probably make your life easier by adopting some newer practices.
Always run upgrades on a test server. I like to run it on my own laptop. You can use a virtual machine for that.
Ideally, use a version control system like git, so you can push your upgrade from your ...
The most reliable way to do this is to not import addresses that are known matches.
I regularly use Pentaho Kettle to create import files for me. I'll separate addresses into their own CSV, then use Kettle to look up whether the address matches the contact's address in Civi. I'll filter out those that do, leaving only remaining addresses. However, Kettle ...
My experience with anything composer-ish seems to be:
Struggle with it for a while until the site becomes messed up beyond repair.
Restore from backup and struggle some more until it's messed up again.
Create a brand new install and then copy over the sites/default folder and .htaccess and such.
Replace the database with my backup.
Run the upgrades.
In practice it's as simple as doing a composer update for the most part - assuming you're configured "sensibly" - the RoundEarth setup makes (or at least made!) some assumptions re: versioning that are not helpful for upgrading. So here goes:
You should declare both civicrm-core and civicrm-drupal-8 in your composer json file. In the require section you ...