Dear Userfrosting experts...
I have just installed Userfrosting on LAMP Stack. Ubutnu 16.04
The URL contains query strings : http://example.com/dashboard#&sort[table-activities][occurred_at]=desc&page[table-activities]=1&size[table-activities]=10
How can I get rid of these query strinngs ?
They look ugly !
This is related to the TableSorter sort2hash plugin. The query strings are used to reapply the same sort and filter params if the page is accessed again.
It is enabled in uf-table. See USerFrosting document about Tables here : https://learn.userfrosting.com/4.2/client-side-code/components/tables
Related
I ran into an issue where elasticsearch is not able to find indexed categories that contain an "-" in their slug. The category given is "wc-sitze". When I query for "wc", the category is found, and when I query for "sitze", it is also found, however when I query for the whole thing "wc-sitze", it is not found. I have checked with several other categories, and it seems that always the "-" is messing it up.
Any ideas?
Thanks in advance
Looks like you are using the text field with default analyzer standard which removes the special char like -. you need to change the analyzer to make it work.
I am using ELK and I need to filter all the documents with an unmatched COUNTRY (from geoip)
Theses properties looks like:
'IPCOUNTRY': '??'
But I just can't filter on this special value...
I tried
IPCOUNTRY:?? => ? is evaluated > returns all records > normal case-
IPCOUNTRY:\?\? => Doesn't return any document... but lucene documentation says it should be the good way of achieving this...
IPCOUNTRY:"??" => doesnt work
IPCOUNTRY:'??' => doesnt work
EDIT:
This case doesn't work too
- IPCOUNTRY:/[^A-Z]{2}/
Simple but boring issue ^^
Thanx!
You could try :
!IPCOUNTRY:"?"
-IPCOUNTRY:"?"
NOT IPCOUNTRY:"?"
If you have an unanalyzed IPCOUNTRY field, you can do something like :
!IPCOUNTRY.raw:"??"
This is an elasticsearch mapping issue. Punctuation is dropped. You'll need to set your field to an analyzer that would keep ?. Maybe keyword? or not_analyzed?
extract from https://github.com/elastic/kibana/issues/6561#issuecomment-197951710
If all of your fields have documents same as 'IPCOUNTRY': '??', then you can directly filter this field which will exclude the field from matches.
To directly add a filter you can do it in the following 2 ways:-
In Discover page open the text and find the field. Click on + magnifier to add the field as a filter.
In Discover page, on the left side where fields are listed. Click on field name & select the value portaying as ?? to add it as a filter.
I have just updated a website, the update adds new fields to elasticsearch.
In my dev environment, it all works fine. but on the live site, the new fields are not being found.
Eg. I have added a new field with the value : 1
However, when adding a filtered query of
{"field":1}
It does not find any matching results.
When I look in the documents, I can see docs with the field set to 1
Would the reason for this be that the new field was added after the mappings was set? I am not all that familiar with elasticsearch, So I am not really sure where to start looking to fix it.
Any help would be appreciated.
Update:
querying from URL shows nothing either
_search/?pretty=true&size=50&q=field1:*
however there is another field that was added at the same time which I can search on.
I can see field1 in the result set but it just wont allow me to search on it.
Only difference i see in the mapping is that the one that is working is set to type:long whereas the one not working is set as type:string
Is it a length issue on the ngram? what was your "min_gram" settings?
When you check on your index settings like this:
GET <host>/<index_name>/_settings
Does it work when you filter for a two digit field?
Are all the field values one digit?
It's OK to add a field after the mapping was set. ElasticSearch will guess the mapping for you. (in fact, it's one of their selling features --- no need to define the mapping, just throw the data at it)
There are a few things that can go wrong:
Verify that data is actually in the index. To do that, just navigate to the _search url with no parameters, you should see the field if it is indexed.
Look at your mapping. Could it be that the field is explicitly set not to be indexed?
Another possibility is that your query is wrong (but that is unlikely, since you're saying it works in the development environment)
I am trying to integrate SOLR with Magento on my development machine. We are upgrading Magento and I want to test if SOLR is working as well.
I am able to feed SOLR, the stats say that it has documents. In SOLR admin, when I put in : as query string, I do get the list of documents. But when I search for "maria mosters" for example, no results are returned.
I have tried SOLR 1.4.1 (which we run in production) and 3.4.0.
My schema.xml: http://pastebin.com/3a2J99re
Thank you for your replies. I finally got my answer, for my case.
I found out by checking the query string that was being logged by SOLR. This was for example:
127.0.0.1 - - [28/09/2011:09:05:34 +0000] "GET /solr/select?sort=score+desc&fl=id&spellcheck=true&spellcheck.count=2&qt=magento_nl&spellcheck.collate=true&spellcheck.dictionary=magento_spell_nl&spellcheck.extendedResults=true&fq=visibility%3A4+AND+store_id%3A1&version=1.2&wt=json&json.nl=map&q=%28maria+mosterd%29&start=0&rows=1 HTTP/1.0" 400 1405
When I requested this query the first time, it said that the field visibility was unknown. Apparently this field was added by Magento in the upgraded release. I added the field to the config, and ran the query again. Now it said that the dictionairy magento_spell_nl did not exist.
What happened?
The new Magento has a option called "Enable Search Suggestions". In my previous Magento version, this option didn't exist, so this spellchecker thing was not passed to the query string.
When I turned this setting of, I was able to use my exact copy of the production server.
*:*
would work as its matching all on all fields.
Search for maria mosters is going to search in the default field, if you are using the standard request handler.
The default search field set in the schema is fulltext and I don't see any copyfields into it.
So are you sure the field is populated.
If you are using any custom request handler via the qt param, are the proper fields included in it ?
sharing you solrconfig and full query might help for others to help you further.
Looks like your issue is that in your schema, you have the fulltext field defined as the default search field, but you are not populating that field. I would recommend either setting the default field to another field that you are populating or when you execute your query, specify the field that you want to search against... Example text_en:"maria monsters"
Please also see the SolrQuerySyntax page on the Solr Wiki for more details.
We have built a website http://www.goshopping.pk/ (sorry had to post the link as its important for this question).
The quick search is not working as it should. For example, search "Nokia" and you will get all sorts of results. Search "Dell" and you get the same results. However, searching exact matches like "nokia 6600" or "Intel Core 2 DUO" or "Dell Inspiron" works perfectly fine.
We have rebuilt the search index, emptied the cache etc but it has no effect. What are we missing?
Help appreciated. Thanks!
One quick tip I normally advise people is to remove the description from quick search results in Catalog > Manage Attributes > Attributes
Obviously the description contains all sorts of words and can dilute search results. See if that improves anything.
Also in Configuration > Catalog I normally change the Search Type to Fulltext for more accurate results.
Based on the suggestion from Adam, we were able to resolve this. Here is what we did if anyone needs future reference:
We had about 400 attributes defined and a lot of them were set to search in quick search by our client. What we did is we manually ran a query via phpmyadmin for table "eav_attribute" and updated ALL records to have is_searchable=0
We then manually edited the title and description record in eav_attribute table to is_searchable=1
Rebuilt the search index via Mage Admin and all was good.
Best,
K