I've been digging into this and I've found some very interesting things:
I am using Lando for local dev with the Pantheon recipe and I've tried a couple of things.
- Creating a new Solr server with custom config automatically added
- "Posting" custom config to default Pantheon server
Here are some strange findings:
- When developing locally, using a custom server and index, I'm able to get synonyms to work.
- When developing locally, using the Pantheon server and index, synonyms work with custom config.
- When testing on Pantheon with default config, synonyms do not work, nor should they.
- When testing on Pantheon with custom "posted" config, synonyms do not work, but they shouldn't.
Here's where it gets strange:
When testing on local, both custom and Pantheon servers, the testing at
admin/config/search/search-api/server/pantheon_solr8/solr-admin/field-analysis
revealed the following:
However, testing the same way on Pantheon with a Pantheon server revealed this:
The most interesting part is that the following happens, which I believe is related:
I checked all of my schema files and the tokenizer should definitely be the StandardTokenizer
<fieldType name="text_en" class="solr.TextField" positionIncrementGap="100" storeOffsetsWithPositions="true">
<analyzer type="index">
<charFilter class="solr.MappingCharFilterFactory" mapping="accents_en.txt"/>
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords_en.txt"/>
<filter class="solr.WordDelimiterGraphFilterFactory" catenateNumbers="1" generateNumberParts="1" protected="protwords_en.txt" splitOnCaseChange="0" generateWordParts="1" preserveOriginal="1" catenateAll="0" catenateWords="1"/>
<filter class="solr.LengthFilterFactory" min="2" max="100"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" protected="protwords_en.txt" language="English"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
</analyzer>
<analyzer type="query">
<charFilter class="solr.MappingCharFilterFactory" mapping="accents_en.txt"/>
<tokenizer class="solr.StandardTokenizerFactory"/>
<filter class="solr.SynonymGraphFilterFactory" ignoreCase="true" synonyms="synonyms_en.txt" expand="true"/>
<filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords_en.txt"/>
<filter class="solr.WordDelimiterGraphFilterFactory" catenateNumbers="0" generateNumberParts="1" protected="protwords_en.txt" splitOnCaseChange="0" generateWordParts="1" preserveOriginal="1" catenateAll="0" catenateWords="0"/>
<filter class="solr.LengthFilterFactory" min="2" max="100"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.SnowballPorterFilterFactory" protected="protwords_en.txt" language="English"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
</analyzer>
</fieldType>
The part of note there is:
solr.StandardTokenizerFactory"/>
What this is telling me, in addition to the issues mentioned on https://www.drupal.org/project/search_api_pantheon/issues/3424724#commen... 🐛 Search API Schema reverts back to 4.2 after deploys or randomly Active is that there is another config file hiding somewhere that we do not have access to edit that is overriding some of the customizations. This is also evidenced by seeing Schema 4.3.3 on local and 4.2.0 on Pantheon.
Without knowing if this is indeed the case, it's difficult to determine what the next steps to correct this are.
ChrisDarke → credited dorficus → .
markie → credited dorficus → .
wylbur → credited dorficus → .
markie → credited dorficus → .
volkswagenchick → credited dorficus → .
volkswagenchick → credited dorficus → .
volkswagenchick → credited dorficus → .
There is no example line under the Component Data Validation section where it says:
- Assertions must be enabled. If assertions are disabled within your local environment, you can add the following to your
settings.phpto enable them:
The code to be added to settings.php should be placed after the colon.
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
volkswagenchick → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
kthull → credited dorficus → .
volkswagenchick → credited dorficus → .
volkswagenchick → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
dorficus → created an issue.
volkswagenchick → credited dorficus → .
volkswagenchick → credited dorficus → .
dorficus → created an issue.
dorficus → made their first commit to this issue’s fork.
This issue is already being worked on in https://www.drupal.org/project/crumbs/issues/3352603 🐛 PHP 8.1 deprecated notices Needs review . Marking as closed/duplicate to prevent confusion.
dorficus → created an issue.
dorficus → created an issue.
Minutes published: https://docs.google.com/document/d/1v5T0b5b6GxOr8fVsb4pLacoBf2PTou3Sfrwo...
Minutes published: https://docs.google.com/document/d/1t7w9vbbl6twyNh5StkiVVUKtjsXlirKeuiVJ...
volkswagenchick → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
markie → credited dorficus → .
I've been following this and have to respectfully disagree with #19. I don't believe that a corporation or private entity should be able to dictate what namespaces are and aren't available on Drupal.org.
By allowing private entities to sit on empty projects due to naming internal projects generically prevents open source contributors from creating projects that either have similar functionality or the same name with different functionality. For example, if I have a client and I build a module for migrating content from a geographical database into a content type and I want to name it "Geography," I shouldn't expect that I can create an empty project on d.o to make sure that my poorly named custom module will not have any namespace collision with another contributed module. For what it's worth, I try to name any custom module for a client with an identifier to prevent this exact scenario.
And in the spirit of open source, if it's something that can be contributed, it should be contributed.
In some ways an empty project is more useful than no project, if the Module repository doesn't let administrators see all the modules that exist it could always lead to the community adopting another source to obtain modules.
I think that one of the big draws to Drupal is that contrib modules are free and found in one place, unlike some of the other CMS offerings where plugins or extensions can be pricey and code can be closed source. I highly doubt that telling users that they cannot sit on an empty repo for an extended period of time is going to cause a mass exodus of people using d.o for finding modules.