Here is my situation:
I have this modernizr js file that reads
Build: http://www.modernizr.com/download/#-cssanimations-iepp-cssclasses-testprop-testallprops-domprefixes-load
To redownload this build (i thought i could just paste the url, but it didnt work.
When i went to the site, it lets you compose your build but you have use human readable features /components/names, but after you build it, the file has these abbreviations.
Is there a way to know what the abbreviations of the listed components on the site?
There is a server issue on the modernizr site (sorry about that!). It is redirecting any http traffic to the https homepage. In the mean time, just throw an s on it - like so
Related
I am just getting started learning DocPad and hope to use it on a few sites that will serve some fairly javascript heavy pages. I am also hoping to be able to keep the javascript as modular as possible using nodes export and require conventions because much of the code I want to use has already been written that way.
I’ve install the babel and browserifydocs plugins, but I am getting errors every time I try use import or require. If I follow the directions on the babel plugin site and add
---
browserify: true
---
to the js.babel files, I get an Invalid left-hand side expression in prefix operation error.
Is it possible to use javascript I have or do I need to add all of the javascript files in the #getBlock(“scripts”) line of the layout file.
Can you upload the full docpad log file somewhere, generated via running docpad with the -d flag.
Looking at this, it seems the issue may be the space before browserify: true
Perhaps cc the babel plugin author in on this.
If you want to do a proper modular js do it with webpack (https://blog.madewithlove.be/post/webpack-your-bags/) that is specially designed for it. Then just combine it with DocPad in the way that at the end of the generation you trigger a webpack compilation. DocPad sends proper events where you can hook in.
Also there is a plugin for that but I never used it and I'm not sure how good it is https://github.com/RobLoach/docpad-plugin-webpack
I want to change the look and feel(ui customization) of Jenkins. Also I would like to add new views(say like new html pages or web pages) with navigation to the required jenkins pages etc.
Please let me know if any single plugins will help me to do so.Any relevant information(how ever generic) will be very helpful.
Any suggestions or links or tutorials is also appreciated.
PS:- Pretty new to jenkins.The inputs from here will help me to add more details to the questions.
I am looking for documents or tutorials that specify Skinning Jenkins using plugins like :-
https://wiki.jenkins-ci.org/display/JENKINS/Simple+Theme+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/jQuery+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/jQuery+UI+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/JSWidgets+Plugin
The plugin page is providing very little information on how to use these and the benefits and the extend to which the UI can be changed.
Any doc or link is appreciated.
Assuming you don't want to write a Jenkins plugin, for adding pages, the best suggestion I can make is to use an HTTP proxy such as NginX, and configure it so that the pages you want to add are plain html files, and Jenkins is proxied for the rest of them. To a visitor, they will look like they are all part of the same site; you could copy code from the head and body sections of Jenkins-served pages to include some of the navigation.
The Simple Theme Plugin, which you found, will let you do basic customization of the look and feel of Jenkins. I do that for my build server and proxy it using this configuration fragment for NginX. The relevant CSS is in this CSS file - toward the end, look for the // JENKINS CUSTOMIZATION comment.
We use the Simple theme plugin - pointed at a css file for the simple styling, and a JS file to fix a couple of DOM oddities (some of the tables in the new look and feel have mismatching column counts).
Those two files need only be hosted either a handy http server, or you can place them in usercontent.
You need only refresh the page in the browser to see the changes. Both files can then happily reference other files served up too.
Handy things to note:
Jenkins has jquery, parts of YUI loaded and prototype loaded - so you can use them in your scripts.
If while debugging, the refresh gets in the way then use the console to enter the following to temporarily stop it without pausing JS: refreshPart = function() {}
When making DOM tree changes to content that is refreshed - attach it to the layout updates with:
layoutUpdatecallback.add(my_function) - that way your changes are applied to new incoming content.
I'm trying to use a Maven build to deploy to Confluence site using XML-RPC.
I'm having trouble finding the right protocol to use in distribution management. It is password protected.
Use one or both of the following:
Proxy Configuration
Maven Server Authentication
I don't think it's a good idea. Maven Site does not fit so well for Confluence: they have a specific layout... you should customize a lot of things in order to create a site that could be uploaded to Confluence, and the deployment is only the tip of an iceberg.
Instead, I suggest you to think to a different content, written in Markdown (or asciidoc, ...). It's very easy to convert those type of content in HTML compatible with Confluence.
By the way, if you need to upload a maven site style I suggest you to take a look at maven-confluence-plugin: in the wiki pages you can find the configuration to apply to do what you need.
I'm working on a similar plugin too. It's called confluence-maven-plugin. However the phylosophy of my plugin is not to be able to upload site, but to upload simple Markdown documentation to a confluence, guided mainly by a README.md as you probably do when you work with Github/BitBucket/etc...
I have a lot of experience with YUI2 and I'm getting up to speed on YUI3. The service I'm writing needs HTTPS, but the vanilla YUI experience loads from Yahoo's HTTP-only CDN, which quietly fails in Chrome and loudly fails in modern IE when the browser tries to mix an HTTPS page with HTTP javascript.
My goals are to get all of:
Site uses HTTPS
YUI works in Chrome & IE (so scripts also must be delivered over SSL)
Uses a modern version of YUI 3 (this disqualifies YUI PHP Loader which hasn't been updated to support even YUI 3.4, while 3.8 is "current")
Use roll up combos for speed instead of many JS and CSS files (this disqualifies Google's CDN... if YUI 3 is actually hosted there which I couldn't find.)
Site dynamically loads YUI dependencies (dependencies change regularly as I add functionality, going back to the configurator and saving a new bundle every time is a PITA)
The obvious solution appears to be to give up goal #5 and just self-host combos.
How can I meet all 5 goals?
The easiest way to solve it is to change base URL from
http://yui.yahooapis.com/ to
https://yui-s.yahooapis.com/
Depending upon your server environment, you have a couple of options.
Development
Download the latest YUI library, and upload the yui/build/ folder to your server. The seed file should work fine without modification, though you won't be able to take advantage of combo loading.
Production
Use the YUI Configurator to determine all the files that you will need for each module set, and download them manually from the combo links provided. Rename them to something suitable like yui3.8.0-node-rollup.js and serve these to your users.
Be advised that if you use different module sets for different scripts, you may need to make multiple sets of files from this process, depending upon how you set it up. There is also a question here about concatenating Javascript together, if you are curious.
As an addendum, in my past research, I discovered that pulling external libraries over a secure connection may not be a safe idea.
Is there any way to configure DocPad generate pages without extension, so hosting as static site in url it will look like: http://mysite.com/page1/ ?
Yes, but in a different way.
The cleanurls plugin when generated for a static environment (so docpad generate --env static) will output say pages/welcome.html as pages/welcome/index.html which accomplishes what you're after - which is you can access pages/welcome in your browser no worries. Document URLs will also be updated to reflect this.
The issue of just outputting pages/welcome without the extension is that then the server is not aware of the mime type of the file which the browser often needs to know how to process the file correctly.