According this page https://api.drupal.org/api/drupal/core%21includes%21bootstrap.inc/constant/CONFIG_ACTIVE_DIRECTORY/8.3.x
constant CONFIG_ACTIVE_DIRECTORY
Will be depecrated before Drupal 9 comes out.
In the current 8.3.x Drupal release I get errors when trying to remove the active directory constant from the config_directories array in settings.php and extra setting for storage plus remove the dependent services configuration in services.yml for active storage. See here: https://www.drupal.org/node/2291587#comment-10426135
Is it not possible to use just the sync directory constant then? The documentation is confusing:
https://www.drupal.org/docs/8/configuration-management/changing-the-storage-location-of-the-sync-directory (sync directory constant)
https://www.drupal.org/docs/8/configuration-management/file-system-based-workflow (again the deprecated staging and active directories).
Related
I have done the following:
installed a clean Sitecore 7.5 instance
added the relevant asp.net web forms controls and pages to support the site
imported and published a content tree from an old application
Visiting the base site url yields a YSOD with the error message:
Could not find configuration node: contactRepository
Now I understand what this means - there's an expected configuration section that is missing. Adding an empty element contactRepository yields an expected message that this section is not defined.
What is contactRepository, what is its associated configuration section type, what is it for and what values should be specified in it? Alternatively, how can I turn off whatever demands this section to be present?
edit #1:
In the Sitecore.Analytics.config file in the node there are the following two lines:
<!--This configuration node is obsolete and will be removed in a future version of Sitecore. Use "contactRepository" node to get access to Contact repository-->
<contactRepository ref="contactRepository"/>
The comment is total gibberish. Which node? 'Use' how? 'get access' in what sense? How is this different to what's there?
replacing with an empty <contactRepository> without the ref attribute, commenting out this node, both nodes, and the whole tracking node makes no difference to the application's behaviour.
Looking at my local Sitecore 7.5 setup the Contact Repository settings should be in your Sitecore.Analytics.config.
The contacts repository settings relate to the new xDB stuff.
Please ensure you have the correct Sitecore.Analytics config files for 7.5.
There should be around 15 config files with new settings for xDB.
Please read this blog post for more information on the new Analytics setup.
https://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2014/10/introducing-the-sitecore-analytics-index
I have one virtual server with 2 installations of drupal. One is for testing purposes. Is it possible to restrict usage of APC to certain directories only, so the testing page won't eat the same amount of resources as production site? My files are installed on server like this:
data/web/mydomain.com/web - I want to use apc here.
data/web/mydomain/sub/test - I do not want to use apc.
Thank you
To answer your specific question: Is it possible to restrict usage of APC to certain directories only? Yes.
Use the apc.filters directive in your apc.ini file:
A comma-separated list of POSIX extended regular expressions. If any
pattern matches the source filename, the file will not be cached. Note
that the filename used for matching is the one passed to
include/require, not the absolute path. If the first character of the
expression is a + then the expression will be additive in the sense
that any files matched by the expression will be cached, and if the
first character is a - then anything matched will not be cached. The -
case is the default, so it can be left off.
So, to exclude the testing directory, add the following to your apc.ini file and restart apache:
apc.filters = "-/data/web/mydomain/sub/test/.*"
Also, at sub-site level in drupal you can achieve this by adding following line in settings.php:
ini_set('apc.enabled', 1); // 1 to enable & 0 to disable apc for a sub-site.
You can have APC disabled in your global php.ini by default and enable it exclusively in a custom php.ini for the document root in question. This would definitely depend upon your httpd/php configuration, I.e. DSO/suPHp
I followed Backup and restore method in alfresco share instead of import/export. It is now working as i expected in new Alfresco, i can see the content in sites, can view files in site document library, can view events, workflow,users,groups and so on. Everything goes fine except that the repository is not loading, but When i search for files in repository it is showing "3 result(s) found in Quality site."...but it is not displaying those files.
In my old Alfresco i have set permissions for folders in repository...will it cause any error to load repository in my new alfresco?
It shows following error when i close my server...
log4j:ERROR LogMananger.repositorySelector was null likely due to error in class reloading, using NOPLoggerRepository.
Kindly look into my issue and give some suggestion......
that error means that the log4j tries to log something in the log file of the webapp but Tomcat already shut down. have you sufficient/right permissions on the new restored alfresco installation?
If you followed correctly the backup/restore procedure from the wiki, the permissions on nodes of the repository also come together. But, if you want to reset and rebuild all the permission, you could perform a FULL reindex with the string appended to alfresco.global.properties:
index.recovery.mode=FULL
I recently switched my development machine from Windows XP to Windows 7 and since that switch, I have a problem with files permissions when I do operations with Tortoise SVN.
Example:
I Have two ASP.NET website set on my local IIS. Beta and Devlo. Beta is a check out of the branch I'm working on and Devlo is a check out of the Trunk.
I made some change on the Beta website and Check it in.
Then I made a merge to reintegrate the branch in the truck on the Devlo website, but I got this error when I test it :
Parser Error
Description: An error occurred during the parsing of a resource required to
service this request. Please review the following specific parse error details
and modify your source file appropriately.
Parser Error Message: Access to the path 'C:\[...]' is denied.
After investigation, I discovered that every file that was modified by the Tortoise SVN merge lost theirs file permission (Read, Read & Execute) for the users IUSE and IIS_IUSRS.
I could manually put them back, but this happen every time I perform an operation of this kind. Is there a way to keep those permissions unchanged by the SVN operation?
Update
Before the Merge, the file was inheriting is permission from the parent folder (has it's supposed to do.)
But not after the merge :
The original file (in the beta folder) was inheriting is permission from the parent folder.
Why the TortoiseSVN (explicitly?) block permission inheritance?
I had the same issue and fixed it with the help of this SO answer: https://stackoverflow.com/a/8993163/361831
The answer mentions that updated files are copied to a .svn/tmp directory which is located in the top level of your working copy (as of tortoiseSVN 1.7). This top level dir didn't have the IIS permissions so I guess they weren't inheriting during the copy. So I just set the IIS permissions to that top level dir and set to inherit, and that fixed the issue.
When subversion updates a file it first creates a temporary version in .svn/tmp/. It then moves the file into the right location. (This to avoid corruptions)
In 1.6 it did this for every directory by itself, but in 1.7 there is just a .svn in the top level directory of your working copy.
If somehow the filesystem permissions of this .svn directory are restricted, it is possible that the restrictions are copied with the file when it is moved in place. (Subversion doesn't change the permissions itself on Windows)
ANSWER: Locate your .svn directory for that project and fix the permissions with permissions needed by your project.
You should be able to set these permissions on the folder that contains the files and then let the files inherit these permissions, instead of explicitly setting the permissions on the files themselves.
TortoiseSVN may delete and create files instead of renaming. When a new file is created this way it will not have the original permissions, but it will inherit permissions from its container.
See also: Explicit vs. Inherited Permissions
Each permission that exists can be assigned one of two ways:
explicitly or by inheritance. For this reason, permissions are
referred to as explicit permissions and inherited permissions.
Explicit permissions are permissions that are set by default when the object is created, or by user action.
Inherited permissions are permissions that are given to an object because it is a child of a parent object.
Similar to the way rights are managed for groups of users, permissions
are best managed for containers of objects. Objects within the
container inherit all the access permissions in that container.
See also: TortoiseSVN - Deleting, Moving and Renaming
Since renames and moves are done as a delete followed by an add...
I had the same problem on both my Win7 64bit machines. I would check in code on one, go to the other, do a Tortoise SVN Update, and have to reset the permissions on the folder to let the parent folder's permissions propagate downwards.
I finally found this article, tried it, and two weeks later it seems to be holding up.
Open the Registry Editor (click Start > Run, type regedit, then press ENTER).
Locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer
With the key selected, on the Edit menu, click Add Value, and then add the following registry value:
Value name: ForceCopyAclwithFile
Data type: DWORD
Value data: 1
Exit the Registry Editor.
http://kb.globalscape.com/KnowledgebaseArticle10473.aspx
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