JS variable loaded using wp_localize_script is no longer available

TL;DR: Call the wp_localize_script after registering/enqueuing the script you are localizing.

Recently (WP 4.1.4 / WP 4.2) my ajax scripts stopped working. I’ve noticed that it was caused by the fact that the variable for the ajax_url was undefined so for some reason it ws no longer loaded to the page.

The reason turned out to be that I was using wp_localize_script to load the ajax url variable for a script that was not yet registered and enqueued.

Seeing the codex now I noticed that they have added: “IMPORTANT! wp_localize_script() MUST be called after the script it’s being attached to has been registered using wp_register_script() or wp_enqueue_script()”. However I don’t remember this not working before and also it did work until now.

So mind to check every site you have made using WP ajax and following the good practices (to load the ajax url using wp_localize_scripts) if they are still working.

geeneric.com is live

We at Shtrak have been working lately on a WordPress and WooCommerce based platform for online shops.
You can create your eCommerce site for free on geeneric.com

Let me know what do you think about our service – I’m open to any ideas for improvement!

Error 500 on a WordPress after an intensive hacker attack

Last couple of days we’ve had a website that is actively under DDoS attack. At some point I’ve noticed that the attack have stopped (or at least my notifications for it from the security plugin we use – Better WP Security)

Opening the website I’ve noticed that it returned Error 500 so I started looking in the ploblem. Happily enough it was an easy thing to spot by the steps I used:

1. To check if it was an account-specific error or a general server error I opened other websites that were hosted on the same server. The other sites were working so it was a problem specificly for this hosting account.

2. To check if it was PHP/WP error or Apache error I tried to open a static html file. Opening the file failed so it was some Apache error.. (most probably .htaccess).

Looking through the .htaccess file the end of the file was wrong and had some part of the rewrite rules partially included after the End Of WordPress comment.

... #Normal .htaccess rules
# END WordPress

iteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

For some reason the last part, starting from ‘iteEngine on’ was added second time. It is highly possible that this was caused by Better WP Security when adding another IP to the blacklisted domains.

If you have any idea what exactly might cause this problem let me know in the comments 😉

P. S.: You can follow me on twitter – @ninarski

WordPress Empty Search Template

WordPress provides you with a nice and easy way to style the search page template using the search.php in your theme. However there is something that is relatively strange related to the searches in WordPress.

If somebody hits the search button without having the search field filled in it gives you the blog archieve template using the index.php. (this is when openinig example.com/?s=)

Solution to this problem is just to tell wordpress that it’s a search (so is_search becomes true) if the s parameter is set but is empty. This should happen on a hook before the posts are requested.

So in your functions.php you can simply put this code

/* Fix for empty search redirect to index.php */
function shtrakeu_fix_empty_search ($query){
  global $wp_query;
  if (isset($_GET['s']) && empty($_GET['s'])){
    $wp_query->is_search=true;
  }
  return $query;
}
add_action('pre_get_posts','shtrakeu_fix_empty_search');

Cheers and follow me on twitter @ninarski

Update to WooCommerce 2.0 and missing information for the product (in the front-end)

WooThemes released the new WooCommerce 2.0 recently and updating seems really charming with the new interface and other listed features.

However sometimes updating won’t be the best thing you can do if your theme is made for 1.6.

In non-technical words – if after the update some of the information is missing or is wrong when seeing it in the front-end this is most related to the theme.

The problem here is that many theme developers (even WooThemes themselves) are using the WC_Product to get the product’s data. The problem is that you can no longer create an instance of WC_Produc by post ID. This is probably related to the new function get_product() which I think is really poorly documented in their official docs for some thing to put in the new release information.

In my case for a theme made from WooThemes themselves I had:

//inside the loop
$_product = &new WC_Product( $loop->post->ID );

This would no longer work so I changed it to

$_product = get_product(  $loop->post->ID );

Which fixed it right away.

In my opinion it would be good if they could update their own existing themes to work with the new version insead of just not caring what their end-users would end up with.

WordCamp Sofia 2012

WordCamp Sofia 2012 is closing in (20th September) and I’m invited to talk about responsive design and WordPress (The talk is named Get Responsive in 30 minutes). If you plan to join me there you can write a comment about something you really want to hear in my talk.

Cheers!

Adding a new currency to WooCommerce

Seemed to me that adding a new currency to WooCommerce would be extremely easy and wide spread which turns out is not the case. I couldn’t find any filter in the filter list with the hooks and filters list.

Anyway I managed to find out that there are two filters for this: ‘woocommerce_currencies’  and ‘woocommerce_currency_symbol’. Adding the bulgarian currency for instance is as easy as:

add_filter( 'woocommerce_currencies', 'add_bgn_currency' );
function add_bgn_currency( $currencies ) {
 $currencies['BGN'] = __( 'Bulgarian lev', 'woocommerce' );
 return $currencies;
}
add_filter('woocommerce_currency_symbol', 'add_bgn_currency_symbol', 10, 2);
function add_bgn_currency_symbol( $currency_symbol, $currency ) {
 switch( $currency ) {
 case 'BGN': $currency_symbol = 'лв.'; break;
 }
 return $currency_symbol;
}

Note: All this code can be placed somewhere in your theme’s functions.php

The result is that now the currency is shown in the Currency list:

WooCommerce Currency Settings
WooCommerce Currency Settings

Anyway one problem still persists – the currency symbol position is totally unmanagable from a hook. It can be only set site-wide through the settings section of WooCommerce. It is also placed in a not-so-intuitive place:

WooCommerce Pricing Position
WooCommerce Pricing Position

This is how far I’ve got with the multilingual shop with WPML and WooCommerce. Still wondering how to make the symbol position to be currency-specific (and not be afraid to update the plugin afterwards). Maybe I’ll have to make it in JS in the end.

I’ll keep you posted! And follow this guy:


//

How to make your slider have multilingual support using qtranslate

If you have a multilingual site with slider which uses the featured images for slider images and you want to make it support different slide images depending on the language you might want to follow these simple steps (or you can hack it your way).

Problem one: WordPress doesn’t support multiple featured images.

Solution

  1. Get and install this plugin
  2. Add the following code to your theme (functions.php would be okay)
if (class_exists('MultiPostThumbnails')) {
  $type = 'slides_options';

  $thumb = new MultiPostThumbnails(array(
    'label' => 'Secondary Image',
    'id' => 'secondary-image',
    'post_type' => $type
    )
  );
}
add_image_size('nivo-secondary-image-thumbnail', 960, $nivo_h, true );

Here slides_options is the Custom Post Type which we use for the slider. If you’re not using custom post type for this you can simply change it to ‘post’.

Congrats! Your theme now supports multiple featured images. Hooray!

Now we have to make WordPress display the relevant image for the specific language.

For this purpose we use a function which determines if the default language of qtranslate is used or not and depending on this shows the featured or the secondary image.

function qtranslate_slide() {

 global $post, $q_config;

 $image_id = get_post_thumbnail_id();
 $language = qtrans_getLanguage();
 $upload_dir = wp_upload_dir();
 $image_data = wp_get_attachment_metadata($image_id);
 if ($q_config['default_language'] != $language) {
 if (class_exists('MultiPostThumbnails') && MultiPostThumbnails::has_post_thumbnail('slides_options', 'secondary-image')) :
 MultiPostThumbnails::the_post_thumbnail('slides_options', 'secondary-image', NULL, 'nivo-secondary-image-thumbnail');
 endif;
 }
 else {
   if (file_exists($upload_dir['basedir'].'/'.$image_data['file'])) {
   $image_url = wp_get_attachment_image_src($image_id,'full', true);
   return $image_url;
  }
 }
}

Now we have to change in our code where we display the images for the slider

$thumbnail = wp_get_attachment_image_src(some, arguments, here);

with our function

$thumbnail = qtranslate_slide();

And from now on we can use $thumbnail[0] as url for the relevant language, depending on the chosen language

Simple as this! Good luck!

P.S.: feel free to ask me something about that on twitter – 

!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=”//platform.twitter.com/widgets.js”;fjs.parentNode.insertBefore(js,fjs);}}(document,”script”,”twitter-wjs”);