Since this path is hard-coded into CiviCRM, the best way to override it is probably a redirect. You could achieve this:
Using the either the redirect or path redirect module for drupal.
Using a plugin for Wordpress such as redirection.
Using Apache's mod-rewrite.
Note that there are two paths you'd need to redirect from: /civicrm and /civicrm/dashboard as ...
There are several things happening on the dashboard, so you'll need to dig further into this yourself to find the real underlying issue. Here are some things which could trigger symptoms like what you're describing.
This is the most common cause of slow dashboards IMO, but it's dependent on your setup; see note re Timeouts below.
Your DB ...
Your best bet with Drupal is to use the Rules module. I think you also need to have CiviCRM Entity installed to get the proper tokens.
Add a new Rules Component:
Component Plugin: Action Set
Name the component (e.g.: Fetch CiviCRM ID of logged in user)
You only need one variable, choose CiviCRM > CiviCRM Contact (may need the CiviCRM Entity module for ...
This one also throws me occasionally. You should reduce the dashboard cache timeout setting to '0' in /civicrm/admin/setting/misc?reset=1
Then it will load the reports dynamically each time you access the dashboard.
When a user is logged in their information is auto populated in profile forms. So when they go to event registrations, donation pages, etc. their info is listed in the profile fields. If they make changes this information is updated in CiviCRM.
You can create a profile for editing and insert it into a WordPress page via a short code with the edit option ...
A few things may cause issues like this.
Webserver cannot make HTTP(s) requests to itself
If CiviCRM / PHP cannot make a request to the CiviCRM site itself, it will be unable to retrieve the dashboard data. This can happen for multiple reasons:
Webserver is behind a proxy and proxy does not permit requests from internal network
Webserver has DNS which won'...
Please check your civicrm.settings.php and after that
Administer - System Settings - Directories
Administer - System Settings - Resource URLs
Administer - System Settings - Cleanup Caches and Update Paths
And then Clear Cache again
It's opensource, whatever you want today you can change... provided you implement the change you want.
As for future versions... well, the future isn't written, so if you are willing to code or fund the changes you want, the answer is "yes", to whatever you make happen.
The form field is assigned "q" as its HTML accesskey. I don't know about other browsers, but you can activate it in Firefox by pressing alt+shift+q (Windows/Linux), or on Mac: either control+option+q or control+alt+q.
The DefaultDashlets CiviCRM extension creates a settings page that allows administrators to define the active dashlets for new users based on group membership.
Keep in mind it was born some hours ago as part of a CiviCRM developer training exercise. You rock David Hayes!
Allen has a great explanation for how to do this, particularly for anytime anyone logs in. Just for completeness, I wanted to make sure this simple option was documented, too.
You may not really want all logins to go to the contact dashboard. It may be really that you want certain links to lead people there, but others logging in (you and other admins, ...
I think the best solution would be to upgrade to CiviCRM 4.7.11 which will include an improved dashboard that no longer depends on server-to-self http requests.
This upgrade will be released in about 2 weeks. The new dashboard features are sponsored by WMF.
Read more about the issue at https://issues.civicrm.org/jira/browse/CRM-17663
I think what you are mainly interested in is having people sent to their User Dashboard on login. This is something that needs to be done in WordPress by one of a variety of plugins. As it is not a CiviCRM functionality, and there are many ways to do it in WordPress, no one has bothered to create a CiviCRM recipe for doing it.
Step 1: Create the CiviCRM ...
Check your CiviCRM base URL - the CMS configuration ($base_url in Drupal settings.php), CiviCRM (CIVICRM_UF_BASEURL in civicrm.settings.php) and webserver configuration (canonical location you rewrite to) must all match.
For the dashboard to work, the webserver needs to be able to access the website itself.
If you're hosted at https://www.example.org the ...
You don't need to use SQL! There is an API and a hook for this, assuming you're on Civi 4.4 or higher.
Check out the DashboardContact API, especially if you're working with contacts that have already been created.
If you're mostly concerned about new users, I'd recommend exploring hook_civicrm_dashboard_defaults.
Graham, you can not really configure these dashlets, they are not based on existing CiviCRM reports but code specifically. We have just created a fair number of CiviCase reports (working on one as we speak :-), you would probably have to create/get someone to create a custom version of the dashlets or possibly even a custom report if it would make sense.
Ok, my host support team have now fixed the problem. Here's what they did:
In /etc/hosts, your website XXXXXXXXXXXXX.co.uk was pointing to one
server IP address, but the Civi website was running on the other IP
address. I corrected that and things are working now.
Civi seems to be a little unusual in that it fetches sub-pages via php
You didn't mention which CMS you are using, and this is CMS-dependent feature. In Drupal, for example, you would select from the menu Structure | Blocks and then find the item labeled "CiviCRM Recent Items" and select "Sidebar First" for its region for the theme that you are using for CiviCRM (which can be different for admins, and there is a setting at ...
At least until the most recent 4.7 releases, CiviCRM needed to contact itself via http to populate the dashboard. Your picture suggests that it's not able to, probably related to how the proxy is setup. If you have a command line interface in environment that the code is executing, see if you can contact yourself using, say curl or wget. Sometimes hardcoding ...
I'm glad you found the cause of your problem. It does sound like something went wrong back when you originally created those dashlets, and it's not clear what that was. But it would be good to proactively repair this during the upgrade.
I've created a PR to do so: https://github.com/civicrm/civicrm-core/pull/9672
This setting has been moved to each Reports(Access Tab). Major improvements related to dashlet has been done in 4.7.11 version. Hence, if you wish to change the cache timeout.
Navigate to any Reports.
Click on Access Tab.
Enable Available for Dashboard? checkbox which displays the setting you need.
Thanks for all your good ideas. Finally I've solved it by going through the first case I've listed above: Civi dashboard and menus won't display after install.
Though I could neither access the menu nor find the resource URL in my database, I found a link to the administer page in the case, which is wp-admin/admin.php?page=CiviCRM&q=civicrm%2Fadmin&...
Problem is Flash being blocked. Although it is globally enabled, for some reason it is being blocked. Solved problem with this process to specifically trust site for Flash.
The dashboard issue is a known issue in CiviCRM 5.4. The latest version of CiviCRM solves this. I'm not sure if that would also affect the extensions directory though. Please comment on this answer if it does though!