Various things are different in 1.0.136, e.g. running code with ctrl-enter has all sorts of strange behavior in an RMarkdown document, running code that has a syntax error somehow leads to all of the code being run in a block above (below?) the wrong code, etc. Sorry for not posting an MWE, but at the moment I just want to know if anyone is aware of these new "features" and if so how they can be turned off or better yet how I can just downgrade to the previous version of RStudio (which I can't currently find on the website).
Yes they changed some default settings that were present in the old interface.
Change the setting in markdown next to the knit button, from:
Chunk Output Inline -> Chunk Output in Console
Pictured here.
You can probably mess with the the Global Setting->Rmarkdowns under Tools to get it back the way it was before, but this was the fastest way for me.
I'm seeing error messages about a file, min.map, being not found:
GET jQuery's jquery-1.10.2.min.map is triggering a 404 (Not Found)
Screenshot
Where is this coming from?
If Chrome DevTools is reporting a 404 for a .map file (maybe jquery-1.10.2.min.map, jquery.min.map or jquery-2.0.3.min.map, but can happen with anything) first thing to know is this is only requested when using the DevTools.
Your users will not be hitting this 404.
Now you can fix this or disable the sourcemap functionality.
Fix: get the files
Next, it's an easy fix. Head to http://jquery.com/download/ and click the Download the map file link for your version, and you'll want the uncompressed file downloaded as well.
Having the map file in place allows you do debug your minified jQuery via the original sources, which will save a lot of time and frustration if you don't like dealing with variable names like a and c.
More about sourcemaps here: An Introduction to JavaScript Source Maps
Dodge: disable sourcemaps
Instead of getting the files, you can alternatively disable JavaScript source maps completely for now, in your settings. This is a fine choice if you never plan on debugging JavaScript on this page.
Use the cog icon in the bottom right of the DevTools, to open settings, then:
You can remove the 404 by removing the line
//# sourceMappingURL=jquery-1.10.2.min.map
from the top part of your jQuery file.
The top part of the jQuery file will look like this.
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license
//# sourceMappingURL=jquery-1.10.2.min.map
*/
Just change that to
/*! jQuery v1.10.2 | (c) 2005, 2013 jQuery Foundation, Inc. | jquery.org/license */
Purpose of a source map
Basically it's a way to map a combined/minified file back to an unbuilt state. When you build for production, along with minifying and combining your JavaScript files, you generate a source map which holds information about your original files. When you query a certain line and column number in your generated JavaScript you can do a lookup in the source map which returns the original location. Developer tools (currently WebKit nightly builds, Google Chrome, or Firefox 23+) can parse the source map automatically and make it appear as though you're running unminified and uncombined files.
(Read more on this here)
As announced at jQuery 1.11 and 2.1 Released, the source map comment will be removed so the issue will not appear in newer versions of jQuery.
Here is the official announcement:
One of the changes we’ve made in this beta is to remove the sourcemap
comment. Sourcemaps have proven to be a very problematic and puzzling
thing to developers, generating scores of confused questions on forums
like StackOverflow and causing users to think jQuery itself was
broken.
Anyway, if you need to use a source map, it still be available:
We’ll still be generating and distributing sourcemaps, but you will
need to add the appropriate sourcemap comment at the end of the
minified file if the browser does not support manually associating map
files (currently, none do). If you generate your own jQuery file using
the custom build process, the sourcemap comment will be present in the
minified file and the map is generated; you can either leave it in and
use sourcemaps or edit it out and ignore the map file entirely.
Here you can find more details about the changes.
Here you can find confirmation that with the jQuery 1.11.0/2.1.0 Released the source-map comment in the minified file is removed.
Download the map file and the uncompressed version of jQuery.
Put them with the minified version:
Include minified version into your HTML:
Check in Google Chrome:
Read Introduction to JavaScript Source Maps
Get familiar with Debugging JavaScript
The new versions of jQuery require this file http://code.jquery.com/jquery-1.10.2.min.map
The usability of this file is described here http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
Update:
jQuery 1.11.0/2.1.0
// sourceMappingURL comment is not included in the compressed file.
If you want to get source map file different version, you can use this link
http://code.jquery.com/jquery-x.xx.x.min.map
Instead x.xx.x put your version number.
Note: Some links, which you get on this method, may be broken :)
As I understand the browser, Chrome at least, it doesn't disable the source mapping by default. That means your application's users will trigger this source-mapping request by default.
You can remove the source mapping by deleting the //# sourceMappingURL=jquery.min.map from your JavaScript file.
After following the instructions in the other answers, I needed to strip the version from the map file for this to work for me.
Example: Rename
jquery-1.9.1.min.map
to
jquery.min.map
I was presented with the same issue. The cause for me was Grunt concatenating my JavaScript file.
I was using a ;\n as a separator which caused the path to the source map to 404.
So dev tools was looking for jquery.min.map; instead of jquery.min.map.
I know that isn't the answer to the original question, but I am sure there are others out there with a similar Grunt configuration.
jQuery 1.11.0/2.1.0 the // sourceMappingURL comment is not included in the compressed file.
Assuming you've checked the file is actually present on the server, this could also be caused by your web server restricting which file types are served:
In Apache this could be done with with the <FilesMatch> directive or a RewriteRule if you're using mod_rewrite.
In IIS you'd need to look to the Web.config file.
I am trying to get phpDocumentor2 to build API documentation for a PHP project I am working on.
The problem is that the HTML output landing page does not show the packages defined in my project. It only shows "Global ()" package.
I believe I am properly using the #package tag for my classes. phpDocumentor version is 2.0.0b4.
In my efforts to find the bottom of the problem I found a project that is already using phpdoc2. I downloaded that project and tried to build the documentation myself as it has a phpdoc.dist.xml file in its codebase root. I got the same problem: no packages in HTML output landing page, while the vendor's one is showing them (SimplePie, CodeIgniter, Streams etc.).
How can I get my phpdoc output showing packages?
I think you are experiencing a bug in the early betas. Keep watching for new beta releases, as they are coming out quite fast as bugs are reported and fixed.
I have this posted here:
https://getsatisfaction.com/pixelandtonic/topics/wygwam_not_styled_in_cp_entry_and_not_functioning_shown_errors_attached
...but I really need a fix asap if anyone can help here.
I can't get Wygwam to work.
It started with me running this:
EE 1.6.8 (Again, can't update)
Wygwam 2.1.6
FieldFrames 1.4.5
I wasn't able to activate the module. I would receive errors and then the field was jacked.
I then upgraded Wygwam to 2.6.3 and that allowed my to enable the module.
The problem I have now is this:
When I try to Add a new Wygwam field, it tells me that there are no configurations available. When I go to 'Edit Configurations', I only get the serial number input field. I added the serial number, but nothing changed. Under 'Editor Configurations' it just says: There are currently no configurations.
Now I have the existing fields back, however, I cannot view source and do not have any "Configurable Editors" available. I also cannot setup any "Configurable Editors" in the module because I have no settings/options display. Also, I cannot add any new Wygwam fields because when I do, I just get a white screen.
Ok, While this may not be the best answer to provide, it has provided a resolve to the situation I was in.
First off, Kudos goes to Brad Bell at Pixel & Tonic for sticking with me via emails in trying to get this fixed. I am in a situation with this site in which I can't provide access to the site, files, data, etc. It definitely makes getting help with EE related instances more difficult. Brandon and his staff definitely know how to push through these issues.
Thanks guys.
Nothing we were trying was working. What I had to end up doing was rolling back the versions of Wygwam and Matrix from the more recent releases that were installed to WW 2.1.1 and Matrix 2.0.11
I didn't try newer versions as I want to push harder than ever now for a site update/rebuild due to these issues and others. The site is again functional in these areas and they can move forward, (or laterally... depending on your stance), again.
I am converting some docs to pdf using wkhtmltopdf (currently using perl and the command line versions). Is it possible to change the "PDF Producer", "PDF Version" and "Fast Web View" fields? The current defaults are "wkhtmltopdf", "1.4 (Acrobat 5.x)", and "No", respectively. I didn't see anything in the wiki page
Pass the following with the command line to see supported features: " --extended-help"
Not sure if those specific params are supported or not.
I patched wkhtmltopdf to support an additional flag recently, and it would be quite easy to add parameters to change those. I don't believe they are supported currently, though.
PDF Producer: Nope. Most apps want folks to know that particular app generated the PDF.
PDF Version: Nope, but trivial. The version number at the beginning of the file is just a courtesy really. What exactly are you after with this? Chances are you don't really need it. The PDF generated isn't going to acquire any features automagically just because the PDF claims to be this version or that. It's only really used so a viewer opening a newer PDF can say something like "I don't support this version, some stuff might not work". Because everything will work regardless (unless someone happens to have a VERY old version of Acrobat/Reader), I don't see the issue.
Fast Web View: Nope, and decidedly non-trivial. "Fast Web View" means everything needed to display the first page of the PDF is sorted to the front of the file, and there are various "hints" on where an app downloading the PDF can find this or that. It's not just a flag, not by a long stretch.
Zero for three. Sorry.