I need some help with this issue in Vue Storefront that I have had some difficulty trying to solve:
After navigating to PDP(Product Detail Page) and refreshing the page, the page gets redirected to ‘page-not-found’ for many products. The products that get redirected to page-not-found are always the same and not all products get redirected to page-not-found. Traversing to the PDP using router-link works, even when the path is hardcoded, but navigating directly to it or refreshing the page while on a PDP doesn’t work. I also tried isolating the problem and found that even including just the Product.js mixin file from the core and removing all other code on PDP still causes the redirect.
I am unable to solve this bug despite trying for days. Even if you can’t see what is causing the issue, it would be helpful if anyone can at least show me how to debug this issue. I don’t know how to know what code is causing the redirect to 404.
Thanks
Is behavior present only for given type of products (like bundle) or do they have some common characteristic?
The problem may be lack of some data during SSR refresh. Then on a client side product can't be fetched. This can happen if we are missing some checks for some specific product types. Can you ping me on VS slack and give access to the code? Looks like the fault is on our side :)
Which version of VS are You using? If 1.9 - please make sure You've got the products properly imported with the product.url_path set. Then please do check if You don't have
Related
Shopify is quite restrictive about the ways that you can structure directories. For example all pages must have a url which looks like "my-store.com/pages/my-page".
Whilst there is no way around this in Shopify, I considered a workaround which would work like this.
Use javascript to check the URL queried when displaying the 404 page.
If URL queried = "my-url" connect to Wordpress Rest or graph QL API, query and then render desired content on the page.
For example, my-site.com/blog would return a 404 error, however javascript would run a function to get content when the URL ends in "/blog".
Although this would work from a technical point of view, I understand the server would still be giving a 404 error and this probably has wider implications? To what extent is this the case and is this an unviable solution?
A really interesting idea.
The biggest issue I see will be SEO, since the URLS will still points to the 404 page and you won't be able to show the proper content with liquid, all of the pages will pull the 404 content and show as 404 pages in the google search.
That said I don't see any other major issues that will prevent you to use this with JS. It depends really how many type of pages will require this logic and how the JS logic is written, but as an idea I really like the possibility of it.
I will probably not recommend it to a client that wants a SEO optimized site, but for a personal one it seems like an interesting idea.
I'm working on a semi-SPA VUE- page.
By semi-SPA i mean that just a few parts of the page are SPA:s (using routing).
The problem is that it generates a #-sign in the URL and the customer really doesn't like that.
To get rid of it you can use history mode but from what I can find it's only possible in a "pure" SPA-solution since it need to point back to a starting point if it doesn't find the specific route.
Is it possible to remove the #-sign from the URL in this scenario?
I need a little help here, i hope someone here can help me for a hint or clue.
First of all, I'm not programmer. I'm just web admin who can use cms and basic html.
I was using PrestaShop for my online shop. In the backend, I can't upload new product image anymore.
The error just blank without any sign for me. Here for the screenshot:
I appreciate it, if someone can help me, thanks, and sorry for my english.
#PanjiWiyono This errors don't really give us a quality information, but this is a start. In your JS code should be a ajax query that has an error when converting results to json (first error). You should check what's the exact error that this request is returning by inspecting in browser developer console.
If you detect that the second error is in fact, the response of this ajax query, well now we almost have the problem.
The second error should be related to data size. Check this: Error while sending QUERY packet
Anyway, you should check DbPDO.php class. You can use debug_backtrace function to display the complete stack, but definitly if error is related to a basic PHP class issue you will have not help knowing wich classes are in calling stack.
Good luck.
Simple solution
maybe a extra module is in a conflict with the prestashop core files. go to advanced parameters, performance and disable third party modules and try again.
other option is reupload admin folder with other name and
js folder check again
hope it will work for you
I have a page tab app that I am hosting. I have both http and https supported. While I receive a signed_request package as expected, after I decode it does not contain page information. That data is simply missing.
I verified that like schemes are being used (https) among facebook, my hosted site and even the 'go between'-- facebook's static page handler.
Also created a new application with page tab support but got the same results-- simply no page information in the signed_request.
Any other causes people can think of?
I add the app to the page tab using this link:
https://www.facebook.com/dialog/pagetab?app_id=176236832519816&next=https://www.intelligantt.com/Facebook/application.html
Here is the page tab I am using (Note: requires permissions):
https://www.facebook.com/pages/School-Auction-Test-2/154869721351873?id=154869721351873&sk=app_176236832519816
Here is the decoded signed_request I am receiving:
{"algorithm":"HMAC-SHA256","code":!REMOVED!,"issued_at":1369384264,"user_id":"1218470256"}
5/25 Update - I thought maybe the canvas app urls didn't match the page tab urls so I spent several hours going through scenarios where they both had a trailing slash or not. Where they both had a trailing ? or not, with query parameters or not.
I also tried changing the 'next' value when creating the page tab to the canvas app url and the page tab url.
No success on either count.
I did read where because I'm seeing the 'code' value in the signed_request it means Facebook either couldn't match my urls or that I'm capturing the second request. However, I given all the URL permutations I went through I believe the urls match. I also subscribed to the 'auth.authResponseChange' which should give me the very first authResponse that should contain the signed_request with page.id in it (but doesn't).
If I had any reputation, I'd add a bounty to this.
Thanks.
I've just spent ~5 hours on this exact same problem and posted a prior answer that was incorrect. Here's the deal:
As you pointed out, signed_request appears to be missing the page data if your tab is implemented in pure javascript as a static html page (with *.htm extension).
I repeated the exact same test, on the exact same page, but wrapped my html page (including js) within a Perl script (with *.cgi extension)... and voila, signed_request has the page info.
Although confusing (and should be better documented as a design choice by Facebook), this may make some sense because it would be impossible to validate the signed_request wholly within Javascript without placing your secretkey within the scope (and therefore revealing it to a potential hacker).
It would be much easier with the PHP SDK, but if you just want to use JavaScript, maybe this will help:
Facebook Registration - Reading the data/signed request with Javascript
Also, you may want to check out this: https://github.com/diulama/js-facebook-signed-request
simply you can't get the full params with the javascript signed_request, use the php sdk to get the full signed_request . and record the values you need into javascript variabls ...
with the php sdk after instanciation ... use the facebook object as following.
$signed_request = $facebook->getSignedRequest();
var_dump($signed_request) ;
this is just to debug but u'll see that the printed array will contain many values that u won't get with js sdk for security reasons.
hope that helped better anyone who would need it, cz it seems this issue takes at the min 3 hours for everyone who runs into.
We have one page that is causing the Session_start to run and I cannot figure out why. Anytime home.aspx is called, Session_start in global.asax is called and a new sessionid is created.
The sessionid looks to be created right when session_start is called. I think that is normal. I just don't know why it is called all from this page.
Home.aspx uses a different master page than the others. I have not found anything in it that is causing this. I checked the Response.Redirect calls, because others have indicated that could be the issue. I found none being called.
Using firebug, I found this:
Server Microsoft-IIS/5.1
.
.
Location /ent4_sql/(S(unfzfplfp5ltgxcrtpt2bk3f))/Home.aspx?_TSM_HiddenField_=ctl00_ctl04_HiddenField&_TSM_CombinedScripts_=%3b%3bAjaxControlToolkit%2c+Version%3d4.1.40412.0%2c+Culture%3dneutral%2c+PublicKeyToken%3d28f01b0e84b6d53e%3aen-US%3aacfc7575-cdee-46af-964f-5d85d9cdcf92%3ade1feab2%3af9cec9bc%3aa67c2700%3af2c8e708%3a8613aea7%3a3202a5a2%3aab09e3fe%3a87104b7c%3abe6fb298
The session in the url is different than the one that is displayed in the browser address bar. The browser seems to always keep the original.
From searching the web, this issue seems to be one that doesn't really have a direct answers. I am just out of things to look for. Any suggestions would be helpful.
Update***
Using fiddler, I found that the system is actually going to ent4_sql/Home.aspx?.....
Notice the session is not in the URL
That displays a page
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
and seems to redirect whatever is calling that to a url with session. I am trying to find more information on if others have seen the AjaxControlToolkit doing this.
The problem had to do with the Ajax Control Toolkit and cookieless sessions, as expected. Here is an issue reported in 2009 dealing with the same problem. Fix is now included on the issue
http://ajaxcontroltoolkit.codeplex.com/workitem/23443