New API Updated

Gin Admin Theme

Contents of this file

• Introduction
• Requirements
• Installation
• Configuration
• Troubleshooting
• Maintainers

Introduction

A radically new UI layout paired with goodies like a Darkmode will give your Drupal's Admin interface a facelift. The Gin theme also includes things which are currently out of scope for Claro and/or some customisations we're experimenting with for the future. Built on the foundation of Claro from one of the lead designers of Claro & Drupal Design System.
Gin can be used in a headless environment, as it provides a nice login screen which is missing in the default Drupal admin themes.

• For a full description of the module, visit the project page.
• Use the Issue queue to submit bug reports and feature suggestions, or track changes.
• Documentation can be found here.

Requirements

This theme requires Drupal core >= 9.0.
Note: For all functions to work properly, it is recommended that you also install Gin Toolbar.

Installation

Install as you would normally install a contributed Drupal theme. See Gin documentation or visit https://www.drupal.org/node/1897420 for further information.

Set Gin as default admin theme

• Navigate to Admin > Appearance
• On the same page, click "Install" under Gin
• At the bottom of the page, switch the Administration theme to Gin

Troubleshooting

• Setup Gin locally that you can compile CSS & JS files.
  nvm use && npm i
• Run dev env with watcher and debug output (development process)
  npm run dev
• Compile assets
  npm run build

Maintainers

Current maintainers:

• Sascha Eggenberger (@saschaeggi)

Introduction

Project Browser (PB) makes it possible to find modules within your Drupal installation. It removes the need to leave the admin UI and visit Drupal.org to find and install modules. It is build to be a more intuitive experience than the module listing on Drupal.org. Only modules compatible with your site are displayed, and enhanced filtering capabilities provide a streamlined view of projects.
Project Browser queries the Drupal.org API in real-time to ensure that the content is easily accessible and up to date. (You may write a plugin to switch using the Drupal API for your own backend if you wish.)
Our goal is to make it easier to find and install modules for people new to Drupal and site builders. Developers will also find this valuable since it provides the composer commands to get the modules.

• For the description of the module visit: https://www.drupal.org/project/project_browser
• To submit bug reports and feature suggestions or to track changes, visit: https://www.drupal.org/project/issues/project_browser?categories=All

Requirements

This module requires no modules outside of Drupal core.

Installation

If you intend to contribute to Project Browser, skip this step and use the "Contributing" instructions instead
Install with composer: composer require drupal/project_browser then enable the module.

Contributing

• Follow the Git instructions to clone project browser to your site
• In the /project_browser directory, install PHP dependencies with composer install
• In the /project_browser/sveltejs directory:
  • install JS dependencies with yarn install
  • For development, run the dev script yarn dev which will watch for filesystem changes
    • Note: yarn dev will report the app is available localhost, but it is fully available in your Drupal site at admin/modules/browse
  • When you are done, compile the changes with yarn build

NOTE: More information is available in the contributor.md file!

Configuration

Navigate to Administration > Extend > Browse.
Filter by Recommended projects or All projects
Search and filter by Title, Sort By, Order and Categories
Customize results layout by List or Grid Format

Maintainers

• Leslie Glynn (leslieg) - https://www.drupal.org/u/leslieg
• Chris Wells (chrisfromredfin) - https://www.drupal.org/u/chrisfromredfin
• Ron Northcutt (rlnorthcutt) - https://www.drupal.org/u/rlnorthcutt
• Tim Plunkett (tim.plunkett) - https://www.drupal.org/u/timplunkett
• Matthew Grasmick (grasmash) - https://www.drupal.org/u/grasmash

This is a sample

A nice sample markdown page
Here goes some code


Search API
This module provides a framework for easily creating searches on any entity
known to Drupal, using any kind of search engine. For site administrators, it is
a great alternative to other search solutions, since it already incorporates
faceting support (with Facets) and the ability to use the Views module for
displaying search results, filters, etc. Also, with the Apache Solr
integration, a high-performance search engine is available for
this module.
Developers, on the other hand, will be impressed by the large flexibility and
numerous ways of extension the module provides. Hence, the growing number of
additional contrib modules, providing additional functionality or helping users
customize some aspects of the search process.

• For a full description of the module, visit the project page.
• To submit bug reports and feature suggestions, or to track changes, use the
  issue queue.

Table of contents

• Requirements
• Installation
• Configuration
• Information for developers
• Maintainers

Requirements

No other modules are required. If you want to use a different backend than the
database (for instance, Apache Solr or Elasticsearch), you will need to install
the respective module providing the required backend plugin.

Recommended modules

There are several very popular modules for extending the functionality of this
module:

• Facets: Allows you to place facets (filters with dynamic options lists) on
  searches created by this module.
• Search API Autocomplete: Allows you to add autocompletion to searches
  created by this module.
• Search API Solr: This is the most popular and well-maintained search backend
  module for the Search API. It provides integration with the Apache Solr
  search backend.

Installation

• Install as you would normally install a contributed Drupal module. For further
  information, see Installing Drupal Modules.

Configuration

After installation, for a quick start, just install the “Database Search
Defaults” module provided with this project. This will automatically set up a
search view for node content, using a database server for indexing.
Otherwise, you need to enable at least a module providing integration with a
search backend (like database, Solr, Elasticsearch, …). Possible options are
listed at Server backends and features.
Then, go to /admin/config/search/search-api on your site and create a search
server and search index. Afterwards, you can create a view based on your index
to enable users to search the content you configured to be indexed. More details
are available in Getting started. There, you can also find answers to
frequently asked questions and common pitfalls to avoid.

Information for developers

The Search API provides a lot of ways for developers to extend or customize the
framework.

Hooks

All available hooks are listed in search_api.api.php. They have been
deprecated at this point, though, and replaced by events. Hooks will be removed
from the module in version 2.0.0.

Events

All events defined by this module are documented in
\Drupal\search_api\Event\SearchApiEvents.
In addition, the Search API’s task system (for reliably executing necessary
system tasks) makes use of events. Every time a task is executed, an event will
be fired based on the task’s type and the sub-system that scheduled the task is
responsible for reacting to it. This system is extensible and can therefore also
easily be used by contrib modules based on the Search API. For details, see the
description of the \Drupal\search_api\Task\TaskManager class, and the other
classes in src/Task for examples.

Query tags

When trying to modify a specific search query, or set of search queries, it is
useful to know the tags placed on those queries. These will allow you to use the
tag-specific "search_api.query_pre_execute.TAG" events, or identify the search
queries in question in a general "search_api.query_pre_execute" event listener.
The following query tags are known to be used either by this module or other
contrib modules:

• alter_cache_metadata: This tag is used by the Search API module’s Views
  integration to mark a "query_pre_execute" event that is only used to collect
  static cache metadata for the view. Therefore, most listeners should ignore
  the "query_pre_execute" event in this case. See this issue for details.
• views, views_VIEW_ID: This tag is placed on all search queries executed by
  the Views integration of this module. Additional query tags can be specified
  with the “Query Tags” option in the view itself.
• server_index_status: This tag is placed on the filter-less search query
  executed on a search index’s “View” tab to determine the “Server index status”
  to display. Therefore, this query should not be modified in almost all cases.
• search_api_autocomplete: Placed by the Search API Autocomplete module on
  all search queries created by that module.
• mlt: Used by the Search API Solr module to mark search queries executed
  for the “More Like This” functionality.

Plugins

The Search API defines several plugin types, all listed in its
search_api.plugin_type.yml file. Here is a list of them, along with the
directory in which you can find their definition files (interface, plugin base
and plugin manager):
| Plugin type | Directory |
|-------------|------------------|
| Backends | src/Backend |
| Datasources | src/Datasource |
| Data types | src/DataType |
| Displays | src/Display |
| Parse modes | src/ParseMode |
| Processors | src/Processor |
| Trackers | src/Tracker |
The display plugins are a bit of a special case there, because they aren’t
really “extending” the framework, but are rather a way of telling the Search API
(and all modules integrating with it) about search pages your module defines.
They can then be used to provide, for example, faceting support for those pages.
Therefore, if your module provides any search pages, it’s a good idea to provide
display plugins for them. For an example (for Views pages), see
\Drupal\search_api\Plugin\search_api\display\ViewsPage.
For more information, see the
handbook documentation for developers.
To know which parts of the module can be relied upon as its public API, please
read the Drupal 8 backwards compatibility and internal API policy
and the module’s issue regarding potential module-specific changes to that
policy.

Server backend features

Server backend features are a way for other contrib modules to cleanly define
ways in which the Search API can be extended. For more information, see
Server backends and features.
The Search API module itself currently defines two features:

• More Like This (search_api_mlt)
  This feature can be used to retrieve a list of search results that are similar
  to a given indexed item. A backend that supports this feature has to recognize
  the search_api_mlt query option. If present, it contains an associative
  array with the following keys:
  • id: The Search API item ID (consisting of the datasource ID and the
    datasource-specific item ID – passing a plain entity ID will NOT work!) of
    the item for which similar results should be found.
  • fields: A simple array of fields which should be used for determining
    similarity. Backends can choose to ignore this field.
  • field boosts: (optional) An associative array mapping fields to a numeric
    “boost” value that determines how important they should be considered when
    determining similarity. Backends can choose to ignore this field.

  The feature can be used in the UI via the “More like this” Views contextual
  filter.

• Random Sort (search_api_random_sort)
  This feature allows sorting a search query randomly. Backends supporting this
  feature should accept sorts on field search_api_random and, if present,
  apply a random sort to the search query. Optionally, they can also check the
  search_api_random_sort query option for additional specifications, which (if
  present) will be an associative array with any of the following keys:
  • seed: The seed value to use for the random function. This is important to
    support proper paging for randomly sorted search results.

Maintainers

Current maintainers

• Thomas Seidl (drunken monkey)

Views GeoJSON

Table of contents

• Summary
• Requirements
• Installation
• Usage
  • Bounding Box Support
• To Do
• Credits
• Current Maintainers

Summary

Views GeoJSON is a style plugin for Views to deliver location-specific data in GeoJSON format, see RFC 7946: The GeoJSON Format.
Each row is output as a GeoJSON "Features" including geospatial data and optional metadata. All features are wrapped in a "Feature Collection" object.

Requirements

Drupal core modules

• Views
• RESTful Web Services
• Serialization

External projects

• itamair/geophp

Optional Drupal modules

• Geofield
• Geolocation

Installation

Install as you would normally install a contributed Drupal module.
Visit https://www.drupal.org/node/1897420 for further information.

Usage

1. Create a View showing an entity (likely "Content") that includes geospatial data in its fields
2. Click "Add" on the Views configuration screen and choose "GeoJSON export" from the Display type choices
3. Add fields to the Display that include either: longitude and latitude coordinates, a Geofield or Geolocation field, or WKT data
4. The Format for the Display should show "GeoJSON". Choose that format if not already set
5. In the Format area click "Settings" (next to "GeoJSON"), and:
   • Choose "Map Data Sources" specifying the type of data in your field(s) (Geofield, lat/lon, etc.)
   • Assign the particular field(s) that include that data
6. Optionally add fields for title and description of each point/feature, and add these to the Format settings
7. Optionally set a JSONP prefix in Format settings, (see https://en.wikipedia.org/wiki/JSONP)
8. Set the Path, perhaps using your site's API endpoint URL structure or ending with ".json" or ".geojson"

Bounding Box Filtering

GeoJSON views can accept a bounding box as an argument to return only the points
within that box.
It has been tested with OpenLayers' Bounding Box Strategy but should work with
any mapping tool that requests bounding box coordinates as
"?bbox=left,bottom,right,top" in the query string. Argument ID "bbox" is
default for OpenLayers but can be changed.

1. Create a GeoJSON view as above in USAGE
2. Add a layer to OpenLayers of type GeoJSON, at
   /admin/structure/openlayers/layers/add/openlayers_layer_type_geojson,
   specifying the URL to your GeoJSON feed and checking the box for "Use Bounding
   Box Strategy"
3. In your GeoJSON View configuration, add a Contextual Filter of type:
   "Custom: Bounding box"
4. In the Contextual Filter settings, under "When the filter value is NOT in
   the URL as a normal Drupal argument", choose: "Provide default value"
5. In the "Type" dropdown, choose: "Bounding box from query string"
6. For OpenLayers, leave "Query argument ID" as "bbox" and click Apply

To Do

• Support addditional GeoJSON feature types like LineString
• Support an optional altitude coordinate for Point positions
• Support additional coordinate systems

Credits

This module was originally born from a patch by tmcw to the
OpenLayers module and adapted
to model the
Views Datasource module.
Much of the code is drawn directly from these sources.

Current Maintainers

• Jeff Schuler (jeffschuler) - https://www.drupal.org/u/jeffschuler

Views GeoJSON

Table of contents

• Summary
• Requirements
• Installation
• Usage
  • Bounding Box Support
• To Do
• Credits
• Current Maintainers

Summary

Views GeoJSON is a style plugin for Views to deliver location-specific data in GeoJSON format, see RFC 7946: The GeoJSON Format.
Each row is output as a GeoJSON "Features" including geospatial data and
optional metadata. All features are wrapped in a "Feature Collection" object.

Requirements

Drupal core modules

• Views
• RESTful Web Services
• Serialization

External projects

• itamair/geophp

Optional Drupal modules

• Geofield
• Geolocation

Installation

Install as you would normally install a contributed Drupal module.
Visit https://www.drupal.org/node/1897420 for further information.

Usage

1. Create a View showing an entity (likely "Content") that includes
   geospatial data in its fields
2. Click "Add" on the Views configuration screen and choose "GeoJSON export"
   from the Display type choices
3. Add fields to the Display that include either: longitude and latitude
   coordinates, a Geofield or Geolocation field, or WKT data
4. The Format for the Display should show "GeoJSON". Choose that format if not
   already set
5. In the Format area click "Settings" (next to "GeoJSON"), and:
   • Choose "Map Data Sources" specifying the type of data in your field(s)
     (Geofield, lat/lon, etc.)
   • Assign the particular field(s) that include that data
6. Optionally add fields for title and description of each point/feature, and
   add these to the Format settings
7. Optionally set a JSONP prefix in Format settings,
   (see https://en.wikipedia.org/wiki/JSONP)
8. Set the Path, perhaps using your site's API endpoint URL structure or ending
   with ".json" or ".geojson"

Bounding Box Filtering

GeoJSON views can accept a bounding box as an argument to return only the points
within that box.
It has been tested with OpenLayers' Bounding Box Strategy but should work with
any mapping tool that requests bounding box coordinates as
"?bbox=left,bottom,right,top" in the query string. Argument ID "bbox" is
default for OpenLayers but can be changed.

1. Create a GeoJSON view as above in USAGE
2. Add a layer to OpenLayers of type GeoJSON, at
   /admin/structure/openlayers/layers/add/openlayers_layer_type_geojson,
   specifying the URL to your GeoJSON feed and checking the box for "Use Bounding
   Box Strategy"
3. In your GeoJSON View configuration, add a Contextual Filter of type:
   "Custom: Bounding box"
4. In the Contextual Filter settings, under "When the filter value is NOT in
   the URL as a normal Drupal argument", choose: "Provide default value"
5. In the "Type" dropdown, choose: "Bounding box from query string"
6. For OpenLayers, leave "Query argument ID" as "bbox" and click Apply

To Do

• Support addditional GeoJSON feature types like LineString
• Support an optional altitude coordinate for Point positions
• Support additional coordinate systems

Credits

This module was originally born from a patch by tmcw to the
OpenLayers module and adapted
to model the
Views Datasource module.
Much of the code is drawn directly from these sources.

Current Maintainers

• Jeff Schuler (jeffschuler) - https://www.drupal.org/u/jeffschuler