I'm working on a project that has:
Bootstrap
FontAwesome
It's own custom stylings
When I write something like this:
.some-el {
font-size: $f (and then wait)
}
Then it thinks for a second and then suggests something like this:
$focus [my variable]
$fa-font-display [implicitly imported from font-awesome]
$fa-font-path [implicitly imported from font-awesome]
$fa-css-prefix [implicitly imported from font-awesome]
$font_size_base [my variable - that I was looking for]
...
...
It gets better with time, since it remembers what I've used previously - so I guess this is something that would fix itself. But it would be awesome to be able to fix it myself right away.
This is just an example where FontAwesome-variable are a nuisance, but other times it's the Bootstrap-variables.
How can I define which SASS-variables that are suggested (and/or the order of the suggestions)?
Solution attempts
Googled a bunch.
Looking through settings for 'Code Completion' and 'Code Style'
It's not possible. The only way I can think of is excluding the folder where the .css/.scss files you don't like getting completion from are stored from indexing (Mark directory as/excluded).
Related feature request: WEB-41257
I have the following written in a driver:
add_action( 'wp_enqueue_scripts', 'add_css_file' );
function add_css_file()
{
// Tried this prior:
// $path = ABSPATH . "/wp-content/plugins/this_plugin/css/";
// wp_register_style( 'css_file', $path.'css_file.css' );
wp_register_style( 'css_file', 'http://subdomain.mysite.com/wp-content/plugins/this_plugin/css/css_file.css' );
wp_enqueue_style( 'css_file' );
}
The string "css_file" does not appear in the View Source HTML and the CSS rules defined therein do not take effect.
Have you included wp_head() in the <head> of your page? wp_head() will add your queued styles and scripts to the page.
The problem for me lay in the fact that I am modifying the Admin screen rather than the display of a Page or Post to viewers.
Replace:
wp_enqueue_script(...)
With:
admin_enqueue_script(...)
Best of luck.
I have just tried this snippet in my site, and it is working properly. You may get conflict with some other plugin/code.
Also make sure you don't have any Cache enabled, and if so, try to clean up the cache. Also try to clean out your browser cache.
Finally, if non of the above works for you, try to de-activate your plugins, one by one in order to see if some of the plugins conflicts with this function, and in last step try to change theme, also to make sure the current theme doesn't conflict with this function.
Following up this question on SO, I am looking to change the default DIV container name that JWplayer provides to JWPlayer Div. The problem is that it starts with a numeric and that creates loading problems.
Is there a way, I can customize this JWPlayer ID ?
This is how it looks btw,
jwplayer('141ef7fe77391234fc105767808cc0a5').setup({"file":"my_video.mp4",
"width":"838","height":"383","controlbar":"none",
"modes":[{"type":"html5"},{"type":"flash","src":"http://path/jwplayer/player.swf"}]});
While you're at it, here is a quick solution to it.
Since this is a fix for Drupal JWPlayer Module, do the following:-
Go to jw_player module folder and open theme folder.
Open jw_player.tpl.php and add the following line on top (probably where PHP declaration starts).
$html_id = "myvideo". $html_id;
It kinda does the job but I am sure you guys have better solutions than this. Please feel free to comment.
Found a better solution
Don't do upper suggestion. Paste the following code in jw_player.module instead.
Find this line $variables['html_id'] = md5(rand()); (I guess line 308) and uncomment it before pasting the following code instead.
while(1) {
$variables['html_id'] = md5(rand());
if (ctype_alpha(substr($variables['html_id'], 0, 1))) {
//echo "First Digit is Alphabet";
break;
}
}
Thanks.
Does anyone know of an extension for Firefox, or a script or some other mechanism, that can monitor one or more local files. Firefox would auto-refresh or otherwise update its canvas when it detected a change (of timestamp) in the files(s).
For editing CSS, it would be ideal if just the CSS could be reloaded, rather than a full HTML re-render.
Effectively it would enable similar behaviour to Firebug with its dynamic HTML/CSS editing, only through external files.
Live.js
From the website:
How?
Just include Live.js and it will monitor the current page including local CSS and Javascript by sending consecutive HEAD requests to the server. Changes to CSS will be applied dynamically and HTML or Javascript changes will reload the page. Try it!
Where?
Live.js works in Firefox, Chrome, Safari, Opera and IE6+ until proven otherwise. Live.js is independent of the development framework or language you use, whether it be Ruby, Handcraft, Python, Django, NET, Java, Php, Drupal, Joomla or what-have-you.
It has the huge benefit of working with IETester, dynamically refreshing each open IE tab.
Try it out by adding the following to your <head>
<script type="text/javascript" src="http://livejs.com/live.js"></script>
Have a look at FileWatcher extension:
https://addons.mozilla.org/en-US/firefox/addon/filewatcher/
it's a WebExtension, so it works with the latest Firefox
it has a native app (to be installed locally) that monitors watched files for changes using native OS calls (no polling!) and notifies the WebExtension to let it reload the web page
reload is driven by rules: a rule contains the page URL (with regular expression support) and its included/excluded local source files
open source: https://github.com/coolsoft-ita/filewatcher
DISCLAIMER: I'm the author of the extension ;)
I would recommend livejs
But it has following Advantages and Disadvantages
Advantages:
1. Easy setup
2. Works seamlessly on different browsers (Live.js works in Firefox, Chrome, Safari, Opera and IE6+)
3. Don't add irritating interval for refreshing browser specially when you want to debug along with designing
4. Only refreshing when you save change ctrl + S
5. Directly saves CSS etc from firebug I have not used that feature but read on their site http://livejs.com/ that they support it too!!!
Disadvantages:
1. It will not work on file protocol file:///C:/Users/Admin/Desktop/livejs/live.html
2. You need to have server to run it like http://localhost
3. You have to remove it while deploying on staging/production
4. Doesn't serves CDN I have tried cheating & applying direct link http://livejs.com/live.js but it will not work you have to download and keep on local to work.
Xrefresh with firebug.
Firefox has an extension called mozRepl.
Emacs can plug into this, with moz-reload-on-save-mode.
when it's set up, saving the file forces a refresh of the browser window.
There are some IDE's that contain this ability (They'll have a pane within them or some other means to auto-refresh a page on save).
If you want to do this yourself a quick hack is to set the meta refresh on the page to a low value - one or two seconds.
# Will refresh the page content every second
<meta http-equiv="refresh" content="1" />
You could just place a javascript interval on your page, have it query a local script which checks the last date modified of the css file, and refreshes it if it changed.
jQuery Example:
var modTime = 0;
setInterval(function(){
$.post("isModified.php", {"file":"main.css", "time":modTime}, function(rst) {
if (rst.time != modTime) {
modTime = rst.time;
// reload style tag
$("head link[rel='stylesheet']:eq(0)").remove();
$("head").prepend($(document.createElement("link")).attr({
"rel":"stylesheet",
"href":"http://sstatic.net/mso/all.css?v=4372"
})
);
}
});
}, 5000);
Browsersync can do this from the server side / outside of the browser.
This can achieve more repeatable results / things that don't require so much clicking.
This will serve a page and refresh on change
cd static_content
browser-sync start --server --files .
It also allows a scripting mode.
This is certainly hacky, but if you want to work locally without making any external request (to live.js, for example), or run any local server, I think this might be useful. This is not specific to web development, you can adopt similar strategy to any other workflow.
You will need two tiny tools (which are present in almost all distribution repos): inotify-tools and xdotool.
First get the ID of your Firefox and your editor window using xdotool.
$ xdotool search --name "Mozilla Firefox"
60817411
60817836
$ xdotool search --name "Pluma" # Pluma is my editor
94371842
Depending on the number of processes running, you will get one or more window ID. Use xdotool windowactivate <ID> to know which one you want (the focus changes to the respective window).
Use inotifywait -e close_write to monitor changes to your local file and when you save the file using your editor, change focus to your browser, reload xdotool key CTRL+R and focus back to your editor. This is so instantaneous you will not notice nothing.
Also, inotifywait exits on change, so you might have to do it in a loop. Here is a minimum working example (in Bash in your working directory).
while /usr/bin/true
do
inotifywait -e close_write index.html;
xdotool windowactivate 60917411; # Switch to Firefox
xdotool key CTRL+R; # Reload Firefox
xdotool windowactivate 94371842 # Switch back to Pluma
done
You can use inotifywait to watch for the entire directory or some selected files in your directory.
You can write a script that can automate is easily.
This works on Linux (I've tested this on Void Linux.)
You can use live.js with a tampermonkey script to avoid having to include https://livejs.com/live.js in your HTML file.
// ==UserScript==
// #name Auto reload
// #author weirane
// #version 0.1
// #match http://127.0.0.1/*
// #grant none
// ==/UserScript==
(function() {
'use strict';
if (Number(window.location.port) === 8000) {
const script = document.createElement('script');
script.src = 'https://livejs.com/live.js';
document.body.appendChild(script);
}
})();
With this tampermonkey script, the live.js script will be automatically inserted to pages whose address matches http://127.0.0.1:8000/*. You can change the port according to your need.
I think that you can solve it by using some ajax requests after a determinate interval. You can do a request to CSS files and then if you don't get the "not modified" header you delete your css and load it again. For dynamic files you do a request and store the response and then every time you make a request to that file you compare the response to the latest.
My theme's custom options panel has the following code...
`
/* initialize the site options */
if(get_option('permalink_structure')==""){update_option('permalink_structure', '/%postname%/');}
`
This checks the permalink option setting and since the WP default is "" which triggers the site.com/?p=x handler. This way, if the user has not yet set permalinks from the default, my script does it for them, by setting permalink to post name. Or at least that what I thought...
However, I've had a few folks who have my template tell me that upon first install, they were getting 404 errors on pages.
Apparently, the workaround is to physically navigate to the Permalinks page and just click "Save Changes" (even though when you first hit this page, the Permalink comes up as if it's correctly entered into the "custom" field.
Anyone know why this happens? Is their perhaps another setting in the db that determines the permalink in addition to what happens when update_options() is called as in the above code?
Well, this probably happens because you're updating value in database table (permalink_structure), while .htaccess remains the same, and that's why mod_rewrite isn't loaded and users are getting 404-errors on pages.
I believe WordPress also adds rewriting rules into .htaccess in order to enable permalinks when you're clicking "Save Changes" in admin panel. Let me dig it out and find out what WP is doing exactly.
EDIT.
Ok, here is the code that is doing what you're trying to accomplish:
<?php
if (get_option('permalink_structure') == "")
{
// Including files responsible for .htaccess update
require_once(ABSPATH . 'wp-admin/includes/misc.php');
require_once(ABSPATH . 'wp-admin/includes/file.php');
// Prepare WordPress Rewrite object in case it hasn't been initialized yet
if (empty($wp_rewrite) || !($wp_rewrite instanceof WP_Rewrite))
{
$wp_rewrite = new WP_Rewrite();
}
// Update permalink structure
$permalink_structure = '/%postname%/';
$wp_rewrite->set_permalink_structure($permalink_structure);
// Recreate rewrite rules
$wp_rewrite->flush_rules();
}
wp_rewrite does not appear to have any effect. Users still have to manually click "Save Options" on the permalinks screen.
I suppose I will run firebug on that page during the update to see what's getting set that update_options is apparently missing.
This would appear to be a bug in update_options when the option being updated is permalink_structure.
Anyone disagree?