robscott

Done and fixed!

See it work @ https://entwistles.net/glass-and-chrome-nest-of-tables/

Thanks for this Antonie – will pop a brief post up on our corporate website saying how awesome you are later today ??

Seriously, thanks for responding – I know it can be a pain when providing plugins for free when you get “complaints” like this, so thanks for sorting it out.

Rob

Hi Antonie,

Works perfectly for resizing the main picture – just not the thumbnails (which are still (not) loading from docroot):

e.g. https://entwistles.net/meredew-wardrobe-and-dressing-table/

But the fix works!

If this alters for thumbnails, will be cooking on gas.

Thanks for the update.

Rob

Hold on – in what way is this problem resolved?

Okay, since the issue is with TimThumb.php, and I can’t (from half an hours tinkering) find where I would change the file location that TimThumb.php uses in the plugin’s files, I’ve simply removed the resizing and thumbnailing features.

We would like to get them back, so a workaround would be appreciated! All we need to do is have TimThumb.php use a relative URL rather than the full docroot when calling the image. Just need to know where to alter that setting.

But we have slideshows working now at least, which is good.

You really should change the “hard embed code” as it means the slideshow disappears upon upgrade, which is why people click “broken” – because their slideshow “breaks” when they upgrade. Just a message in the plugin’s info in the manage plugins menu would be sufficient (“Note, after upgrading your plugin to 1.2, you should change your hard code php to…”).

My solution is not a fix – it is a workaround- the solution lies with using TimThumb slightly differently. For us. Probably others on shared hosting will experience similar issues.

Okay, I have narrowed this down a little.

The following link doesn’t work – will never work on this shared hosting setup:

https://entwistles.net/wp-content/plugins/slideshow-gallery/vendors/timthumb.php?src=/homepages/27/d380802910/htdocs/wp-content/uploads/2012/04/barbola-close2.jpg&w=100&h=75&q=100&a=t

However, the following does work:

https://entwistles.net/wp-content/plugins/slideshow-gallery/vendors/timthumb.php?src=/wp-content/uploads/2012/04/barbola-close2.jpg&w=100&h=75&q=100&a=t

How do I change the plugin to ask for the latter, rather than the former?

Sorry, I just went and had another look at this, and now I know what the problem is.

TimThumb is calling up a file that (on a shared host) it isn’t allowed to access – its “above” the file system of this client’s site.

We should be using “Web root” (“https://…”) instead of Doc root (“/homepages/27/d380802910/htdocs/…”) for this, which will require some tinkering in some files.

You may want to change this setup in the plugin itself – I’d imagine a lot of people on shared hosting will run into this issue?

On our server, this isn’t an issue – on this site (which I manage for a friend on shared hosting) it is – hence I couldn’t recreate elsewhere!

Otherwise, could you point me in the right direction of the files I’d want to change to swap doc root for web root and “allow external” in TimThumb.php (if you know the answer). I will otherwise just do it and post the answer up here later for all to see (and you to add – or not – as you see fit).

@antonie Potgieter

The images do exist.

Which permissions do I need to change to get TimThumb.php working? Have tried the directory the images are in, and the TimThumb.php file itself, to no avail.

Would roll this one back to the previous (1.1) version, though since I’ve implemented code changes, and this seems to be a bug with the plugin (I think) thought I’d leave it up for an hour or two and see if we could get a fix – the new version seems to have a lot of good fixes, so will help to make it better ??

Incidentally, running the query HALVED the size of my total database, so was worth looking into ??

Hope this helps somebody counter a lot of spam.

We’ve also turned off self registration – we don’t really need it, as we know the people who post for us.

Ok guys, as always, no answer, and I answer my own question before getting there, below is the SQL query.

Remember backup backup backup before doing this – you might break things, and don’t blame me if you do!

DELETE tr FROM wp_term_relationships tr
INNER JOIN wp_term_taxonomy tt ON (tr.term_taxonomy_id = tt.term_taxonomy_id)
WHERE tt.taxonomy != 'link_category'
AND tr.object_id NOT IN (SELECT ID FROM wp_posts);

Incidentally, if anyone is interested, I can post up the other SQL queries I used / created to help them get over this issue.

It cropped up because we use a front-end form to accept posts, so rarely fish around in the WordPress “Posts” menu except on routine maintenance. Our server is pretty hefty, so didn’t notice the 60,000+ “draft” posts sitting there…

But this is something that seems to have started automatically in about October 2011 – when, presumably, somebody worked out how to do this automatically to list to blogs taking guest posts.

We reverted user type to “subscriber” and deleted all rogue accounts also.

Okay, I have got a working hack for this now. I have added

<g:availability>in stock</g:availability>

Into the file “eshop/eshop-base-feed.php” for each. Obviously, it would be better if this were triggered by an “if in stock” statement, but we can just delete products that aren’t in stock. It actually wouldn’t be too hard to do the “if…” statement, but I don’t quite know which attribute to go off for this by looking ??

I also removed the “Payment Accepted” part as this is no longer supported by Google Merchant center.

I can put my hacked file up for you guys somewhere if you want a badly written workaround to download today ??

Sorry, correct info re availability is:

<g:availability>in stock</g:availability>

Can choose from:

‘in stock’
‘available for order’
‘out of stock’
‘preorder’

Basically, I want everything that is available to have the ‘in stock’ added to it – which file would I update to achieve this?

Yes, “availability” is required for Google Products. Pretty sure it only has to be <g:availability>yes</g:availability> which suggests that it should be able to hook directly off the “in stock” info.

If you can point me in the right direction, I can fix this – I’ve not yet delved into any files for this (set up an online shop for a friend at https://entwistles.net and am trying to get Google Products working for them!)

Needs fixing, as the error is keeping all the products out.

Several other “warnings” but they are not so important.

All help gratefully received!

It’s not a question of “deleting their blog” it is a question of deleting their user account. It’s not professional (for those of us who make money from sites which employ WordPress as a CMS in one way or another) to say, to an irate user (customer) “Hey, don’t complain about me not letting you remove your account, all you have to do is put in a fake email address and name and then remove any comments you may have added over the past few years.”

What they want is for you to say “your account has been removed, absolutely.” Which is all well and good, but, assuming that user has taken the decision to remove his or her account, wouldn’t it make sense to allow them to self-delete.

I would request this feature but for the limited application that it has for ordinary users – my point was simply that, as an answer to the enquiry, it wasn’t necessary to get defensive and say “I can’t see why you would want THAT” and instead simply either a) not answer, if you don’t know how to add this; or b) provide a useful explanation as to how user self-deletion might be achieved – or at least some kind of workaround.