Selectively disabling plugins from loading in Wordpress admin area - performance

Does anybody know how to disable certain plugins from loading in the back-end/admin area of Wordpress?
Currently I'm running a site that has many plugins mainly geared towards front-end manipulation yet when I access pages in the backend (ie. /wp-admin/edit.php) all CSS, JS and plugin files are being loaded for plugins that are not required there, thus increasing the load-time and responsiveness of the admin area.
I'm looking for a solution, either plugin based for code that can selectively load admin only plugins, ideally without having to hack the core files.
I'm using wordpress 3.5.1.

Checkout Plugin Organizer. I haven't used it but according to it's description, you can "Selectively disable plugins by any post type or wordpress managed URL". I would guess that you could disable certain plugins from running on urls that contain /wp-admin/.
You can also modify the plugins themselves. It depends how they are written, but you can find where they are enqueuing the css and js files and wrap those in an is_admin() statement like this:
// Make sure we aren't in the admin area
if ( !is_admin() ) {
wp_enqueue_script('plugin-script');
wp_enqueue_style('plugin-style');
}
That will ensure that the scripts/styles are only loaded on the front end.
Another possibility is to find all of the css and script files that are being loaded via plugins and deregister them in your functions.php file. This will require you to poke around the plugins a bit to find the handles of all the files, but it should work well. This would deregister some of the default stuff enqueued in the admin area, so you can see what I mean.
add_action( 'admin_init', 'remove_admin_styles' );
function remove_admin_styles() {
wp_deregister_style(
'wp-admin',
'ie',
'colors',
'colors-fresh',
'colors-classic',
'media',
'install',
'thickbox'
);
}
As you said, you don't want to mess with core files, but if you absolutely need to you can implement the solution described in this article. As I'm sure you know, it's not a good idea to alter WordPress core files unless you absolutely have to. Just keep in mind that the changes will be wiped out if you upgrade WordPress in the future.

Related

Creating Magento Extension - Where to start?

I want to make an extension that injects videos on product pages.
I already read a lot of documentation in Magento website but, sincerely, I have no clue where to start. What's the difference between Magento Extensions and Widgets? Can I develop my extension using only JavaScript? Do I really need to use PHP to develop one?
So many questions, can't find a focus. Can you please share a simple follow trough for me to read on? Thanks.
Credits : Marius
https://magento.stackexchange.com/questions/8344/how-to-write-a-custom-extension/8345#8345
Here is what I usually do:
Always develop with error_reporting on.
Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
If the extension is linked to a core functionality add the
dependency in the declaration file <depends><Mage_Catalog /></depend>
If the module is for community use, use community as codepool to
give the developers the chance to override some classes without
modifying the code directly
Put your frontend design files in app/design/frontend/base/default
to make them available for all themes.
Put your admin design files in
app/design/adminhtml/default/default and do not change the admin
theme. I may want to change it in one of my modules.
Prefix your layout file names and template folder name with the
company name to make it easier to isolate them.
easylife_articles.xml and app/design/.../easylife_articles
Put your static resources (js, css, images) in a similar folder as
the template files easylife_articles/images/doh.png
Attach a simple text file with how to uninstall the extension: What
files need to be removed, what tables need to be dropped, what
config settings need to be removed from core_config_data table.
Do not write queries directly in models, blocks or helpers, use a
resource model for that.
Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
table names using ->getTable('sales/order').
Use the base url to include js files in template. Wrong
<script type="text/javascript" src="../js/some.js"></script>.
Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
Do not rewrite classes unless is necessary. Use observers and if
it's not possible use helper methods that receive as parameter and
instance of a class that you wanted to override. Wrong:
Override Mage_Catalog_Model_Product to add the method
getProductArticles(). Right. In your helper add
getProductArticles(Mage_Catalog_Model_Product $product)
If you override classes put a list of them in a readme.txt file
Use the default admin path for the admin section of your module.
Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
Add ACL for your admin sections. I may want to restrict access to
some of the admins.
Do not add an other js framework (jquery, mootools, ...) if it's not
necessary. Write you code in prototype.
Make you template html W3C valid (this is for OCD developers like myself).
Do not put images in the media folder. Use skin. The media
folder usually is not versioned and this makes it harder to move the
website on different environments.
Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
Test your extension with cache on and cache off.
Avoid using uppercase letter in the module and class names. If not
properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
Dispatch events in your code to make it easier for developers to
alter the functionality.
Follow the same coding standards that Magento uses and comment your code.
[Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all
websites are build in English and the identification of texts to
translate is time consuming.
If you sell an extension offer at least basic support. Or at least
answer the support e-mails you receive.
Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
(Inspired by this question)
Develop with the log activated and from time to time take a look at
the var/log/system.log file. The errors listed here are not shown
even with developer mode on. If there is at least one error you end
up with a large log file after a few months of running the extension.
If your extension affects the checkout process or the orders in
some way, make sure it works with multi-shipping, or if it
shouldn't work with multi-shipping, make sure it doesn't affect it.
Do not replace the default Admin Notification bar (or feed URL). If
I'm interested on what you have to offer I will subscribe to your
newsletter. Let me see what Magento has to say. It's more important
to me.
If you encrypt your code files with Ioncube (or something
else)...well...I just hate you and I hope your business goes bankrupt
That's what have so far. I will add more as soon as I think of something else.
You will definitely need XML and PHP, because this is mainly what Magento is built on.
Additionally to the official documents, there are a lot of helpful and very diverse tutorials out there that explain the mechanics of Magento. A web search helps, and I can recommend everything by Alan Storm, for example this litte module: http://alanstorm.com/magento_list_module
As soon as creating an extension works for you, you will also find a lot of tutorials on how to alter the product-view, or you can then post a more specific question here or on magento.stackexchange.com.

Jenkins UI customization

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.

How to use bootstrap size option in joomla 3.0?

I m new to joomla world. pls can any1 tell how to use bootstrap size option in joomla 3.0?
and i have 1 more question, what is the use of index.html in every modules folder which has no content in it ?
Second question answer
Web servers list all its directory-content in the browser if there's not present an index.html, making it easy for attackers to click on any of the links and view the contents; worse, if it's a PHP file, which will invariably execute upon clicking. That brings three risks:
Direct access to a PHP file exposes sensitive information (e.g. the
server's path structure) to directly alter codes.
It makes easier uploading hacking scripts to a site through any of
its vulnerable component. This allows for direct web access which
compromises the site.
It reveals the names and size of the site's files and helps
identifying any vulnerable extension, making it an easy target
The index.html files prevent the file listings from such exposures.
The "bootstrap size" option in the module parameters has to be supported by the used module chrome. From the default system chromes, only the html5 one does support it. Depending on your template, there may be other chromes as well which do support it. But since it's a rather new parameter, most templates probably don't support it yet.

Static vs. dynamic content in docpad system - how to create dynamic content?

DocPad is described as being comparable to other static site generators, but it is also described as being "not limited to static site generation".
I've been browsing the DocPad website and other documentation and haven't yet been able to find anything that seems to explain how to incorporate dynamic content, and what types of limitations may be involved?
As a relative beginner, I am wondering if anyone can help me better understand the methodology whereby dynamic content would be incorporated into DocPad...? e.g. AJAX, and dynamic server-side scripts for doing things like dynamically loading pictures from Flickr into a webpage when a certain tag is clicked...
Thanks.
So there's a few ways DocPad facilitates dynamic content:
Via the regenerateEvery configuration option. This will regenerate your website every so often you specify. This great when combined with plugins like feedr for pulling in data from remote feed sources (like your latest social activity), as well as repocloner which clones out and keeps a git repository up to date inside your project. The benefit of this option is it's really easy to do and provides the illusion of a dynamic website. For instance the Benjamin Lupton Website applies this method to keep it's statistics on the home page, as well as the social data in the sidebar up to date. Every hour it regenerates with the latest information. Making it fast, and also illusively dynamic.
Via the dynamic meta-data property. When set to to true this tells the DocPad server we should re-render that document on each request, rather than just once. This works great inside the Kitchensink Skeleton for search pages and misc forms. This way is most similar to PHP development.
Via the serverExtend event. This event allows you to hook into and extend the DocPad server, allowing you to add extra server-side logic, handling, etc. Common use cases is to add extra routing to your server to handle route aliases, adding form processing such as a contact form, or to add a RESTULful interface for a Backbone.js application. The DocPad Website uses this to add extra routing and a regenerate post-receive hook for the documentation. The NodeChat Skeleton uses this to add the Socket.io server-side logic.
Via the API. This way is the most involved but can be quite rewarding if you just wish for DocPad to be a small part of an existing node.js application. With this, you can create a DocPad instance in your code and interact with it. The grunt-docs grunt task utilises this :)

GWT like perfect caching for non-GWT resources

Perfect Caching
Perfect Caching allows the browser to cache resources forever and guarantees that changed resources are propagated immediately to the browser. In GWT this is accomplished by naming a file like the hash code of its content. As this leads to a new file name each time the content of a file changes, the browser can cache these files forever without having to ask the server whether or not there is a new version available. More about perfect caching can be found here.
As this concept works very well I would like to apply it to all of my non-GWT resources (some JS, CSS and image files).
As my build process is Maven based it would be great if there was a plugin which could automatically rename the files according to their hash code and which could adjust all of the references to this file.
Here's an example
Renaming
foo.css -> foo_39757cec04498955db62043f7ecfefc2.cache.css
logo.png -> logo_35bcdbbabe1944afc75eeeb16f06d1ad.cache.png
Update references in files
Replace all occurances of "foo.css" by "foo_39757cec04498955db62043f7ecfefc2.cache.css"
Replace all occurances of "logo.png" by "logo_35bcdbbabe1944afc75eeeb16f06d1ad.cache.png"
Does anybody know whether something like that already exists?
Many thanks in advance,
Michael
If you're using Apache (httpd) you can setup mod_pagespeed to do that. Since GWT does some of that stuff already, be careful to properly configure mod_pagespeed so that performance doesn't degrade.
mod_pagespeed indeed disables HTML caching by default, as typically HTML is dynamic. However, you can override that behavior.
There is a new option in the most recent binary release (0.10.21.*) that provides the behavior you want: explicitly control of your HTML caching headers:
ModPagespeedModifyCachingHeaders off
http://code.google.com/speed/page-speed/docs/install.html#ModifyCachingHeaders

Resources