Bye Bye my-hacks.php?

Soon the new 2.8 version of WordPress will be released, but the hype is not as much as it was some years ago, when version 2.0 was released for example.

But the new version brings many new things, fixes a large number of problems and WordPress is in my view, more open than in the prior versions. One of the points that users should be aware of is the fact that the option for the support of the my-hacks.php removed. 2003 this file was announced as a feature, and now it’s going to be removed silently. WordPress has a sophisticated interface system, you can start at various points and bring in new functionality, so that the developer team decided that there is no longer need to support this solution. Alternatives and possibilities of further usage will briefly shown here.

Further usage of my-hacks.php

The file with its own extensions can still be used in 2.8, it only can’t be enabled via option in the backend anymore. If you want to do this, you have to set the entry hack_file in the table options on 1.
This is done either directly in the database, for example through phpMyAdmin, or via code:

update_option( 'hack_file', 1 );

Alternatively you can get the option via a Plugin back into the backend, see Post and Plugin download at Schurpsel.

The query of the file remains in the core and should remain so, also the query of the fields in the database should remain.

// Check for hacks file if the option is enabled
if ( get_option('hack_file') ) {
	if ( file_exists(ABSPATH . 'my-hacks.php') )
		require(ABSPATH . 'my-hacks.php');
}

To keep everything as it was, store the file in the root (ABSPATH) of the installation.

The idea to no longer support is obviously connected with considerations and because WordPress offers excellent interfaces. In addition, the file got pulled early and was therefore not always a clean solution as you know of other interfaces. A test for intolerance and problems is not possible and the file can also slow down the system.

Via Plugin

One of the interfaces is the Plugin interface, and therefore lends itself to that, to create a Plugin, to do small hacks. Either you learn how to do this, for example in my small tutorial how to write a Plugin or you use this template.

Just create a PHP file and insert the following syntax, then create your own hacks and copy the file in the Plugin directory. You only have to activate it in your backend.


Theme functions

The active theme can always bring their own functions, therefore it uses the file functions.php which can be added to each theme. The idea is to explicitly provide new functions for each theme. Therefore, you can store there your hacks, just write it in your functions.php of your theme, upload to the theme folder and you’re done.

Alternative language folder

A third possibility to carry out their own functions is the language folder, the default is the /wp-content/languages/ ; wp-content can be moved and renamed since version 2.5. If a language key is set in the wp-config.php , for example, en_US, then WordPress looks for a language file .mo – and a .php file and if exist, it will be used.

define ('WPLANG', 'de_DE');
/**
 * The locale of the blog
 * @since 1.5.0
 */
$locale = get_locale();
$locale_file = WP_LANG_DIR . "/$locale.php";
if ( is_readable($locale_file) )
	require_once($locale_file);

/**
 * Loads the theme's translated strings.
 *
 * If the current locale exists as a .mo file in the theme's root directory, it
 * will be included in the translated strings by the $domain.
 *
 * The .mo files must be named based on the locale exactly.
 *
 * @since 1.5.0
 *
 * @param string $domain Unique identifier for retrieving translated strings
 */
function load_theme_textdomain($domain, $path = false) {
	$locale = get_locale();

	$path = ( empty( $path ) ) ? get_template_directory() : $path;

	$mofile = "$path/$locale.mo";
	load_textdomain($domain, $mofile);
}

This should of course only be used for hacks and features, which has something to do with the language of the blog. Basically, you can also put functions there. This possibility is especially well suited to create language typical functions, such for a clean use of URLs in Permalinks (instead of u for ue ü etc.).

Comments

7 responses to “Bye Bye my-hacks.php?”

  1. Christopher Ross Avatar

    I have to admit that these days, on the rare occasions that I feel the need to hack WordPress I do it with either a custom plugin (my site had dozens, now just one) or I simply add the hacks to my functions file.

  2. johnbillion Avatar

    It’s worth pointing out that those sites that already have my-hacks.php support enabled will still be able to use my-hacks.php as the option will remain in their database. It’s just the settings interface checkbox that is disappearing.

    Nice coverage of all the alternatives.

  3. Frank Avatar

    Hello John,
    yes, only the checkbox is not supported, it is a problem for users to use this file if set a new install of WordPress.
    They can use these alternatives or an own idea.

  4. […] the usage behind my-hacks.php and its disappearance in 2.8 in terms of being an option to select. https://wpengineer.com/my-hacksphp/ All sites that used myhacks.php will still work considering it’s just a UI change. WPTavern […]

  5. […] Bye Bye my-hacks.php? – options , 1, Plugin, WordPress, This … […]

  6. Stephen R Avatar

    N 2.8 you can still use the my-hacks.php, sans settings, by putting it in a mu-plugins folder inside wp-content. That is:

    /wp-content/mu-plugins/my-hacks.php

    Doesn’t even need to be named my-hacks.php. Any PHP file in that folder will activate.

  7. Stephen R Avatar

    It appears that WP 2.8 has *added* support for MU plugins. So you can create a mu-plugins folder in wp-content and put PHP files in it, and they will be include()ed shortly before plugins are.

    I sure hope this isn’t a temporary thing. I have a system that requires me to do a couple things *before* plugins actually load, and this is pretty much the only way to do it….