Well, I'm not sure this is a long-term solution, but it is a workaround....
In one of the Angular posts (Status page angular load error) I found this:
another work-around should be going to "Administer => System Settings => Debugging" and disabling the "Asset Cache"
That's brought my System Status page back, but I don't like the thought of not using a ...
Here's one answer that fixed my problem (see my comment above). The cause was that when I created the Drupal system I just used the domain name without the www. But Civi was loaded with www. This is an old problem and I'm a bit ashamed to admit I made this mistake again! But if your system has this mismatch then system status won't work. Fix was to ...
There have been many answers relating to this type of 'blank' page and most have been solved by ensuring the various paths set in Resources and Directories are correct.
Many questions on this have been tagged with angular so hopefully you will find the ones i am thinking of in the list at https://civicrm.stackexchange.com/questions/tagged/angular
I would probably use the CiviRules extension for this (to be found here: https://civicrm.org/extensions/civirules with documentation here: https://docs.civicrm.org/civirules/en/latest/ ) and then:
set up an activity for uploading the document
set up a CiviRule with trigger new activity, condition on activity type and status (and possibly attachment) and ...
I'm happy to report that the original issue was resolved with an update to 5.5.1. With this update made, the errors illustrated in my original post are no longer occurring.
Because we've long used CiviCRM without this error and first noticed it with 4.7.31 (and consistently with subsequent upgrades), we believe that this new upgrade has returned the ...
Invalid value for field(s) : Membership Status means that the csv file had invalid options for Membership status. The import file should use machine name rather label (or hopefully membership status ID).
Here is the similar post that might help to find solution for your question.
I see this line in CRM_Contribute_BAO_Contribution:
//update pledge and pledge payment, CRM-3961
Looking at CRM_Pledge_BAO_PledgePayment::resetPledgePayment(), I see it calls the DAO method, not the BAO - which is why the hooks (which ARE present) are bypassed.
I think this would be a good ...
Welcome Lawrence: One thought would be to take the approach that if an expired member signs up again, that rather than renewing the original membership, it creates a brand new one - in which case i assume your existing Probation process would work fine.
I don't recall if there is an Extension or just a setting to change CiviMember to always create a new ...
This problem has been raised before and you can view the thread at How to find and/or fix missing indices?
There is also an entry in JIRA at the following link https://issues.civicrm.org/jira/projects/CRM/issues/CRM-20533?filter=allissues
Hope this helps.
Did you check if the cron run is recorded if you call that url manually?
That way you eliminate the possibility of having a typo in the url or an invalid site key.
Some steps you could follow:
is 'curl' installed on the server that executes the cron run?
in the access log of your webserver, do you see the url being called?https://example.org/administrator/...
This can be fixed by removing the permission 'CiviCRM: administer CiviCRM' from these users. You called them non-admin so they shouldn't need this menu? If they don't have this permission they won't get the messages.
I haven't walked through the details, but CiviRules lets you do things with membership statuses. You may want to walk the logic through and see if there is a way to get what you want or close to what you want with that for now.
Well, it's not really possible to have a status for the Renew state because the Start event used for status rules is based on one of the following date :
start date : this date is updated only when there is a gap between the last end date and the new renewal date... if there is no gap, which is the most frequent case, there will be no update
end date : ...
You do not need to have a separate cronjob for each job: on the admin interface, set the frequency for each job you want to (nightly is good for most of them, but the one that process the mailing and handle the bounces are better run hourly or more frequently)
And then if you wget without the "job=cleanup" it will automatically try to process all the ones ...
The membership status ID field on a membership record is a single-value field - so this isn't doable without adding the new membership statuses. I'd recommend either a) adding the new statuses and updating your smart groups, or b) creating reports based on membership end dates to use those to follow up with members.
I'm getting the same error after upgrading to 4.7.25 from 4.7.16 on my WordPress installation. The disabling the Asset Cache workaround fixes it. I guess, for now, I'll just have to disable it whenever I need to check the system status.