Disclaimer, as with other answers, this is aimed at a fairly technical person who kinda understands what they're doing and has made lots of backups :-)
As Sophie points out you can find the exact problem looking at the latest log in the ConfigAndLog directory.
For several of us the problem has been that there's a key defined incorrectly and the script's ...
What is the installation canary?
The civicrm_install_canary is fundamentally a test to see how well we control/understand the installation process. It's part of a bigger topic, so bear with me in giving the context.
The crux of the CiviCRM installation process has traditionally been two steps:
Copy a config template and edit it (civicrm.settings.php.tpl =...
The pop-up message should have a link "View details and manage alerts" that takes you to the System Status page. That includes an Update Indices button (yes there is a typo in 4.7.19 but it doesn't affect the function).
Update Indices should create the missing indices which may take a while depending on which indices are missing and how much data you have ...
Yes, running OPTIMIZE TABLES on a regular basis is beneficial. I dont think there is significant risk with it. I'd run it on a copy of the DB first.
If you have the memory on your database server increasing the cache and buffer sizes of mysql is a good thing, IMO
In the past, i've found: https://www.percona.com/blog/ quite a useful resource. Also some ...
The problem is that the database user doesn't have some higher level privileges required for CiviCRM. Ask your ISP support or database administrator to run the following commands for you as the root MySQL user:
-- Assuming a database called "civicrm" and a user called "civicrm_user"
-- and a MySQL version of 5.1.6+
GRANT SELECT, INSERT, UPDATE, DELETE, ...
See this question: Number of contacts vs. hosting space required
Here is a thorough answer to that question: https://civicrm.stackexchange.com/a/3289/105.
The short version: there is no formal limit to how many contacts CiviCRM can store. It really comes down to the amount and type of hardware you have supporting the software. For a record count of 5-10 ...
Exports and backups serve different purposes: 'export' refers to an extract of data to use in another system, 'backup' refers to recovery in the event of system failure, recovery from bad user actions (eg unintended deletes), creating a second copy of the site etc.
If you want a backup, then take a dump of the mysql database with mysqldump or an equivalent ...
The suggestion to increase the join_buffer_size is a good one if your server can afford the 128K. The number of queries with joins on unindexed fields, which need more cache, is not insignificant.
(Background: There are write performance downsides to putting an index on every field that might have a join put on it. I believe in a few places in CiviCRM there ...
Below are the simplified instructions taken from Moving an Existing Installation to a New Server or Location, but specific to answer your question.
Open the file wp-content/plugins/civicrm/civicrm.settings.php in any text editor and change the value for CIVICRM_UF_BASEURL with your new domain name
For CiviCRM Version 4.7 open the file wp-content/uploads/...
Maybe you can try to run the upgrade script again to go from 4.7.10 to 4.7.12
Documented on the Wiki Upgrading CiviCRM for Wordpress .
Summarising the above conversation:
The upgrade of PHP to version made the PEAR DB extension unavailable. So the exception "DB Error: extension not found" was thrown.
Changing to the database connection URL in the civicrm.settings.php using the prefix mysqli solves the problem.
You can retrieve contribution notes via the api using:
civicrm_api3('Note', 'get', array(
'entity_table' => 'civicrm_contribution',
'entity_id' => $contributionID,
Or see the api explorer to generate this in other formats (you can also do it from within a smarty template, for example).
Important: The api returns raw, unsanitized user input. ...
Yes, CiviCRM would be a great match for what you're describing. CiviCRM is a central 'master' information hub that has quite a bit of reach out of the box:
membership data (What Is CiviMember? and the following sections are a good start)
mass emails (which can be integrated with MailChimp via an
Paypal integration for membership payments, ...
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 ...
After upgrading to 4.7.19 I found that indices cannot be created automatically; you can look at your CiviCRM error log to see which database statement is causing a fatal error - you might see problems such as a duplicate index.
In my case I had to run these database statements before/after repairing indices, but it could be different on your site:
Honestly without a significant amount of detail regarding your current database, how you're going to use CiviCRM, what kind of site it is being connected to, etc, no one can give you anything but a huge range - I've seen it done for as cheap as $3,000 and as high as $30,000.
Some things to consider:
How clean is your data? Is there going to be a ...
It sounds like you imported the first_name and last_name values - but the value at the top of the record is the display_name. You have two options:
Use your SQL script to update the display_name accordingly.
Export ONLY the contact_id of the affected records (or all records). Reimport the contact ID via the "Import Contacts" functionality. All records ...
What I did for the sepa extension is a bit of a hack, but worked ok:
write the xml schema files, as you have them on the (development version) core and run xml/phpGencode.php to generate the dao, that you then copy into the extension folders and voila, you got the tables ready to use (for a few more lines, you got the api files, worthwhile IMO)
The process ...
This is a result of someone going in CiviCRM and deleting the Home location type, either through Administer > Customize Data and Screens > Dropdown Options > Location Types or clicking the wrench next to the dropdown of location types on some other form.
It's obviously not a good idea to do that if you have a lot of email addresses, phone numbers, and ...
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 is a tricky one to resolve yourself. You basically need to identify whereabouts in the upgrade it failed. For example it might have done all the tasks for a particular point version & failed afterwards, or it might have run some sql & not completed.
If you look in the db the civicrm_domain table has a field called version. Once you know where ...
Don't overthink it, and don't go out on a limb without a worthwhile reason. So long as MariaDB is truly a drop-in replacement for MySQL, you're fine with that. If somehow MariaDB ceases to be compatible, you'll be able to do an export/import to MySQL, assuming you haven't upgraded your server irreversibly and deleted all of your backups from before then.
There's a difference between how many records a database can hold and how many users need to access the system simultaneously on a regular basis. For the latter it's a much harder question because it depends not just on hardware but usage patterns and where the users are located (network latency), and I mention that specifically because you mention Captive ...
Tested on CiviCRM 4.7: two users can edit the same contact record, however, at the moment of saving the contact record, the second user to save the contact record will get a warning that the contact record has been modified by someone else. The user will then have an option to save anyway or reload the page.
It also works with inline edit:
I'd recommend approaching the problem the other way round: find a hoster that works with the latest versions of Civi rather than find a version of Civi that works with your current hoster. You will be missing out on many new features and security fixes if you choose to run an old version. It will only bite you later.
Is there any reason not to move hoster?...
Had the same problem when I went from 4.7.14 to 4.7.20, same resolution as @mfb but with a different index. Default location for the error logs is
There I found an error adding the index UI_case_contact_id . Coincidentally, this was the first index listed when running the drush ev command per @Kainuk above. ...
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 ...
I had the same problem today, so I looked in the source code.
In civicrm.install there's a function called _civicrm_get_db_config. It's looking in the $databases array for an element with a key civicrm. So I added this to settings.php:
$databases['civicrm']['default'] = array (
'database' => 'civi_db_name',
'username' => 'mysqluser',