Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update several files 

Signed-off-by: Vitalii Koshura <lestat.de.lionkur@gmail.com>
Vitalii Koshura 2023-04-09 17:41:26 +02:00
parent 3970f64df8
commit 666ce4889a
No known key found for this signature in database
GPG Key ID: CE0DB1726070A5A3
4 changed files with 4 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
DrupalIntegration.md

@ -64,7 +64,7 @@ The Drupal system ties into the BOINC database in order to display information f
## Code Organization
Drupal is installed in a web directory, typically at the root of a virtual host. Initially, this installation is the Drupal core only and contains no contributed modules or custom code. At the top level of the core Drupal installation is a //sites/// directory. This is where contributed and custom modules are deployed. Hosting multiple sites from one instance of Drupal is possible by creating directories for each site domain here, each with the modules needed for its corresponding site, and an additional //all/// directory for shared modules and themes. In a single-site deployment, the //default/// directory will be used instead of a domain name.
Drupal is installed in a web directory, typically at the root of a virtual host. Initially, this installation is the Drupal core only and contains no contributed modules or custom code. At the top level of the core Drupal installation is a *sites*/ directory. This is where contributed and custom modules are deployed. Hosting multiple sites from one instance of Drupal is possible by creating directories for each site domain here, each with the modules needed for its corresponding site, and an additional *all*/ directory for shared modules and themes. In a single-site deployment, the *default*/ directory will be used instead of a domain name.
![500px](BOINC-Drupal_web_root.png)
@ -90,7 +90,7 @@ Using drush on the command line:
Typical deployment process:
1. Make changes to code and configuration on development system
1. Check Features list for overrides and run //drush fu// (or use the web interface to recreate any overridden Features) to capture changes
1. Check Features list for overrides and run *drush fu* (or use the web interface to recreate any overridden Features) to capture changes
1. Commit changes to relevant git repository and branch, push to origin
1. Pull changes into web root of deployment target (e.g. beta system)
1. Run //drush fr-all// or opt to revert individual Features to apply changes present in code to the Drupal database
1. Run *drush fr-all* or opt to revert individual Features to apply changes present in code to the Drupal database

1
GuiRpc.md

@ -223,7 +223,6 @@ Report power, battery, and WiFi status to the client.
This is used on Android, where the interfaces for this info are in Java
and therefore easier to access from the GUI than from the client.
[=#reset_host_info]
### `reset_host_info()`
Tell the client to get host parameters
(RAM and disk sizes, #CPUs) again.

2
InstallDrupal.md

@ -18,7 +18,7 @@ Basic functionality should now be in place. Create an account and then set its u
# Configure System Features
The Drupal integration system contains a number of //Features//, which are custom meta packages that provide some specific type of functionality. These might be as simple as providing text for a single link or menu, or as complex as pulling together community contributed modules, custom code, site configurations, and content in order to significantly enhance the site wide experience.
The Drupal integration system contains a number of *Features*, which are custom meta packages that provide some specific type of functionality. These might be as simple as providing text for a single link or menu, or as complex as pulling together community contributed modules, custom code, site configurations, and content in order to significantly enhance the site wide experience.
The purpose of Features is to allow for simple deployment of modules and configurations. Rather than install each Drupal module by hand and "replay" any configurations that are required, enabling a Feature automatically satisfies all dependencies required for its logical function and sets default configurations as appropriate. Deployment of Features is best handled on the command line by using drush.

1
SolrIntegration.md

@ -96,7 +96,6 @@ On a redhat system: /usr/sbin/chkconfig --add solr
Once started, the Solr admin interface should be available at: http://localhost:8983/solr/admin/
[=#configsolr]
## Configure Solr Integration
If not already done (i.e. if this is a pre-existing implementation of Solr), copy schema.xml, solrconfig.xml, and protwords.text from the solr-conf directory of the apachesolr Drupal module to the conf directory of the Solr installation (e.g. example/solr/conf). Also, be sure the data directory is exists parallel to the conf directory and that the web service has write access to it.