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?
Related
When I updated the style.css in Appearance > Theme Editor > stylesheet(style.css),
I refresh my site, then I see that the style is not applied.
I've also tried clear cache in browser and use cmd + shift + r to re-download the resources but still not working.
Is there any way to make the site live for development, or is there any preferred way for development?
In style.css
...
/*
Author: xxx Limited
Description: This is the template for xxx
Version: 1.0.0. // tried to update the version here but not working
...
*/
.....
Need to check few things.
upload style.css through ftp or cpanel again to check whether it is properly saved or not,
Remove cache , check in private window to make sure that there is no cache.
check in console for error if above 2 doesn't work.
If the CSS file has been updated, the problem is because of caching. There are different levels of cache.
Clear Cloudflare cache if you are using it.
Clear any caching mechanism that your Webhosting offered.
Clear all plugins cache
Salman and PHP Geek are right, do the steps they mention that should solve your problem. If the problem continues then...
In function.php find wp_enqueue_style function it would look something like this. There can be multiples of them so look for the 'style.css' inside them
wp_enqueue_style('yourtheme-style', get_template_directory_uri() . '/style.css', '', '1.1.0');
see the last argument '1.1.0' this could be anything on your case, this can also be a variable. Change this to something else like '1.1.1' (anything other then 1.1.0)
OR
replace the line with the below code (doing this will change your version automatically whenever you change something in the style.css)
$ver = filemtime(get_template_directory().'/style.css');
wp_enqueue_style('yourtheme-style', get_template_directory_uri() . '/style.css', '', $ver);
When using the MediaWiki software, how do you disable the popup saying "Your edit was saved." from appearing?
This feature has been created after A/B testing to provide users a feedback that their edit indeed has been saved. The module providing this functionality was unconditionally loaded, while now it's only loaded if a cookie, was set in EditPage.php. It will trigger a label/popup on the next page loading with action=view (the default action). There was an HTML snippet, while now, HTML is generated by JavaScript mediawiki.action.view.postEdit.js.
2 ways to get rid of it:
As a server administrator (and you'll have to remember to re-install this hack after upgrading): Remove the line loading the module mediawiki.action.view.postEdit - this will possibly save you a few bytes bandwidth, too.
As a site administrator: Hide the message by adding the following to MediaWiki:Common.css:
.postedit {
display: none;
}
I'm using attempting to add an "onclick" object to a page in a singlesite (i.e. rather than multisite) WordPress that triggers an event. The code is:
Send a voice message
When attempting to save the code, WordPress strips the onclick object leaving:
Send a voice message
A user on another forum suggested that this restriction should only apply to multisite non-superadmin users. Again, this is a siglesite with only one admin user.
It is understood that WordPress removes "onclick" from HTML to prevent malicious code. Still, does anyone know how to resolve this?
Thanks.
It appears that with current Wordpress (I'm on 4.9.4), TinyMCE does the filtering directly on the editor screen, not when the form is submitted. The allowedtags and allowedposttags don't seem to matter, so the solution above does not solve the problem for me.
The method I have developed uses the tiny_mce_before_init filter to alter the allowed tags within TinyMCE. The trick is to add the extended_valid_elements setting with the updated versions of the elements allowed for a.
First, look in the page http://archive.tinymce.com/wiki.php/Configuration3x:valid_elements to find the current value for a, which right now is
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur]
And add to the end of that the onclick attribute:
a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]
Then use that in the filter function like this:
function allow_button_onclick_mce($settings) {
$settings['extended_valid_elements'] = "a[rel|rev|charset|hreflang|tabindex|accesskey|type|name|href|target|title|class|onfocus|onblur|onclick]";
return $settings;
}
add_filter('tiny_mce_before_init', 'allow_button_onclick_mce');
which you install in your functions.php file in Wordpress. You can see it in action by toggling the text and visual view on the edit page. Without the extended list, the onclick goes away. With it, it remains.
You can solve this by changing the anchor tag into button and adding a script. For more info please refer to this link: Wordpress TinyMCE Strips OnClick & OnChange (need jQuery).
By resolving, I'm assuming you mean to allow the onclick attribute. You will want to be careful with this, because modifying the allowed tags does this for all your users.
You can modify the list of allowed tags and attributes, by adding this to your functions.php file:
function allow_onclick_content() {
global $allowedposttags, $allowedtags;
$newattribute = "onclick";
$allowedposttags["a"][$newattribute] = true;
$allowedtags["a"][$newattribute] = true; //unnecessary?
}
add_action( 'init', 'allow_onclick_content' );
I suggest trying it with only $allowedposttags first to see if that works for you. According to this other stackexchange post, you should only need allowedtags if you need it for comments or possibly non-logged-in users, but when I did something similar in the past, I needed both of them to work.
On a side note, if you want a list of all already allowed tags and attributes, look inside your /wp-includes/kses.php file.
I've added shibboleth authentication (ShibAuthPlugin 1.2.3) to a MediaWiki site (mw 1.17). That turned out to be pretty straightforward, but I now have another related problem: I have two login links. I want only the Shibboleth login link to be available.
I can alter the CSS to hide the unwanted link, but that only makes it invisible. I want to disable it. The documented ways of disabling login links disables all login links. I'm new to MediaWiki and would expect to be able to make this change in the configuration and not have to hack the code to get what I want.
Perhaps someone familiar with MediaWiki can tell me if such a configuration setting exists, or if code modification is the best practice for solving this kind of problem.
Thank you in advance,
Peter
To just remove the login link, I suspect this FAQ entry may help; it seems to be more or less how the Shibboleth auth extension does its own login/logout link mangling. For convenience, let me copy the code here:
$wgHooks['PersonalUrls'][] = 'lfRemoveLoginLink';
function lfRemoveLoginLink( &$personal_urls, $title ) {
unset( $personal_urls['login'] );
unset( $personal_urls['anonlogin'] );
unset( $personal_urls['createaccount'] );
return true;
}
If you want to completely disable local login/logout, even if the user deliberately goes to Special:UserLogin, this solution might do the trick. Again, let me copy the relevant part of the code below:
function LessSpecialPages(&$list) {
unset( $list['Userlogout'] );
unset( $list['Userlogin'] );
return true;
}
$wgHooks['SpecialPage_initList'][]='LessSpecialPages';
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.