Patch for Service Links – Failed: PDOException: SQLSTATE[42S22]: – and a good example of patch syntax

Drupal patches can be a pain. I usually just apply them manually because the line numbers don’t always line up (various reasons) and that way I get to look at the code. But this patch was fairly complicated and the error occurs at update.php so I didn’t want to mess around with it. Here is some detail about the error, and the syntax needed to install the patch using the patch shell command.

Upon a standard upgrade to the Service Links module, I encountered a known error during the update.php section, where the db is upgraded to add some elements to the schema.

The following updates returned messages

service_links module

Update #6200
Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘service_links_show_’ in ‘where clause’: SELECT name FROM {variable} v WHERE LOCATE(“service_links_show_”,v.name) > 0; Array ( ) in service_links_update_6200() (line 46 of /var/www/html/sites/all/modules/service_links/service_links.install).

Here is a link to the fix: https://drupal.org/node/2015967

This is the exact syntax that was provided:

patch service_links.install drupal7-service_links-2.2-update_1.patch

from within the service_links folder

Views Upgrade and subsequent patch

Well, to my chagrin (AGAIN) I have had to patch the Views module after a routine upgrade. This time was better than the last but it still wasn’t fun.

You have to patch the views.aggregator.inc file. you can read earlier posts about this to get some of the additional details.

this is before:

// ———————————————————————-
// Aggregator category feed table

$data[‘aggregator_category_feed’][‘table’][‘join’] = array(
‘aggregator_item’ => array(
‘left_field’ => ‘fid’,
‘field’ => ‘fid’,
),
);

// ———————————————————————-
// Aggregator category table

$data[‘aggregator_category’][‘table’][‘group’] = t(‘Aggregator category’);

$data[‘aggregator_category’][‘table’][‘join’] = array(
‘aggregator_item’ => array(
// ‘left_table’ => ‘aggregator_category_feed’,
‘left_table’ => ‘aggregator_category_item’,
‘left_field’ => ‘cid’,
‘field’ => ‘cid’,
),
);

And this is after:

// ———————————————————————-
// Aggregator category feed table

$data[‘aggregator_category_item’][‘table’][‘join’] = array(
‘aggregator_item’ => array(
‘left_field’ => ‘iid’,
‘field’ => ‘iid’,
),
);
//
//
//

//
// ———————————————————————-
// Aggregator category table

$data[‘aggregator_category’][‘table’][‘group’] = t(‘Aggregator category’);

$data[‘aggregator_category’][‘table’][‘join’] = array(
‘aggregator_item’ => array(
// ‘left_table’ => ‘aggregator_category_feed’,
‘left_table’ => ‘aggregator_category_item’,
‘left_field’ => ‘cid’,
‘field’ => ‘cid’,

CKEditor could not be detected – resolution

Well, I had trouble installing the CKEditor so I went with TinyMCE. But I began to get errors from that as well. And I don’t really like using a solution because I didn’t take the time to figure out what was wrong. So I went back and made CKEditor work. There is a patch for those of you using WYSIWYG 7.x-2.0 and CKEDITOR 7.x. You may receive an error that CKEditor cannot be detected.  This fixed it for me in sand and prod.

http://drupal.org/node/1161738#comment-6814058

Here’s another Patch

Posted by sakseiw on December 5, 2012 at 1:50pm

In …/modules/wysiwyg/editors/ckeditor.inc change line from function wysiwyg_ckeditor_version($editor)

if (preg_match(‘@version:'(?:CKEditor )?([d.]+)(?:.+revision:'([d]+))?@’, $line, $version)) {

to

if (preg_match(‘@version:”(?:CKEditor )?([d.]+)(?:.+revision:”([d]+))?@’, $line, $version)) {

This changes version number search from single quotes version: ‘4.0’ to double quotes version “4.0”

It worked for me on Drupal 7.17 and wysiwyg 7.x-2.2

Error with the Core Contact Form and Google Analytics Tokenizer

well, today I enabled the user contact form and tested it. The form works but I received an error from PHP about a deprecated function. Here is the link to the fix:

http://drupal.org/node/1198504

To be honest, I’ve had more luck installing these patches manually than using the patch application from the command line. I might be doing something wrong but I don’t think so. I believe that what is happening is that the patch is issued for a version of the module, at a specific line number. Then, the module is changed and the line number changes but the patch isn’t necessarily committed to the module. So the line numbers no long match. Or, I am an idiot who doesn’t know what he is doing.

So i usually open the patch, check out what is being changed and add it manually with Aptana. that way i have to look at the code too.

Aggregator categories, Views, Feeds, Panels and a solution

I am very happy today. I finally found a solution to the issue that I was having with Views and Aggregator items from the core mod. Aggregator is core, Views is contrib so this patch doesn’t involve hacking the core but be aware that an updated version of Views might break this again. I’m on Views 7.x.3.5

Here is the issue.

In Views, you can create a view for Aggregator items. But even though Categories is listed as an available field to add/filter against, it is not available unless the category field is used as the default category for that feed. when you go through the items and categorize them manually, that assigned category won’t show up in the View. this patch fixes that.

http://drupal.org/node/498438#comment-7063554

This is what I have. 20 RSS feeds from news sources all over the state. This is a catch all and I am only interested in certain stories. So, I have categories created to group the stories that I want together, regardless of the source. Every item that comes in has a default category of New. That way, I can see all new items together for categorization. This all works. It’s a pain, I have to look at about 40-50 items per day and categorize each one. But it is a big deal because I am dealing with a focused target audience. A niche. And stories that deal with their situation are import and need to be easy to get to.

So, I also need the power of Views. Views gives me much better presentation options when used by Panels than the Blocks interface does. Blocks is clunky and Panels is much better. And Views integrates well with Panels.

Now, you might ask, “why not use the Feeds Module?” well, i did. for hours and hours. and while it will do what I want, it is much more difficult for me (AT MY PRESENT LEVEL OF UNDERSTANDING*) to edit, categorize and tag individual nodes created by Feeds for each new news item. That takes a lot longer. And until I can write a module that does autotagging the way that will work for my type of content, I need to be able to use the Aggregator categories they way they are intended.

So, I implemented the patch. And it does work. I had to do it manually because code has been added since the patch was written to the Views mod and the line numbers are different. But it is really short. I’m on Views 7.x.3.5, Core 7.19. The patch goes into the modules/aggregator.views.inc file within the Views folder.

If you want to see why Views doesn’t work properly with Aggregator ietms read the post. the explanation is in there. This was a really frustrating experience but like all of those types of experiences, I am better off for it.

Error from CTools in Panels during preview

I got a bunch of errors from the preview feature of panels via page manager.

go to the ctool module dir from a terminal window and type –

curl http://drupal.org/files/1739718-fix-block-warning.patch | git apply

i had to install git to make this work (yum install git) and i received an error about an unexpected difference in file sizes but it looks like the patch worked. known issue. i wanted to document it because i’ll probably have to put this into prod as well as sand.