I started to migrate a Ruby on Rails/Backbone.js app to production today and got a large number of new problems. One was the following CSS line:
#crops input[type=text, class=crop_selector] {
width:140px;
}
This was OK in development, but in production it isn't. On top of that, many of my images no longer appeared in the browser and I'm seeing no background colors. Could someone explain to me
1) what is wrong with the CSS?
2) what is so different about production? (perhaps point me to docs where I could read up on the differences)
EDIT on 1/24/13: someone helped me with the CSS error, so that is no longer a question. I still need to understand exactly what is different about production, when the switch is made. It is not just environment variables.
Related
as shown below:
I don't understand why, the syntax and format is correct, it's extremely confusing.
I review my code carefully but can't figure out
this seems to be a bug with VS Code. This could be because VS Code is not updated, or an extension that is not supported anymore.
first, try ctrl + shift + p and running >Developer: Reload Window this should reload your current environment and the error should be fixed.
If that doesn't work, try a different extension. I currently use Vetur, and Prettier.
And don't forget to make sure your VS Code is up to date. go to the bottom left and click the settings cog, then check for update or updates.
My answer is, "Start from scratch, and record your steps." I'm happy to share my notes on what is presently working: https://github.com/TheAutomaTom/VsCodeSettings-Vue3
My personal machine had been in that spot for some weeks, so I took a step back and dump out your cornucopia of extensions and their dependencies.
Only run pertinent language services. This is a tall order given how much a Vue + Typescript + Tailwind on Vite app covers. I am suspicious of generalized HTML/CSS/JS packs though, because they may not be built to parse Vue SFCs. Every new release of a services intended for other frameworks, like Angular or React, are still possible culprits (and moving targets).
I gave up getting Prettier and ESLint on stable ground. For a non-workplace thing, I feel okay about that. You may be having issues with a global package, if you've been experimenting. I've tossed out a couple branches following different tutorials. I intend to revisit this one since it has some example projects: rvest.vs-code-prettier-eslint
I've noticed the Volar team seems to let oddities squeak out a little more frequently than I remember in Vetur.... but we love them just the way they are. Sometimes I downgrade just to check if I've gone crazy, yet.
Within the last few updates to Aurelia I've noticed increasingly bad load times. I'm not talking about bundling load times, but dev load times on localhost. The Aurelia motto was that it would get out of your way and only be there if you needed it. With a ~10 second load time for my page, that's not getting out of my way. Simply making style changes to my site is a tediously slow process now.
I checked the skeleton navigation sample app to make sure this wasn't related specifically to my "custom" version and I got the same load times. 107 requests and an average of 9.5 seconds to load the page. How is this acceptable for even a dev environment?
Is there a way to bundle just the Aurelia code so it's "out of my way"? Again, this has only happened within the last few releases of Aurelia. I don't know which one specifically because it felt like such a gradual increase and only now am I noticing these long load times.
Edit
I did take note that these long load times started shortly after I updated Chrome and FireFox. I'm not sure if it's actually related, but I noticed big slowdowns after the update, specifically in Chrome (I use Chrome for the majority of my dev work).
For reference, here's the log. It seems there are two culprits taking up the majority of the time.
Everything evens out after that.
The results:
I am at my wits end. I've written a xul app and it runs fine if I open the .xul in firefox directly. But xulrunner doesn't cooperate at all. I can run my xul fine by using the -chrome flag for firefox and giving it an absolute path, but -app doesn't work on firefox either. I have all the files required (application.ini, chrome.manifest both in root and /chrome/ and tried with either missing as well) and their format has been checked and re-checked.
I was prepared to paste all my files here and link the code, but I've tried everything, including a boilerplate project from http://www.mozdev.org/projects/wizard/ (from the application wizard) which reacts the same way as my own project.
xulrunner returns no error message, nothing - it just stays there in the task manager, no cpu load, not loading anything to memory, inert.
I've tried other projects (https://github.com/matthewkastor/XULRunner-Examples - the periodic table works at least) but I can't get a single solid lead on why some projects run properly, while others just have xulrunner waiting and doing nothing. It also seems this is a rare problem because most people can at least run the boilerplate fine, even if their own projects don't initially run.
I don't think it's necessary to post my code at the moment since it behaves the same way as the boilerplate. Can anyone tell me possible reasons why xulrunner won't work with the boilerplate but will with the example project?
I'm running v25 on win xp sp2 and I have been searching and reading all day, so I'm pretty sure I've read everything related - thanks in advance; I hope 5 days of work won't be wasted :(
edit:
SOLUTION: I messed up and didn't notice that prefs.js was missing or empty. Even if you have no preferences in your app, prefs.js is needed to set up the environment and tell firefox or xulrunner where the xul file to start from is. Without this pointer it has no idea. Yes, the MDN article does state this and what it contains is accurate, this was a big mistake on my part, as it seems I subconsciously (or not?) ignored the prefs.js file because I had no need for preferences in my app.
tl;dr if your apps don't work but the example files do, check your prefs.js even if you don't use preferences.
Posting this to close this question, since it doesn't need further answering.
The fault was with me - the app required a valid prefs.js file which I hadn't created because I was under the impression it wasn't required unless you intended to have preferences in your app. The MDN (at least at the time) specified this.
I did not have this problem 2 days ago, now it happens without me doing anything. I have my site.less file which includes bootstrap.less, and it takes 25s to load all the less files which is very annoying when developing
less: parsed http://localhost/css/dev/public.less successfully.
less: saving http://localhost/css/dev/public.less to cache.
less: css for http://localhost/css/dev/public.less generated in 26446ms
less: css generated in 26453ms
I was using Chrome and Firefox and both browsers have the same problem. I am not sure what is it.
So, to be clear, it looks like everything is local. but what isn't clear is what you're doing with the LESS and CSS. It's taking a while for the CSS to compile into LESS, but what are you using to compile? less.js?
So I'm assuming you're directly editing the LESS files and your goal is to have the LESS compile into CSS on the fly, and then you will use the CSS for production... right?
If my assumptions above were correct, don't use less.js during development the way you would if you were compiling LESS to CSS in the browser.
Use one of the solutions in this post: https://webmasters.stackexchange.com/questions/25289/is-there-a-way-to-compile-less-files-to-css-so-that-every-browser-doesnt-have
I figure out that I have changed the database (Redis) from localhost to a remote database. When I change it back to localhost, everything works as it is supposed to be. I am not sure how database connection can have anything to deal with less files.
I'm very keen to update a number of our servers to PHP 5.3. This would be in readiness for Zend Framework 2 and also for the apparent performance updates. Unfortunately, i have large amounts of legacy code on these servers which in time will be fixed, but cannot all be fixed before the migration. I'm considering updating but disabling the deprecated function error on all but a few development sites where i can begin to work through updating old code.
error_reporting(E_ALL ^ E_DEPRECATED);
Is there any fundamental reason why this would be a bad idea?
Well, you could forget that you set the flag and wonder why your application breaks in a next PHP update. It can be very frustrating to debug an application without proper error reporting. That's one reason I can think of.
However, if you do it, document it somewhere. It can save you a couple of hours before you remember setting the flag at all.
If you haven't already you should read the migration guide with particular focus on Backward Incompatible Changes and Removed Extensions.
You have bigger issues than deprecation. Ignoring E_DEPRECATED will not suffice. Because of the incompatible changes there will also be other type of errors or, maybe, even worse, unexpected behaviors.
Here's a simple example:
<?php
function goto($line){
echo $line;
}
goto(7);
?>
This code will work fine and output 7 in PHP 5.2.x but will give you a parse error in PHP 5.3.x.
What you need to do is take each item in that guide and check your code and update where needed. To make this faster you could ignore the deprecated functionality in a first phase and just disable error reporting for E_DEPRECATED, but you can't assume that you will only get some harmless warnings when porting to another major PHP branch.
Also don't forget about your hack and fix the deprecated issues as soon as possible.
Regards,
Alin
Note: I tried to answer the question from a practical point of view, so please don't tell me that ignoring warnings is bad. I know that, but I also know that time is not an infinite resource.
I presume you have some kind of test server? If not, you really should set one up and test your code in PHP 5.3. If your code is thoroughly Unit Tested, testing it will take seconds, and fixing it will be fairly quick too, as the unit tests will tell you exactly where to look. If not, then consider making Unit Testing it all a priority before the next release, and in the meantime go through it all, first with E_DEPRECATED warnings disabled and fix anything which comes up, then with it re-enabled once you have time. You could also run a global find-and-replace for easier to fix errors.