I've been using Chrome's (latest stable build v49) devtools and Serverpress for years to develop local Wordpress sites. I haven't had an issue adding theme folders to workspaces then mapping CSS files to the network resource so I can make persistent changes until yesterday, when I started a new project and the mapping stopped working. I can see in the workspaces settings that the mapping is set up properly, but it simply doesn't make the connection--in the elements panel rather than edit the local file, it has me editing style.css?v=4.4.2. I'm going crazy, I've tried clearing out all other workspaces folders and mappings, reinstalled chrome, racked my brain for recent changes I've made to any settings that might have caused this, and searched high and low for others with the issue but no luck.
Another thing I've noticed is that when I attempt to map the local file to the system resource, the correct stylesheet I want to map appears in the list. But when I attempt to map the 'remote' stylesheet to the local file, the list of options is blank.
Any help would be amazing,
Well, it's absurd and a hack, but for anyone else who may come across this issue, I was able to fix it by adding a hook that strips the stylesheet version.
function remove_cssjs_ver( $src ) {
if( strpos( $src, '?ver=' ) )
$src = remove_query_arg( 'ver', $src );
return $src;
}
add_filter( 'style_loader_src', 'remove_cssjs_ver', 10, 2 );
add_filter( 'script_loader_src', 'remove_cssjs_ver', 10, 2 );
I have noticed this issue as well. Its a fix that the Chrome team is aware of and is trying to fix. From what I understand, basically it was a complete coincidence that it even worked in the first place because the code wasn't written to accommodate files with parameters. Check out the Chrome Dev Forum here.
Chrome Dev Forum Persistence Topic
Until then, if you are using Wordpress and you really want this feature to work, replace the version number in your wp_enqueue_style with null like so:
From This
wp_enqueue_style ( 'customstyle', get_template_directory_uri () . '/css/custom.css', false, '1.0', 'all' );
To This
wp_enqueue_style ( 'customstyle', get_template_directory_uri () . '/css/custom.css', false, null, 'all' );
That should solve your issue, at least until the DevTools team works it out.
Related
I've optimized my WordPress site performance and also checked its performance using web.dev
But still, have the following issues that I couldn't solve:
Remove unused CSS
Remove unused JS
Initial server response time was short
How can I Solve this issues?
Performance optimisation is a huge theme and probably can't be covered simply in one answer, but I still can point you to the right direction.
Remove unused CSS & JS
First, you have to determine what CSS and JS files you really load on each page, find out where they come from and think about whether you really need them or not. It often happens that a lot of heavy CSS & JS files are being loaded only for the sake of a simple animation that is used once somewhere on website. You can see all the files loaded in browser console, or with the help of services like GT Metrix. If you find assets that you don't need but they're still being loaded, first try to find a source (for example: a theme or a plugin) that loads them. Popular themes and plugins have settings for disabling some parts of assets so it's an easy one. For those that don't have any settings you can try this piece of code, just replace file names with yours.
add_action( 'wp_print_styles', 'remove_styles' );
add_action( 'wp_print_scripts', 'remove_scripts' );
// Remove styles from plugins we don't need
function remove_styles() {
if ( $GLOBALS['pagenow'] != 'wp-login.php' && ! is_user_logged_in() ) {
wp_dequeue_style( 'coblocks-frontend' );
wp_dequeue_style( 'coblocks-frontend-css' );
wp_dequeue_style( 'wp-editor-font' );
wp_dequeue_style( 'duplicate-post' );
wp_dequeue_style( 'thickbox' );
}
}
// Remove scripts from plugins we don't use and don't need
function remove_scripts() {
// just in case we use those in wp-admin, exclude only from front-end loading
if ( ! is_user_logged_in() ) {
wp_dequeue_script( 'coblocks-animation' );
wp_deregister_script( 'coblocks-animation' );
wp_dequeue_script( 'thickbox' );
wp_deregister_script( 'thickbox' );
wp_deregister_script('jquery');
}
}
Ideally you need to keep your CSS and JS as small as possible but it can be tricky in modern WP themes that use a lot of it.
Initial server response time
Long response time mean that your server takes too long to return any data. 99% of the times it is either because of badly-optimised website or a weak server. Latter can be easily solved by moving to another hosting provider or changing hosting plan.
Website optimisations are trickier and may require profiling, especially if you already have proper full page caching installed . Generally, I can describe all the general cases like this:
Slow server response + no caching = try caching first. WP Super Cache, WP Rocket or similar plugins.
Slow server response + caching = try hosting providers with nginx-caching support (basically serving static content on each page load). I can recommend Kinsta or Pressjitsu.
Slow server response + a lot of dynamic content = You can't cache things the same way as regular websites. Here you need an experienced dev who should first profile you website with tools like xhprof or blackfire.io and then gradually work on optimising performance of the worst performing functions.
I’m using localhost for wordpress theme development by xampp server. When I change in my css file it not work instantly. Its work may be after 3-4 hours. css dynamically linking is ok. Wht’s the problem plz.?
Sometimes I have found that the browser will cache assets when running under localhost and make it appear as though updates are not taking effect. It's hard to tell from your description if this might be the problem, but try clearing cached images and files and see if that helps.
Sounds like you have some intense caching. In local development you can bust the cache with a different version numbers in your wp_enqueue_style call. Version number is the 4th parameter. In this example, we'll update the version number to be the current date/time of the latest change to the style.css file.
/**
* Proper way to enqueue scripts and styles
*/
function theme_name_scripts() {
$cacheBusterCSS = date("U", filemtime( get_stylesheet_directory() . '/style.css' ) );
wp_enqueue_style( 'style-name', get_stylesheet_uri(), array(), $cacheBusterCSS );
}
add_action( 'wp_enqueue_scripts', 'theme_name_scripts' );
This kind of dynamic version number is only for local development and is a bad idea for production sites when you want to leverage caching for better page load times.
I have a problem with a WordPress site.
When I am trying to update page content or edit css file, changes not appearing in front-end. It looks like cache problem, but I empty my cache every time and nothing helps. I should wait some hours or try another browser to see changes that I've made.
I am not using any cahce plugins and don't know why content changes take so long to go live.
Please help me.
This is standart browser cache for CSS and JS files. You can reload page with CTRL+SHIFT+R buttons. If you want to display your new CSS for all users, you need to change the version of CSS-file in your theme. Read More: https://codex.wordpress.org/Function_Reference/wp_enqueue_style
I am facing this kind of issues these days too, what I do is, in the
wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
in $ver i place php function time() it changes after every second, I think this technique is best for development purpose.
so the final enque will be
wp_enqueue_script( 'myscript', filesourse/file.js, array(''), time(), true );
for the style you can also use time() at the $ver position
wp_enqueue_style( 'mystyle', filesourse/file.css, array(''), time(), 'all' );
Hope this will work for you too,
If you have cache folder in your rootfolder rename it and try,because your all site configuration store that cache folder in root folder.
in the plugins page, under each plugins' name usually there are buttons/links like "Deactivate | Edit | Settings". Recently on one of my sites the "Edit" (and "Settings") button has disappeared. I have just "Deactivate" or "Activate | Delete".
My question is - what could cause this?
I am logged in as an administrator, so I should see the buttons. I suspect that something might have vent wrong with the installation of the last plugin but I am not sure.
Is there some scenario when these buttons get disabled (hidden) or do I have a bug / error?
EDIT:
This is happening on the server. I also have the exact same files (just checked with a comparer) running on my local computer, where plugins have all the buttons. I am now looking in the DB to find differences, but so far have not found anything significant.
Sounds like a file permissions error, make sure the user the web server is running as (typically www-data or similar) has write permissions to the plugin files.
Those "buttons" are called "plugin_action_links" and are/can be set by the plugin´s author.
Some plugin authors choose do not include "settings" .
If you have updated the plugin it might be that the new version does not include that ??
Does the plugin itself work ?
Is it the exact same version as on the other sites ?
As for the "edit" link - it can also be set to not appear or be disabled by third-party plugins that has to do with user-permissions or visibility of links (like adminimize for example)
example how to disable those links for plugin authors :
add_filter( 'plugin_action_links', 'disable_plugin_footlinks', 10, 4 );
function disable_plugin_footlinks( $actions, $plugin_file, $plugin_data, $context ) {
// Remove edit link. if you want to remove selective use if statement
if ( array_key_exists( 'edit', $actions ) )
unset( $actions['edit'] );
// Selectively remove deactivate link for specific plugins with if statement
if ( array_key_exists( 'deactivate', $actions ) && in_array( $plugin_file, array(
'plugin1_specific_name_folder_/plugin1_name.php',
'plugin2_name_folder_/plugin2_name.php'
)))
unset( $actions['deactivate'] );
return $actions;
}
Ok, this is a biggie. Here's the deal:
I have upwards of 50 installs of WordPress running on MAMP Pro locally. For some of them I use local/whatever, for others I set up virtual hosts as whatever.local/. WordPress has never had any problems. Yesterday, installed a copy of WP 3.0.1 (fresh, straight off the server), and started templating. Today, I returned to it to continue, first by registing default navigations. I put the necessary lines in functions.php:
add_theme_support( 'menus' );
add_action('init', 'register_custom_menu');
function register_custom_menus() {
register_nav_menu('primary_menu', __('Header Menu'));
register_nav_menu('404_menu', __('404 Menu'));
}
Fine, right? I also tried it with register_custom_menu, one at a time. In WordPress, no default menus show up. I've tried:
Activate a different theme, re-activate the original
Try Twenty Ten - still no custom navigations although a 'primary menu' is registered in the code, so it is NOT my functions.php
Tried another theme that I have running locally (that works perfectly in its original place), still no navs
Delete the entire database and re-install WP
Delete the entire directory, re-download WP, reinstall
Delete the virtual host and work from localhost/whatever
So, I have a ton of other WP sites working perfectly fine with nav registering, but I can't create any more? I'm completely, totally lost.
Any input would be appreciated, right now I'm at my wit's end. Let me know if you need any more information.
Three things:
You should be hooking menu registration onto 'after_setup_theme', not 'init'
You don't need to call add_theme_support() since register_nav_menu() takes care of that.
You can use register_nav_menus() to take care of all your menus at once.
However, the biggest reason this isn't working is because you're not calling your function. The callback on add_action should be 'register_custom_menus' (notice plural). The spelling has to match the function declaration. This is how I'd suggest you rewrite it:
add_action('after_setup_theme', 'register_custom_menus');
function register_custom_menus() {
register_nav_menus( array(
'primary_menu' => __('Header Menu'),
'404_menu' => __('404 Menu') ) );
}