There are several things in play at different levels with regard to the CiviCRM extensions directory location. The concepts to be aware of are:
CiviCRM shipping codebase
Drupal's files directory
CiviCRM bundled extensions
As @Demerit's answer states, sites/<sitename>/modules/civicrm/ext contains the extensions which ship with ...
The reason we do that with client sites is because I don’t think it’s a good idea to put code under /files. It belongs at the level of /modules. Permission requirements for code and /files are quite different. Another benefit is that it allows me to more easily put the code for a project in git.
The ext dir that ships in the tarball is for extensions bundled directly with core like IATS. If you put other extensions in there they will get wiped when you upgrade, so it's common to put them somewhere outside the civicrm folder.
See also https://docs.civicrm.org/sysadmin/en/latest/customize/extensions/#enabling-extensions
It's on purpose that it removes the link to the user when you delete. It was added years ago here: https://github.com/civicrm/civicrm-svn/commit/3d9843c5912cb9d77e557b4a8cd4ef711f2cdcbb
and seems related to deduping https://issues.civicrm.org/jira/browse/CRM-6861
But yes Civi will reattach them once you do something that triggers the matching which is ...
I would check what is happening by setting up a Profile with the simplest possible profile eg just First and Last and Email
That will help rule out the issue being related to any of your Fields or permissions related to eg Custom Fields.
I am quite curious about why you are asking this question. My advice would be to install only modules when you have functional need and those modules solve them for you.
It might be even that a module which is used often is completely useless in your context. Or that it breaks other needed functionality.
Having said that the masquerade module is very ...
The CiviCRM stats collector doesn't collect that stat but besides webform_civicrm, it might not be too different from the list you'll see at https://www.drupal.org/project/project_module, which is sorted by most installed by default.
Rules and Organic Groups might be additional ones not high on that list because Civi bundles drupal modules that depend on ...
On which forms do you wish to add the fields/logic?
I feel like there are two questions here:
1) How to build an arbitrary list of options from a third-party source of data (Drupal)
2) How to set the value of one field based on the value of another fields.
For (1), arbitrary lists, you can look into hook_civicrm_fieldOptions, which can dynamically modify ...
Installing CiviCRM on Drupal 7 guide is on the following link https://docs.civicrm.org/sysadmin/en/latest/install/drupal7/ . From your question is quite difficult to tell what you have done or what the issue can be (did you check Drupal db settings, system requirements etc)? What are the error messages if any? Did you test locally before attempting in ...
I see what you're saying. Thanks for reporting. I've never used that alternative before. I believe it's coming from this line where it excludes the docs folder so the symlink is no longer valid.
I've made a ticket at https://lab.civicrm.org/dev/core/issues/1393
Look at the error log file of the webserver (probably apache2). If you see an entry like PHP Warning: POST Content-Length of 21426352 bytes exceeds the limit of 8388608 bytes in Unknown on line 0
you will have to adapt the /etc/php/7.2/apache2/php.ini file in order to rise the value of two parameters to v.gr. 32M:
upload_max_filesize = 32M
post_max_size = ...