Blog

Add a program to Send To context in Windows 8

With the move to Windows 7 and Windows 8, there are a number of new locations for folders that were very helpful and well known to support techs and SysAdmins. The Send To folder (where you could control what shows up in Explorer when you right clicked on an item and selected Send To) was one of these.

Unfortunately, for many, the location of this file is a mystery… Until now.

HowToGeek.com shows how to do this in two different ways.

One way is to run the following in a command window or Run box (WinKey + R):
shell:sendto

Simple and elegant, this should find the correct folder for the currently logged in user.

Alternatively, in a command window or Run box (WinKey + R) you can enter the following:
%UserProfile%\AppData\Roaming\Microsoft\Windows\SendTo

Just in case you needed to know…

Image of locks

Locked out of WordPress? Create new Admin Account via FTP

Have you ever found yourself locked out of your WordPress admin-level account and email recovery won’t work for you? Well, if you have FTP access, you can create a new account that will get you into the system and allow you to set things right.

By placing the following code into a plugin folder or adding it to the current theme’s functions.php file, a new user will be added to WordPress as soon as the next page is drawn on your site.

function add_admin_acct(){
$login = 'myacct1';
$passw = 'mypass1';
$email = 'myacct1@mydomain.com';

if ( !username_exists( $login ) && !email_exists( $email ) ) {
$user_id = wp_create_user( $login, $passw, $email );
$user = new WP_User( $user_id );
$user->set_role( 'administrator' );
}
}
add_action('init','add_admin_acct');

As you can imagine, this is pretty scary stuff so ensure that you remove these lines of code from your site as soon as you’ve been able to log into the site. Oh, and guard FTP access credentials to your site to ensure some bad guy doesn’t do the same thing to get access to YOUR site. That means no more FTP while on WiFi at Starbucks or other public hotspot unless you are running over a VPN to secure your connections!

Tip found on Stephanis.info.
Image © Copyright RAY JONES and licensed for reuse under this Creative Commons Licence

Did You Know: Bootstrap Grid Breakpoints

One of the nice things about Bootstrap is it’s grid system and how it can be leveraged to do some pretty cool things as you move from device to device. Aside from knowing that the standard measure is for 12 columns wide, it is also important to know what the breakpoints are for each size.
Bootstrap uses 4 different classes to accomplish this.

  • Extra Small has a breakpoint for displays of less than 768px (many/most phones in portrait mode)
  • Small has a breakpoint between 768px and 991px (appropriate for most tablets)
  • Medium has a breakpoint between 992px and 1199px (laptops and desktops with small screens)
  • Large has a breakpoint greater than 1200px (suitable for the modern laptop or desktop)

If you don’t apply a breakpoint to a column,then the default behavior is to stack the columns.
You can use multiple breakpoint classes in a div so that you can have different behaviors for different sized screens but just remember, the lowest appropriate breakpoint is going to win.

Custom Redirects in .htaccess Disappearing from WordPress Site?

A number of WordPress that we manage have been “losing” the custom 301 directives that we or our clients have been putting into the .htaccess file. This has been a very random and disconcerting issue.

Recently, we discovered that this was happening whenever someone saved the Permalinks Settings in WordPress.

Alternative solution? Make the file read-only until you need to edit it again. Or at least set up the permissions so that the webserver can’t overwrite the file. Problem solved…

In most cases this means setting the permissions on this file to 660 or 644 as described in this Codex article.

Tracking Session Variables in WordPress

Recently, a discussion came up about some new feature that will need to be added to a client website and it quickly became clear that we need to track the some variables in the session state. Now, I had always been told that WordPress, in trying to present a stateless solution, didn’t support tracking sessions variables without custom cookies.

Well after a little Googling (thank you Larry and Sergey) i found the following article on Session Variables in WordPress and it has a very elegant and simple solution to the problem.

Just add the following code to your theme’s function.php and you are good to go:
function THEMENAME_init_session()
{
session_start();
}
add_action('init', 'THEMENAME_init_session', 1);

This is exactly what I needed so now we’ll be able to store and access $_SESSION[] variables.

Program Compatibility Mode Interferes with Visual Studio 2013 Update 3 Install

I ran into some interesting issues with Visual Studio and figured in order to quash this bug I should make sure that all my plugins/extensions were all up to date. In doing so, I discovered that I was missing VS2013 Update 3. How could that happen? Well, I clicked the button to update and it downloaded a copy of VS2013.3.exe via Chrome (my default browser).
Upon clicking on the downloaded file, I was greeted by the following error:
vsfail
Searching for the error “Windows Compatibility mode is on. Turn it off and then try Setup again.” returned quite a bit of wasted time investigating and trying possible solutions. Most involved setting up compatibility settings for an uninstaller, not an installer.
Well, out of frustration, rather than launching the executable from within the browser, I tried to run it directly from downloads folder (first using “Run As Administrator” and then, to check, just opening it via normal click) and voila, problem solved..
voila
Hopefully this will help some other programmer from wasting a good deal of time trying to figure this one out. Not sure WHY it happened this way but this is a quick and easy fix.

Moving Drupal 7 to WordPress 3.3

Having to move data from Drupal 7 to WordPress 3.x is not as easy as I had hoped it would be. Initially found a plugin that didn’t work. Then found a project on GitHub but it was for Drupal 5 or Drupal 6 (not sure really) but the jump to 7 comes with enough schema changes that the above wasn’t going to work.

While not a perfect script, this certainly did give me the ability to move articles/posts/pages from a Drupal 7 site to a current WordPress site. You’ll find the original article at http://fuzzythinking.davidmullens.com/content/moving-from-drupal-7-to-wordpress-3-3/

I made some changes here and there to accommodate the vagaries of the original database I was working with and to correct the types of quote marks used for data fields but other than that, it worked pretty well. If you need access to it, here’s the details (in case his original post disappears):

AS ALWAYS, BACK UP YOUR DATABASES FIRST!

#Run these in blocks and remember to change wordpress to the name of your wordpress
#database/schema and drupal to the name of your drupal database/schema.
#
# Block 1
# TAGS
# Using REPLACE prevents script from breaking if Drupal contains duplicate terms.
REPLACE INTO wordpress.wp_terms
(term_id, `name`, slug, term_group)
SELECT DISTINCT
d.tid, d.name, REPLACE(LOWER(d.name), ' ', '_'), 0
FROM drupal.taxonomy_term_data d
INNER JOIN drupal.taxonomy_term_hierarchy h
USING(tid)
# INNER JOIN drupal.term_node n
# USING(tid)
WHERE (1
# This helps eliminate spam tags from import; uncomment if necessary.
# AND LENGTH(d.name) < 50 ) ; INSERT INTO wordpress.wp_term_taxonomy (term_id, taxonomy, description, parent) SELECT DISTINCT d.tid `term_id`, ‘post_tag’ `taxonomy`, d.description `description`, h.parent `parent` FROM drupal.taxonomy_term_data d INNER JOIN drupal.taxonomy_term_hierarchy h USING(tid) # INNER JOIN drupal.term_node n # USING(tid) WHERE (1 # This helps eliminate spam tags from import; uncomment if necessary. # AND LENGTH(d.name) < 50 ) ; #Block 2 INSERT INTO wordpress.wp_posts (id, post_author, post_date, post_content, post_title, post_excerpt, post_name, post_modified, post_type, `post_status`) SELECT DISTINCT n.nid `id`, n.uid `post_author`, FROM_UNIXTIME(n.created) `post_date`, r.body_value `post_content`, n.title `post_title`, r.body_summary `post_excerpt`, n.type `post_type`, r.entity_id `rid`, <- There is an issue here. Haven’t had a chance to fix this yet. IF(n.status = 1, 'publish', 'private') `post_status` FROM drupal.node n, drupal.field_data_body r WHERE n.vid = r.entity_id ; #Block 3 # POST/TAG RELATIONSHIPS INSERT INTO wordpress.wp_term_relationships (object_id, term_taxonomy_id) SELECT DISTINCT nid, tid FROM drupal.term_node ; #Block 4 # Update tag counts. UPDATE wordpress.wp_term_taxonomy tt SET `count` = ( SELECT COUNT(tr.object_id) FROM wordpress.wp_term_relationships tr WHERE tr.term_taxonomy_id = tt.term_taxonomy_id ) ;

In my case, I ended up not running the taxonomy or the comments commands as we didn't have any comments to worry about and the taxonomy failed hard.

Either way, thanks to the writer at this blog post for pointing me in the right direction so I could stop wasteing time getting this data converted.