I need to merge two versions of a site that was forked and changes have been made to both.
I have managed to get all the content, fields, nodes, views etc in the database. However they do not all display.
One of the versions uses civicrm which is installed in a separate database. For it to work it had a default db prefix.
This is causing some of the data not to load since the tables are getting the prefixes. If I remove the prefixes than civicrm does not load.
I figured I could use different settings for civicm and use he default for the rest. On my localhost environment I can not get this to work due to how drupal loads the settings.
I did a hotfix to drupal to test out my idea by changing line 327 to $uri = explode('/', $_SERVER['REQUEST_URI'] ? $_SERVER['REQUEST_URI'] : $_SERVER['REQUEST_URI']); it originaly used script_name
That correctly gets the config files to load and my site content is showing! but I can't access civicm even though im logged in to the main site.
CiviCRM's civicrm.settings.php (in the same place as settings.php) has information on how to connect to the Drupal database as well as the CiviCRM database (which may or may not be the same). You should
1. Confirm there is a civicrm.settings.php file in the same spot as your settings.php (sites/default or equivalent)
2. Check within civicrm.settings.php that both database entries are correct, the paths to CiviCRM files are correct, and the URL is correct.
3. Clear everything out of sites/default/files/templates_c (cached templates)
Related
I have been given the task of moving two Drupal-based websites to a new server, not because I'm a Drupal expert but I'm the only one in the office with PHP programming skills. One is a Drupal 7 site, the other Drupal 8. These were both given to me as DevDesktop archives and SQL dumps. The Drupal 7 site was pretty straightforward - copied the contents of the docroot up to the new server, created and populated a new MySQL database and edited the default site settings file to point at the new dbase. So the Drupal 7 site works fine. Doing the same with the Drupal 8 site the main problem seems to be it won't load any CSS or Javascript.
In the Javascript Console it threw me off the scent slightly because it said the mime type of the CSS was incorrect, but on further inspection that's because the path to the CSS was returning a 404.
Compounding the problem is Antibot, and as Javascript isn't loading, although I have the username and password for the admin user, I can't login because Antibot keeps sending me back to the homepage telling me to enable Javascript. I have edited settings.php to enable /core/rebuild.php and tried that, but doesn't appear to make any difference. I've also manually truncated the 'cache_...' tables and that doesn't seem to work either. Note that I DON'T have access to SSH on the new server, so can't use drush.
Refused to apply style from '[]' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.
Failed to load resource: the server responded with a status of 404 (Not Found)
What it does look like to my non-expert eye is that Drupal is configured somehow to server up optimised versions of the CSS and JS from virtual directories /css/ and /js/, although those paths don't actually exist on the server. I checked the .htaccess file, but other than some clever stuff to deliver gzipped versions to gzip-capable browsers, couldn't see anything in there that would get the server to the correct file. Perhaps if someone could explain how Drupal routes a request to /css/ or /js/ to the right file, that would help my understanding further.
Ultimately I think this problem is because Drupal 8 wants to deliver optimised files, but the cache is screwed and Antibot won't let me get into admin to turn off aggregation.
I have full access to the server files and database, but not drush. Is there a way to turn off the CSS & JS aggregation apart from via the admin menus?
In this situation you can disable aggregation either :
by editing settings.php or settings.local.php :
/**
* Disable CSS and JS aggregation.
*/
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
or via sql, but you have to decode and unserialize blob data from the config table to make the changes, and then make the reverse process :
# Query :
SELECT name, CONVERT (`data` USING utf8) FROM config WHERE `name`='system.performance';
# Unserialize query output and edit data locally
$config = unserialize($output);
$data['css']['preprocess'] = FALSE;
$data['js']['preprocess'] = FALSE;
# Then serialize data and write it back into the config table
# (original encoding is probably `LONGBLOB` but it may differ depending on the backend).
Once you can ssh into the server, you will need to reset permissions and ownership under sites/default/files/ before enabling aggregation again :
mkdir -p sites/default/files/{css,js}
chown -R apache:apache sites/default/files/
chmod -R 0755 sites/default/files/
You may also want to check if the public file path setting (in settings.php) is properly set according to where these ressources are actually located :
$settings['file_public_path'] = 'sites/default/files';
At my current place of employment I've inherited a Drupal 6 site that I am maintaining and updating. There's a custom module that has some copy in it that needs to be updated.
Naturally, I went in and edited the .module file in my local environment, tested it and it looked great. We pushed the file to our development server and cleared the caches, theme registry etc and the change will not take place. It is still reading as the old copy.
As I've said, I've cleared the cache, deactivated/reactivated the module etc.. I've even tried to run update.php but the module in question doesn't actually appear in that list (there's no hook_update in this module it would seem). Is there some other trick to getting Drupal modules to register a change in the code?
One possibility is that the PHP process is not reading the new file but has the old one cached. You should restart your php-fpm or apache, depending which way you are running the site, to make sure the APC or Opcache are cleared as well.
I would also double check the content of the actual .module file to be extra certain that the new version is really there.
Yet another possibility that comes to mind is that you'll have to make sure you are updating the code in the correct location, ie you need to double check that the web server is serving Drupal from the location you are updating.
I want to do developments on my client's website but by making a clone of it. So, main website url is: http://website.com and the clone i am trying to create is: http://test.website.com.
So far i've done the following:
copied entire root directory into public_html/test dir (with folders config,field,FirePHPCore,fontyourface,includes,js,misc,modules,scripts,sites,styles and themes)
created a subdomain in cPanel for test.website.com
checked the file settings.php (inside sites/default folder) for $base_url but found it commented, so left it as it is unchanged.
copied db via phpMyAdmin and updated the new db details in settings.php (inside sites/default folder).
inside the table variable, two rows with the name securepages_basepath and securepages_basepath_ssl. Changed their values from http://website.com to http://test.website.com (using the variable_get and variable_set functions).
Now i can access http://test.website.com but when i click on login (from header) it takes me to http://website.com/user and if manually type http://test.website.com/user and login then it takes me to http://website.com/users/admin then i have to manually type in correct address http://test.website.com/users/admin.
And when i logout, it again takes me back to http://website.com.
So i want to know how can i completely make it to work on http://test.website.com?
Are there more variables to change?
And how i can make 100% sure that the test site is only using test and not the live site. I am afraid of messing up live website.
Please advice, thanks!
I fixed it by disabling the secure pages from inside the mysql database. It was inside variable table and securepages_enable field. It was in blob so i had to download the blob first and opened it in notepad and changed the value inside it from 1 to 0 and then uploaded it back by updating the securepages_enable field.
I had to do this because after logging in from my test url, the urls were redirecting back to the live website, so whatever change i was making, it was all affecting the live site.
Hope this helps to someone with similar case. Thanks!
I'm having some trouble with an Umbraco website. Some times some Media files disappear.
The nodes still exist but the actual 'physical' file is gone.
Also the folder the media file was in doesn't exist anymore.
The users of the CMS are unable to log in on the server, so they couldn't accidentally delete the files them self. Only me and my colleagues have access (and we wouldn't log in to a server unless it's necessary)
I just checked the disk space, and there are several gigs on all disk available.
We did a migration of the media folder some time ago, so we thought it might have something to do with it. We have analysed the file system backup of the whole Media folder and those items are not there as well so we can exclude the possibility of a problem on the filesystem.
The version we are using is: Umbraco v 4.7.1.1 (Assembly version: 1.0.4868.25172)
If you clone content nodes with media files attached using an Upload property type, both nodes will point to the same media element. If you replace or remove the file on one node, it will remove the physical file. The original node will still have the reference to the removed file. This makes it appears as if a ghost is deleting images, but its Umbraco 4 deleting the file when you publish your change.
The best way to solve this is to convert your property from type Upload to type Media Picker.
I had this problem in sites around umbraco v4.5. I never run into this issue on Umbraco 6 and 7. But, on those systems, I use the media picker instead of upload for all media-like elements.
There are no issues I know of with Umbraco 4.7.x deleting its own media. It is possible to do it remotely, but that would delete the nodes as well as the physical files.
The only cause is the one which seems most unlikely, and that is someone has accidentally deleted them. I find this occasionally happens when deploys are done. Someone replaces the media folder with the one from the staging environment.
I have also seen an issue if files are copied across an RDP connection, the files being copied are not copied completely and in the process some actually disappear from the target folder.
But either way, I would check your internal processes, maybe move the media folder to a virtual directory to avoid the chances of it being overwritten.
There is one case in which media files might be deleted, and that is when you are using the Upload datatype on a document type.
What happened before on a system that I managed was that editors copied a page that included an image previously uploaded, but never updated the image, leaving the same path as the value for the Upload field.
In this scenario, you would have 2 published pages that have a field with the same path.
Now, if one editor decides to delete the page, the media file is also deleted.
This would leave the copied page with a broken link to the image and a missing image.
I have recently moved a drupal site. (both servers run on a debian based LAMP stack) Everything works great here, including the uploading of images via a CCK filefield. Original url:
dev.example.com/foo
Deploying it to a test folder on the production server to a test folder for an environmental shakedown cruise lead it here:
www.example.com/foo
Everything works here too, including image uploads. After adjusting sites/default/settings.php, then making it readonly again, I renamed the folder to its production name:
www.example.com/bar
Everything works fine here except for image uploading. I've adjusted the webroot variable within settings.php .
Things I have tried so far:
Gave php system user write permissions to sites/default/files (images are set to go in sites/default/files/images but imagecache just puts them in sites/default/files)
Enabled file php file uploading for www.example.com/bar/sites/default/files
Are there any other configuration settings I should be looking out for here? I'm running low on relevant solutions.
Edit: I had quite the typo there, I adjusted sites/default/settings.php, not sites/default.settings.php .
Your question is slightly confusingly framed. default.settings.php has no impact on Drupal -- its merely a template. The file that contains the actual database connection information and other configuration is settings.php.
You may also want to look at your .htaccess file in your root Drupal folder and try changing the RewriteBase directive to the folder you are accessing your site on. Usually you should not have to change the $base_url directive in the settings.php file that you may/may not have done. Reverse that change for now if you have (you may need to play around with that later though).
imagecache will always upload the image derivatives in sites/default/files but imagefield will upload the original image in the folder you specify (within sites/default/files). You will get a setting for the imagefield under Manage Fields->[Name of Image field]->Configure under Path Settings.
Please google to understand the difference between imagecache and imagefield. Make sure your sites/default/files (and subfolders) are writable by the apache user (usually www-data).
In such situations, its usually a good idea to pick up a book on apache (if you haven't already) and try to understand how it works. It will be time consuming but will help you out in the future when you encounter configuration issues like this.
This worked for me. When having issues uploading images to a cck field, I gave write permissions to directory:
sites/default/files/field/image