Applying a patch to a standard install doesn't require you to switch it over to Git. You can just apply the patch from a given PR (let's say it is PR #12345) like so from the command line:
patch -p1 < 12345.diff
To add to Erik's, here are three advantages to separating the databases:
1) Upgrades. When we are working to upgrade Civi, I know that the website side of the house is largely unaffected (not completely unaffected, but mostly), and if something in the upgrade goes awry, I'm only having to deal with the Civi side of things (especially in the event of ...
we have a slightly different approach for an enhanced security architecture using a proxy-server plus vpn. If you are interested, please sind more information plus code on GitHub, there was also a session on last year's CiviCon.
Let me know if you have any questions regarding CiviProxy.
There's no single perfect solution to this, but there are several adequate solutions. To highlight some trade-offs among the approaches raised so far:
For each security principal, use separate data-directories (like bgm's answer).
Pro: Portable -- works in many different environments. Doesn't require any special tools or root permissions.
Con: Only works ...
My standard practice is still to have them separately simply because I prefer the overview as a developer. And obviously you have to make sure the backup is OK, but if they never checked that (or tested it) I would see that as a bigger issue than having it in one database :-)
Ok so this may seem like a silly issue to some but after some messing around I figured out cron didn't have access to the path where CV was installed so to fix it the crontab entry had to be changed to:
*/5 * * * * /usr/local/bin/cv api job.execute --user=admin --cwd=/var/www/html/siteroot
There was no error as the mailer deamon was not firing correctly so ...
If you're lucky, you just need to turn on the php op-code cache. My experience using on Centos6 was that it wasn't on by default. But I'm intrigued if your slow execution time is specific to CiviCRM. If it isn't, your server specs sound reasonable, but there are many devils in the details, and I'd tend to agree with Hershel that you should go back and make ...
This would appear to be a fairly general question of Linux server optimization, which is a complicated subject. The details of such optimization depend on a myriad of factors and settings and is, generally speaking, not the kind of thing that can be answered on a site like this--it depends as much upon the hardware as it does on the software and settings.
I use separate database whenever possible, for a few reasons, many of which Allen already covered. In addition, I am often responsible for migrating data to a new CiviCRM installation while a coworker (or another dev shop) is responsible for CMS implementation. This allows me to give frequent updates to the client on a test server without coordinating with ...
Setting directories group-setuid might get you part of the way (with chmod g+ws templates_c), but maybe we should consider something like this in the CiviCRM drush module?:
$config = CRM_Core_Config::singleton( );
$config->configAndLogDir = $config->configAndLogDir . 'drush/';
$config->templateCompileDir = $config->templateCompileDir . 'drush/';
I like that drush make or composer reduce the amount of code in your repository, and encourage IMO better development workflows (eg submitting and documenting patches rather than forked codebases).
However I am also running into challenges using Drush, which is quite Drupal-centric and requires some working around rather than with if you don't do what it ...
Our solution to mixed access to CiviCRM's cache files (and other situations where permissions issues arose) has been a daemon which monitors filesystem entries and "corrects" permissions immediately on file creation/modification.
Enforced on Github
There are still some issues with this approach (eg issue linked in comment on bgm's answer), but it seems to ...
Tim describes a solution based on linux ACL:
But it requires amp, that I (might be wrongly) see a dev only tool. Does someone use something like that in production?
As long as your PHP and MySQL settings are correctly set (CiviCRM should warn you if they are not), you can set the server time to your preference. Using UTC for the server is probably more convenient on the long term, but it's not a CiviCRM requirement. For example, lets say you are in UTC-8, but next year a new sysadmin joins your team and is in UTC+6, UTC-...
This turned out to be an unexpected odyssey.
This error was misleading, and actually indicated that some of the page elements were being returned with 0 bytes.
Those elements were civicrm php urls, and most of the errors we noticed where from a 4.7 installation.
There were unhelpful messages in the php error log until I turned on 'catch_workers_output=yes' ...
Is the user "admin" defined in Drupal? If not some commands will not fire under cv. cv needs a user under "username" that is recognized by Drupal as having the rights to fire the command you're interested in. I had this same issue myself which was fixed by identifying an authorized Drupal user.
I've configured CiviCRM behind both Pound and NginX. Both worked perfectly well, no complaints. If there were any special configurations required, they can't have been troublesome enough to remember :)
You will need to ensure CiviCRM is capable of "accessing itself", since some requests (eg dashboard contents) are made to the current CiviCRM website. This ...
One more thing further to the answers so far: moving to a different CMS. If, for whatever reason, you want/need to move civiCRM to a different CMS this is quite simple if the databases are separate. I've done it, so don't say it will never happen.
If you have recently moved from one location to other or DB.
please follow the link which should fix the issue