Title: ecartz's Replies | WordPress.org --- # ecartz [ ](https://wordpress.org/support/users/ecartz/) * [Profile](https://wordpress.org/support/users/ecartz/) * [Topics Started](https://wordpress.org/support/users/ecartz/topics/) * [Replies Created](https://wordpress.org/support/users/ecartz/replies/) * [Reviews Written](https://wordpress.org/support/users/ecartz/reviews/) * [Topics Replied To](https://wordpress.org/support/users/ecartz/replied-to/) * [Engagements](https://wordpress.org/support/users/ecartz/engagements/) * [Favorites](https://wordpress.org/support/users/ecartz/favorites/) Search replies: ## Forum Replies Created Viewing 4 replies - 1 through 4 (of 4 total) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [Trouble with javascript and css after latest upgrade of W3 Total Cache](https://wordpress.org/support/topic/trouble-with-javascript-and-css-after-latest-upgrade-of-w3-total-cache/) * [ecartz](https://wordpress.org/support/users/ecartz/) * (@ecartz) * [16 years, 7 months ago](https://wordpress.org/support/topic/trouble-with-javascript-and-css-after-latest-upgrade-of-w3-total-cache/#post-1201833) * I am having the same problem. The .8 release loses the previous minify settings and I can’t add them back. I have done a Verify URI on the file path and the popup shows the CSS file. * If I do a view generated source after clicking the add stylesheet button, I see * ```
  1.   
    ``` * However, if I look in the options function in lib/W3/Plugin/TotalCache.php I see * ``` $css_files = W3_Request::get_array('css_files'); ``` * If I add _include to css_files there: * ``` $css_files = W3_Request::get_array('css_files_include'); ``` * It changes the behavior and the CSS file setting that I enter shows on the subsequent page. However, it doesn’t actually include the CSS in the head. It does look like it removes the link if I enter one for the CSS manually in the head. I had to disable minify to get the site to work correctly. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Plugin: Developer Formatter] Version 2009.0.1.33 errors](https://wordpress.org/support/topic/plugin-developer-formatter-version-20090133-errors/) * Thread Starter [ecartz](https://wordpress.org/support/users/ecartz/) * (@ecartz) * [16 years, 7 months ago](https://wordpress.org/support/topic/plugin-developer-formatter-version-20090133-errors/#post-1218911) * Something that I did broke syntax highlighting. I’m not sure if it was from these changes or a subsequent change. I’ve reverted to 2009.0.1.32 until I have time to figure it out. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [Some observations w3-total-cache](https://wordpress.org/support/topic/some-observations-w3-total-cache/) * [ecartz](https://wordpress.org/support/users/ecartz/) * (@ecartz) * [16 years, 8 months ago](https://wordpress.org/support/topic/some-observations-w3-total-cache/#post-1164171) * I am just another user of this plugin, so don’t take my advice as gospel. However, my understanding is that the preferred place for javascript is footer, non-blocking. The impact of this is for the javascript to start loading after the HTML is almost completely loaded and it allows the HTML to finish loading before it actually runs the javascript. * In some cases, your javascript will need to be in the head as blocking so that it runs before the HTML loads (the HTML may include javascript that accesses the head javascript). In other cases, it will be sufficient for it to be in the footer as blocking. * In principle, the kind of javascript that needs to be blocking is javascript that actually displays content. I.e. it makes HTML appear on your page. The kind of javascript that needs to be in the head is the javascript that is called by javascript snippets throughout the body. For example, a function that does a document.write of some content that might be called in the page while it is rendering. Because it can control element position, CSS should always be head, blocking for this reason (and I don’t think that the plugin offers you an option to do CSS differently). * If you understand what all your javascript does well enough, you could figure out where it belongs. However, if you are just using the javascript (you didn’t write it yourself), you might try first setting everything as footer, non-blocking. Then, look around and see if the site works. If it doesn’t, move things to footer, blocking; head, non-blocking; head, blocking — (head, blocking should be last and footer, non-blocking should be first; I’m not as sure of the order of the middle two, but I think that footer, blocking will either work or not; head, non-blocking might seem to work in cases where you really want footer, blocking), and see if it fixes it. In general, you would prefer to have the javascript non- blocking and in the footer, but depending on how it is written, you might need to put it in the head and/or make it blocking to get it to work. * When testing your site, remember to clear your cache first, so that you have to load fresh copies of the javascript. That will highlight the kind of issues that a first time visitor to the site would see. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Plugin: Developer Formatter] After install many php error in setting page](https://wordpress.org/support/topic/plugin-developer-formatter-after-install-many-php-error-in-setting-page/) * [ecartz](https://wordpress.org/support/users/ecartz/) * (@ecartz) * [16 years, 9 months ago](https://wordpress.org/support/topic/plugin-developer-formatter-after-install-many-php-error-in-setting-page/#post-1175523) * There is a bug in devinstall.php. There is an extraneous comma at the end of the list of columns for {wp_}devfmt_config: * ``` showtools tinyint(1) DEFAULT '1', ``` * This causes the install to fail and never populate the programming languages. I ran the SQL manually (getting an error on the syntax) and then revised the SQL so it would pass. Then I uninstalled and installed the plugin and things seem to be working. * Presumably the code should be * ``` $sqlDevFmtConfig = "CREATE TABLE {$table_prefix}devfmt_config ( geshilangpath varchar(255) CHARACTER SET utf8 NOT NULL, geshiuselink tinyint(1) NOT NULL DEFAULT '0', displaylinenumbers tinyint(1) NOT NULL DEFAULT '1', usedevformat tinyint(1) NOT NULL DEFAULT '1', devfmtcss text CHARACTER SET utf8, linkjquery tinyint(1) DEFAULT '1', highlighttags tinyint(1) DEFAULT '0', copyclipboartext varchar(100) CHARACTER SET utf8 DEFAULT NULL, parsepre tinyint(1) DEFAULT '1', hookrss2 tinyint(1) DEFAULT '1', devversion varchar(30) CHARACTER SET utf8, showtools tinyint(1) DEFAULT '1' );"; ``` * Not sure whether this is a problem in all versions of MySQL — it’s actually a Perl Best Practice (according to Damian Conway) to make lists this way, but it doesn’t seem to work in my MySQL. Viewing 4 replies - 1 through 4 (of 4 total)