My situation: we have a Shopify store, we also have a search engine implemented and hosted on AWS. We need to use that search engine instead of the default /search on our Shopify store.
Ideally, when users try to search something, their query (and potentially some other stuff like attribute selectors/checkboxes on the front end) will be passed to our search engine. Then after the result is back, they will be rendered at the front end.
My Question: how should I do this?
Option 1: modify the theme code, inject some javascript to call the search engine
(Possible, but messy)
Option 2: write an app, wrap my search engine within the app, and somehow plug it in the store
(I don't know how to do this)
Option 3: similar to Option 1, but write an app, use the app to inject some code to the theme, and somehow handle the work.
(I don't know how to do this either)
I found a similar post here: Write custom search app in shopify
but the answers below were more about filtering/modifying search result returned by the default shopify engine, I want to instead use my own search engine.
Essentially my problem was to redirect user search queries to my service, and eventually render search results on user front end. To do that i have found the best way was to write a Shopify App.
Here is my solution:
1, build an App, host it somewhere maybe ngrok, install it on the store: (https://help.shopify.com/api/tutorials)
2, use proxy to redirect the /apps/mysearch to where the App is hosted: (https://help.shopify.com/api/tutorials/application-proxies)
3, in the store, show users a form where action="/apps/mysearch".
4, in the app process the form data, do whatever we want. Eventually return a view back to the store containing the search result, be sure to specify "Content-Type: application/liquid" inside of the app so that the returned view works with shopify theme.
Note that all of the search happens outside of Shopify.
I think you should do this with Option 1. Though its messy but it work and save your time. You can also hire an shopify developer ( like me ) for help.
Related
I'm working on a web application where a large set of data can be filtered using JavaScript. When a user selects filters, I want to update the URL of the page to reflect the selected filters so that the user can share that URL with someone else, and that person can load the page and my app will apply the same filters. I don't have a need for the back buttons in the browser to cycle thru the previous filters that were selected.
I think I have two approaches here:
I can create a representation of the filters and add them to the fragment of the current page via window.location.hash. I can parse them on page load to see if there are any already set.
I can create a representation of the filters as query string params, and manipulate the URL using the history API. I would use the replaceState method.
Is there a reason to chose one over the other? Again, I want to emphasize that I'm not concerned with any routing or browser history manipulation. I just want to provide a way for someone to put certain params in the URL that my JS code will parse and apply as the filters.
Using the Vue router and may be also vuex for state management should help you save some time. There is also a little helper library for url encoding / decoding --> qs.
To your question "history vs hash": that depends on your application, the system which hosts the application (e.g. part of a content management system with its own url handling) and the meaning of the params.
History mode generates better looking paths and features some more control, as long as you stay in your application. But: as your path segments have no identifiers, the sort order matters.
Scenario: You have an application which can have three params:
/value1/value2/value3 means something else as /value1/value3/value2
With a query string you don't need to take care about sort order, as every value has its key:
key1=value1&key2=value2&key3=value3 is the same as key1=value1&key3=value3&key2=value2
It seems like there's 2 options available, and I wanted to make sure they were reliable ways to get the current Shopify store information:
Option #1:
Hijacking window.Shopify variable. This provides shop variable needed for any api calls (api calls not through Shopify but my server).
Option #2:
Shopify passes shop to the injected script element like so:
<script type="text/javascript" async src="https://myexample.com/js/welcomeBar.js?shop=foobarshopify.myshopify.com"></script>
This option is weird because I do not see it being done for every scripttag that I tested from Shopify store, only mine.
Is either option more reliable than the other (or do either cause issues)? Also, please let me know if there is a more reliable way, or if there's more ways missing.
Edit: This is under the assumption that the Shopify app is installed, and I need the shop for the current store it is installed on.
We are using a third part web app which does not allow or have an API yet, this third party app is basically a membership registration website and each member belongs to a specific category.
I need to use these category in our internal system and so far I have been manually adding the category in a drop down menu of a form as soon as a new category in created in third party app.
Since there is no access to an api so I am wondering if it is possible to crawl the third party app where the dropdown menu is and copy the entire dropdown menu over to our internal site.
I wish i can show you the efforts I have made so far but I am stuck on how to even begin this. I did however search online but all I could find is how to copy a dropdown on a same page.
Any push to the right direction will really be helpfull, the technologies I am working with is PHP and JS
I don't think CORS is going to help you here, as it's function is to provide a legal/safe way of sharing web resources across different domains (i.e. images/css files/web fonts), not data.
If there is no API for the data you need, you are almost certainly limited to scraping the data out of the web page.
You can do this by first issuing a request for the page to obtain the html, then searching/parsing the html to find the drop-down menu, then finally parsing the menu items to obtain a list that you can use for your own drop-down.
So, some pointers:
Obtain page html - See PHP: how can I load the content of a web page into a variable?
Parse html - See PHP Parse HTML code
Of course how easy this ends up being depends on many factors, e.g.
Can you just request the page containing the drop-down, or does the
web app need authentication? You may need to refine the curl request
as appropriate.
Can you easily identify the html drop-down, e.g.
using a unique id tag. If so, you could use
DOMDocument::getElementById, otherwise you may need more complex
logic to parse the page html and find the menu.
Either way, it should be possible to achieve - just remember that the third-party app is not under your control, and as such may be subject to changes that break your program.
LATEST UPDATE:
Added in retrieval of value, and we hide parse warnings using internal_errors.
Here's a simple PHP script that will print out the text and value of each of the drop-down options:
<?php
libxml_use_internal_errors(true);
$html = file_get_contents('http://example.com/');
$domdoc = new DomDocument;
$domdoc->loadHTML($html);
libxml_clear_errors();
$menu = $domdoc->getElementById('tid');
$options = $menu->childNodes;
foreach ($options as $option) {
echo($option->nodeValue)." - ".$option->getAttribute('value')."<br>";
}
?>
Im new to Meteor/iron-router and am following the Microscope project/ file structure.
My question is :
I dont want the usual drop down login box with {{> loginButtons}}. How do I set up a stand alone authentication page as the primary loaded page if user is not registered or logged in? It will have the usual email/pw and social logins.
This is the basic router code for easy reference.
Do I just tweak the requireLogin part?
I also tried to use accounts-entry package but its fairly tough to figure how to use it.
You could also use an existing package from Atmosphere that provides a full-page login, such as UserAccounts.
One way to do this is to just roll your own implementation with the Meteor.loginWithPassword and Meteor.loginWith<ExternalService> functions. You can call these functions when the relevant buttons on your login page are clicked.
I need to create a feed based on changed documents. I figured the _changes api would be perfect in this case. Ie simply store the last sequence id client side, so we can use it to limit the results in the next call to _changes.
Currently, the application performs the following:
calls _changes with since/filter parameters
calls a show function for each id in the _changes feed
renders all changes into the customer feed
What I would like, is to be able to call a list function on the entire _changes result in a single request. This would remove the need to explicitly parse the _changes result on the client, and move that functionality to the server.
The question: is this even remotely possible?
I have been trying to implement a view, doing "almost" the same thing as _changes, but without any real luck.
This is not possible at the time, and the _changes API is different enough from regular views that it's not entirely straightforward to implement.
There is a ticket open in the CouchDB issue tracker, but it hasn't been updated in quite a while.