rudolfbyker β created an issue.
Point to new docs about GitLab CI, because the instructions on this page are not possible to follow since the changes from https://www.drupal.org/project/project_issue_file_test/issues/3415931 π Remove βAutomated testingβ tab when a project has no DrupalCI testing Active were implemented.
Even with this patch applied, I still get this error after upgrading to version 2.0.15 when visiting admin/structure/taxonomy_manager/voc/foo
Warning: file_get_contents(libraries/jquery.fancytree/dist/jquery.fancytree.min.js): Failed to open stream: No such file or directory in Drupal\Core\Asset\JsCollectionOptimizerLazy->optimizeGroup() (line 175 of core/lib/Drupal/Core/Asset/JsCollectionOptimizerLazy.php).
My knowledge of the search_api
code base is VERY limited. I simply stumbled upon line 221 of FieldsHelper::extractFieldValues
while stepping through the code with xdebug to where my field values are getting lost. I'm not in a position to make good suggestions on the way forward with the code. I just wanted to show a sensible use case that would be solved by this issue.
@Lendude those issues look similar, indeed, but they are marked as fixed, while I can still reproduce this issue by importing the attached `views.view.test.yml` file into a fresh Drupal 10.3.2 instance.
@akhil babu you are correct. With the latest Drupal version, the "Date format" is respected, but the whole thing is still wrapped in HTML. I'll update the title and description of this issue.
Partial workaround: Enable "Strip HTML tags" and "Remove whitespace" under "Rewrite results" when configuring the views field. The only problem is that it's still a string instead of an int when using "U" as the "Date format".
Looking for co-maintainer or sponsorship.
Looking for co-maintainer or sponsorship.
Here is an example from my use case: I have a custom Drupal FieldType with a few different properties, say xmin, xmax, ymin, ymax. None of these are the "main" property. They work together to describe a bounding box. I want to create a custom BBox or RPT data type (See https://solr.apache.org/guide/solr/latest/query-guide/spatial-search.html ). This is how far I got:
Set up the data type:
namespace Drupal\vv\Plugin\search_api\data_type;
use Drupal\search_api\Plugin\search_api\data_type\StringDataType;
/**
* Provides a BBox / RPT data type.
*
* @SearchApiDataType(
* id = "vv_solr_bbox",
* label = @Translation("BBox"),
* description = @Translation("A bounding box field. Useful for finding overlapping ranges in 2 dimensions."),
* fallback_type = "string",
* prefix = "bbox"
* )
*/
class BBoxDataType extends StringDataType {
/**
* {@inheritdoc}
*/
public function getValue($value) {
// @todo I would expect to get the entire field item here.
// $xmin = (int) $value->get("xmin")->value;
// etc...
return "ENVELOPE({$xmin}, {$xmax}, {$ymax}, {$ymin})"
}
}
Set up the data type mapping:
namespace Drupal\vv\EventSubscriber;
use Drupal\search_api\Event\MappingFieldTypesEvent;
use Drupal\search_api\Event\SearchApiEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
/**
* Subscribe to events from the `search_api` module.
*/
class SearchApiEventSubscriber implements EventSubscriberInterface {
/**
* {@inheritDoc}
*/
public static function getSubscribedEvents(): array {
return [SearchApiEvents::MAPPING_FIELD_TYPES => 'onMappingFieldTypes'];
}
/**
* Handle the `search_api.mapping_field_types` event.
*/
public function onMappingFieldTypes(MappingFieldTypesEvent $event) {
$mapping = &$event->getFieldTypeMapping();
$mapping['field_item:my_bbox_field_type'] = 'vv_solr_bbox';
}
}
Search API config at search_api.index.commentary_comments.yml
:
field_settings:
my_bbox:
label: BBox example
datasource_id: 'entity:node'
property_path: field_my_bbox
type: vv_solr_bbox
dependencies:
config:
- field.storage.node.my_bbox_field_type
Solr config in schema_extra_types.xml
:
<fieldType name="bbox" class="solr.SpatialRecursivePrefixTreeFieldType" geo="false" distanceUnits="kilometers" worldBounds="ENVELOPE(0,4800,1,0)" />
Solr config in schema_extra_fields.xml
:
<dynamicField name="bboxs_*" type="bbox" indexed="true" stored="true" multiValued="false" />
<dynamicField name="bboxm_*" type="bbox" indexed="true" stored="true" multiValued="true" />
But the problem is that, in FieldsHelper::extractFieldValues
on line 221, it returns an empty array when there is no main property:
// Process complex data types.
if ($definition instanceof ComplexDataDefinitionInterface) {
$main_property_name = $definition->getMainPropertyName();
$data_properties = $data->getProperties(TRUE);
if (isset($data_properties[$main_property_name])) {
return $this->extractFieldValues($data_properties[$main_property_name]);
}
return []; // line 221
}
Here are some examples and resources:
- An example from this module's test cases: https://git.drupalcode.org/project/search_api/-/tree/8.x-1.x/tests/modul...
- Tutorial about hooks and events: https://www.specbee.com/blogs/hooks-vs-events-in-drupal-making-informed-...
- Replacing a hook with an event: https://www.drupal.org/docs/8/modules/search-api-solr/search-api-solr-ho... β
rudolfbyker β made their first commit to this issueβs fork.
rudolfbyker β made their first commit to this issueβs fork.
rudolfbyker β made their first commit to this issueβs fork.
rudolfbyker β made their first commit to this issueβs fork.
rudolfbyker β created an issue.
I ended up doing something completely different, and standalone: https://www.drupal.org/project/oai_pmh_harvester β
Due to lack of documentation, I ended up writing https://www.drupal.org/project/oai_pmh_harvester β without depending on this module.
@fishfree I'm willing to work on this if you can find a sponsor for it. I think it will take 3 work days. Alternatively, you may submit a merge request, and I'll review it.
I think this patch needs to be re-rolled for version 3.5.
v3 clearly states that it is supposed to be compatible with Drupal 10: https://www.drupal.org/project/geolocation/releases/8.x-3.12 β
v4 is still in alpha, so I can't use that on some projects.
Thanks. I merged your patch, with one small fix to the punctuation.
Thanks!
If you think this module needs a help hook, feel free to write one and submit a merge request. Otherwise, please use the "Closed" status instead of "Postponed".
Thanks for your time! I hope this module is helpful.
Done!
I'm also running into this issue. Thanks for the patches.
I think two more things are needed here:
- Unit tests, so that this does not regress again.
- A way to clear the secret in the UI when editing the consumer. Currently, if you leave the field empty, it just means "don't update".
rudolfbyker β created an issue.
rudolfbyker β created an issue.
This is not possible yet. It will take considerable development and design to get this working. I don't have the time, sorry.
Is this working for you @tikaszvince ?
Thanks for the reproduction. That saved me a lot of time.
I think since the used "caseyamcl/phpoaipmh" packages requires guzzlehttp/guzzle you do not need to lock this requirement at all.
Almost correct, but not quite. If oai_pmh_harvester
used guzzle directly, we would need to keep it, even if it's provided by caseyamcl/phpoaipmh
. But it looks like we are not using guzzle directly, so your patch is good.
Hi, please provide steps to reproduce the problem, rather than simply pasting an error message. I need more context to be able to help you with this.
Ah, I see it has nothing to do with the PHP version. I will release version 2.0.2 with your fix.
Thanks for the patch. Which PHP version are / were you using?