Blog

The CiviCRM Installation Guide for Drupal 9 says to run these three lines of code: composer config extra.enable-patching true composer require civicrm/civicrm-asset-plugin:’~1.1′ composer require civicrm/civicrm-{core,packages,drupal-8}:’~5.35′ We edited that last one to end with the latest version of CiviCRM, which today is 5.35, but anyhow if you run these commands today, on the second and third you will see this error: $ composer require civicrm/civicrm-{core,packages,drupal-8}:’~5.34′ ./composer.json has been updated Running composer update civicrm/civicrm-core civicrm/civicrm-packages civicrm/civicrm-drupal-8 Loading composer repositories with package information Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 – Root composer.json requires civicrm/civicrm-core ~5.34 -> satisfiable by civicrm/civicrm-core[5.34.0]. – civicrm/civicrm-core 5.34.0 requires… Read More

Continue Reading

This week one of our clients asked if we could help to convert a large Word document to MediaWiki pages. His document was separated into 30 small “chapters” and he wanted each one to be its own page. We said no problem and we converted that for him, including footnotes. How did we do it? Good question. First trick is to open the file in LibreOffice Writer. Next is to copy and past one chapter into another document and then you can export that in MediaWiki format. Do that 30 times and now you have 30 text files. But they have some garbage “anchor” code that comes out ugly red… Read More

Continue Reading

We have now had our third client complaint that public CiviCRM pages don’t work — no data appears on the page. We investigated and could not find a cause. Two clients said that Event pages didn’t work and one said that a Contribution page didn’t work. The solution we can offer for such cases is to use a regular WordPress “Page” for the Event Info page and include there a link to another regular WordPress “Page” which will be the Event Registration page. The trick is that in this Event Registration page we put in a shortcode like this: [civicrm component=”event” action=”register” id=”16″] This is valid to do as CiviCRM… Read More

Continue Reading

CiviCRM uses the URL: /libraries/civicrm/extern/soap.php for unsubscribe links and other tools. On a default Drupal 8 install, such a URL is blocked by the .htaccess file. To fix that, add these lines: RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/authorizeIPN.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/cxn.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/ipn.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/open.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/pxIPN.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/rest.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/soap.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/url.php$ RewriteCond %{REQUEST_URI} !/libraries/civicrm/extern/widget.php$ to that file just after this line: RewriteCond %{REQUEST_URI} !/core/modules/statistics/statistics.php$ That should fix it.

Continue Reading

A client contacted recently to ask for help in automating data entry to their Google Spreadsheets. They were copying and pasting information from form submissions, and also donations, into their spreadsheets manually. They hired us for a few hours of labor and we used the Google Sheets API and set up for them a system to automate all of those tasks. They investment they made will pay for itself soon as these tools will now save them hours of labor each week.

Continue Reading

All of our servers now support PHP 7.4. You can read more in the official guide for migrating from PHP 7.3.x to PHP 7.4.x here: https://www.php.net/manual/en/migration74.php PHP 7.4 brings performance improvements over previous PHP versions. From now all new accounts on our servers will have PHP 7.4 as the default PHP version. Existing accounts can be easily switched to PHP 7.4 via the hosting Control Panel > PHP Settings > Default PHP Version tab.

Continue Reading

CiviHosting has now a new feature — our “Marketplace” or “Client Area.” Managing your existing services and ordering new ones, including domain name transfers, is now all available easily online at one place. The URL of our Client Area is https://clientarea.civihosting.com/ but to login most easily for the first time, visit your hosting Control Panel and click on the Marketplace tab. Then click on Login and you will be able to set your password and then login. Once in, you can see all of your existing services with us, renew them, and add more services. If you have multiple hosting accounts, they are all initially associated with separate accounts in… Read More

Continue Reading

We recently migrated and then upgraded a MediaWiki, and the upgrade was a major upgrade. It run successfully, but then tome pages, such as the home page, showed errors like this: MediaWiki\Revision\RevisionAccessException from line 1676 of /home/mysite/www/www/includes/Revision/RevisionStore.php: Main slot of revision 38921 not found in database! We found several reports of this error online and the Mediawiki RevisionAccessException forum page on https://www.mediawiki.org/ suggests a solution. We tried that and found that using $wgMultiContentRevisionSchemaMigrationStage = SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD; in LocalSettings.php fixed the problem.

Continue Reading

Let’s Encrypt recently announced a very serious issue called the CAA bug. You can read up for more details about it on the Let’s Encrypt Community site Arstechnica blog Sucuri Blog CiviHosting was quick to act. Our system administrators checked all the Let’s Encrypt certificates installed on our servers, and we reissued any affected ones, before the issue came to be a problem for any of our clients.

Continue Reading

Semantic MediaWiki by default comes with a set of words that it will not search on. See here for details: Full-text_search Recently we had a client who wanted to disable this on his site so that users could search for words like “everybody” and “everything” on his site. So we changed the MySQL table type of the searchindex table from MyISAM to InnoDB and that fixed the issue.

Continue Reading