I have an application that use laravel 8.75. I made custom views for 404 and 500 errors.
When I deployed my website, custom error view shows but seems that styles doesn't work on it.
So I realized that I made a mistake on the stylesheet call. I made correction and the css file is correctly call. But style still doesn't work on my error view.
So I clear the framework cache data and views and I clear the serviceworker cache.
Now my custom error does not appear at all, only standard navigator error (and not laravel standard error).
I want to precise that it works on local server.
I think it's due to cache but I don't understand the problem.
Has anyone had this problem before?
Do you have any idea of the cause of the problem?
Related
I'm currently working on Vue 2 app hosted on S3 and served through CloudFront. With my routing mode set to history, things weren't working properly upon initial deployment.
However, I was able to fix that by adding redirection rules to my CF distribution:
Things were working fine, but now for whatever reason, that stopped working, I'm getting a HTTP 403 on all pages/paths I try to visit. The only difference between then and now is that my app has more pages/paths. Nothing else has changed. Here's a sample response header:
It's few and far in between, but there have been a couple of instances when I've gotten HTTP 404. The puzzling part is that the pages/paths load up fully, but not all the stylings get applied. For example, a fully bolded 12-sentence paragraph might display only 4 sentences as bolded.
Initially, I thought there was an issue with CF, but I have tried everything I could think of and talked with AWS Support, but nothing has come of that so far.
My next guess is that this may be a routing issue, but I'm not sure what to try. The routing issues I've faced in the past revolve around pages/paths not loading up at all so this is new territory for me, and I have not the slightest idea where to begin my troubleshooting efforts.
Has anyone faced a similar issue in the past? If so, how did you fix it?
So it turns out, the issue originated from the way I was setting up Tailwind.
Instead of setting things up myself, I just pointed to Tailwind's CDN and the issue was resolved.
The version of Tailwind I was using was a bit old, so it could have been a dependency issue as well.
So, I'm building an application with Vuejs and after we finish her we decided to finally build for production. Everything worked just fine while building and etc, but when the application was really being hosted, we noticed some issues that we do not saw while on localhost (development and production).
I'm saying this after a lot of tests and researches about it because first, I thought that the problem was after building to production but we tested another way to host and it's not apache that is causing this issue and I really think that is not the code either. Anyway the problem is when we first access the application our login page is the first that you can see and it works just fine at the first access but if the user refreshes the page for any reason the page loses all her CSS because the route /auth/login goes to /auth/login/ and after some tests I can confirm. That bar that is added at the end of the route makes the page lose CSS.
This problem we solved by adding an exception on our .htaccess (we know that this is not that best practice but anyway) after this solved we saw another problem: when we click on a link for example /auth/login?token=12334567890 the token param simply disappear and the user is automatically redirected to /auth/login. So we think that maybe these two problems are related because when we first access and log in everything inside the application works as it should, these two problems are only occurring on our login component. My question is what is causing this problem only on this page? It's a vue-router that is causing?
I am having what I think is a weird issue.
After re-installing (because it did the same thing before) VS2012 I am unable to debug websites on my local machine - running Windows 7 Pro SP1
When I create a new application of the type Internet Application I can debug fine - I mean it brings up the website in the browser.
When I select the Basic template I get a 404 error (See Image 2)
Even after I create a Model, a Controller and a View.
Despite it being an empty website - when the view is created it has the <h2>Index</h2> so it show that at a minimum.
Am I making a bonehead simple error that gives me the error? The setup in my projects are exactly the same, so I do not really understand what gives me this error.
So after finding this article and following the instructions it worked.
I needed to create a HomeController with an index page.
I had done everything except naming the Controller - HomeController
I am part of the developer team for a quite a large online system using ASP.NET(4).
Asp.net Ajax completely breaks down for Webkit browsers and we are getting full page postbacks when we should be getting partial only for the UpdatePanels.
I am starting to believe it has something to do with my Application Configuration, mainly for the following reasons.
If I move the ajax enabled controls to a new project they will work as expected for all browsers, including Webkit.
I created a static .aspx file with nothing but an UpdatePanel,ScriptManager and a button making a literal visible on click.
I get no Javascript errors from any browser, and i see an http request for the asp.net-ajax (ScriptResource.axd) in both Firebug and Chrome Developer tools
I tried ye'old safari fix from this highly referenced thread
Edit: After a bit more testing and http sniffing i noticed a major difference between the test application and the actual application. The test application generates 2 additional .axd files which are not generated from the actual application. These WebResource.axd, seem to contain data related to the async postback. However this is only the case for Webkit browsers. The WebResource.axd files are generated for Firefox as i can see them in firebug
What i am asking from the community, is any ideas or suggestions as to what could be the cause of this problem and if i am correct to assume that the problem is probably on the server side
Thanks for any help
The problem was due to a deprecated config file that's used to limit the content that bots/spiders/crawlers receive, which was loading by mistake thanks to our lovely inhouse CMS
In short if u get behavior similar to my case, check your or configs
I was having a similar issue however my problem was with all browsers and not just webkit. I ended up going through and tearing up the web.config file and found out that a line: <xhtmlConformance mode="Legacy"> was preventing webresource.axd from working properly. The fix was to simply remove that line from my web.config file.
For a little more information on xhtmlConformance, visit http://technet.microsoft.com/en-us/librarY/ms228268(v=vs.85).aspx.
If you scroll all the way to the bottom you'll notice it explicitly states that it causes issues with webresource.axd and scriptresource.axd.
What is the best way to load the WordPress API from a Zend Powered page, so I can call it on .php pages outside of the WordPress installation?
I currently have this code on a .php page outside of WordPress:
define('WP_USE_THEMES', false);
require('/wordpress/wp-blog-header.php');
I try and run the page and get this error:
Fatal error: Call to undefined method stdClass::set_prefix() in
/wordpress/wp-settings.php on line 268
I have been trying to troubleshoot the problem using some of the suggestions on this page. But to no avail.
I'm getting exactly the same issue as you are above. I don't think the problem is specifically that you are trying to load from outside WordPress. It is because the above code is being called from inside a function, outside of WordPress.
I am not using the Zend framework, but when I try to access WordPress using the code above, it's no problem. When I try to load it from the context of my CMS (within a function) I get the same error as above.
Sorry I can't help, but I thought my observation might help someone find a solution.