I am about to start a new project that requires a responsive design solution and I'd also like to take advantage of LESS.js for the styling.
I downloaded the Responsive template from Initializr and set it up as a new site on my localhost. I have begun making minor tweaks to the index.html file to begin styling the page up as it would be required for my project. I began by adjusting the width of the .wrapper class and was frustrated when my changes did not appear to be making any difference when viewing in the browser.
However upon changing the name of the folder containing the files and amending the URL, my changes appear, so there is obviously some sort of caching issue when using LESS on Localhost.
Does anyone know of a solution to this?
What worked for me was disabling, or deleting, cookies of the domain on which you're developing.
Related
Firstly, wow, Bigcommerce's own forums are dead as heck, huh?
Anyway, I've been working on my theme locally within stencil and for the most part it's been going fine. I did add a grip of images to the /assets/img directory that are displayed by category.js under certain conditions, which worked great when I'm serving from localhost but when I push the theme to Bigcommerce from the commandline (using 'stencil push') these images (and a couple custom icons, etc) are broken. I read the docs that warned me to make sure any added directories have the proper permissions but 1) this is an existing directory and 2) i'm getting a 404 anyway so it's not like they can't be accessed, they're just not there at all. Clearly Push isn't bundling them up, which means I'm doing something wrong.
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?
The problem is that site view in cms differs from live site itself.
In cms edit mode I've deleted component from container inside page, saved, then published changes. Publish done successfully without any errors and site view in cms looks correctly, i.e. without that component that was removed. But this component still appears in live site.
I can easily fix this problem by removing this component in console. In cms console it can be seen that preview and working configuration differs.
But why this type of desynchronization happens? And what can I do to prevent this kind of problems?
This type of desynchronization happens rarely, but this problem may be very critical in production.
I am using Hippo CMS 10.1.0 Community Edition
If Your configuraton have been resynchronized, good way is to remove whole preview node. This node will be reconstructed from Your live node when You enter in CMS and turn on edit Mode.
The great thing about PHP is that if you have something like
clothes.com, clothes.com/men.php, clothes.com/women.php
Then if you only edit the men's page, only that particular "app" will be restarted.
But on rack/Sinatra I have to touch the restart.txt file to restart the ENTIRE website.
Is there a way around this problem, so that users browsing other parts of the site wont have any problems while another part of the site get edited?
(i'm using mod-passenger on Apache, not that it's important..)
This would be true in all cases anyway for editing (non-inline) views (not layouts).
Aside from that, if you're really worried about this then I'd suggest using versioned folders to hold the application code. When you do a deployment, change the proxy to point at the newer version. Those who had already made requests will remain on an instance of Apache and the application that is already running, as long as their request remains alive, and seemlessly (unless you've broken something with the code) move to the new code on the next request.
It's also a convenient way to rollback to the/a previous version quickly and easily.
Check out the sinatra reloader from sinatra contrib
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.