View Full Version : HP v1 Issues - thumnbails missing etc..

03-18-2009, 03:51 PM
Hi all,
Does anyone else have the problem of the property photos not keeping their order? If so has anyone fixed this issue? Basically they randomly change order it seems, leaving no photo in position 0 First, which means there's no featured property thumbnail to show.

Also, in Firefox, HP admin behaves, but in IE7, it times out consistently. Anyone else experiencing this?

Thanks.. Driving me mental!


10-20-2009, 04:30 PM
Photos are driving me nuts, too! I just removed a pic from a featured property, added it again, ordered it to 0 to make it display and ALL the other featured properties lost THEIR 0 position photos!!!!
What the hell is THAT all about?

10-21-2009, 07:59 PM
@andrewdferguson, stephenarmitage

Have you updated to 1.0b5?

11-13-2009, 07:10 PM
I updated to V1.05b and it's problems far out weighed the image problems in 1.04b.

Can we find a fix for the images in 1.04b?

11-14-2009, 09:35 AM
Hi, got the same problem here.

I'm on 1.05b, never had 1.04.

I upload the whole table with the ordering set for 1000 photos direct into mysql, all works fine.

Then if I go into My Items in the frontend and remove one item, the ordering for ALL the photos changes.

Instead of each photo having order value 1,2,3 etc, then order column just runs from 1 to 1000 through all items.

I made a custom search plugin which uses the order field to bring up the photo so my sql has 'AND ordering=1' to bring up the first image per property returned, however this is now broken due to the ordering never being 1 (except for the first photo in the table).

Initially it looks as though the order is still kind of there - item 235 with photos 359, 360 and 361 should have order 1, 2, 3, but instead it has changed order to 359,360,361 so I think I can get round it temporarily by changing my query to pick the minimum instead of picking '1', but without more testing I can't confirm it's this simple, all my items have been put directly into the database and it's not been let loose with users yet.

Apart from this I've not personally noticed any other bugs with how I intend to use the component.

Whatever is triggered when you perform an admin task on your properties is messing with the order without the need to, hopefully it's something simple to sort out.

the order isn't changing to 356, 360, 361, it's changing to more like 125, 456, 753. So before the change all my photos have 1,2,3,4 etc, but after the change then all photos with ordering '1' are being put first (order pos. 1-320), then all photos with order '2' next (order pos. 321-543), and so on.

My guess is that the bit that deals with the ordering is not taking into account the different property id numbers when doing it's sort/renumber. Which file takes care of that?

11-14-2009, 11:41 AM
Narrowed it down a bit, the photo order is only messed up when a property is removed, or a picture is removed from within a property.

Editing the product, moving the photos around and then saving it resets the order to correct values, but of course I can't do that every time a user removes a picture.

It seems like the reorder() function works fine when editing/adding a product, but when it's called from the generic remove function it disregards the different properties and sorts them all as one in the hp_photos table.

Doing this stops the problem:

comment out line 644 in plugins/mosets/framework/libraries/mosets/database/table.php

// parent::reorder(); // Reorder the whole table to "fill the gaps"

Now removing a photo or property leaves the photo order column as it was before.

I figure this will cause problems still if the user removes photo with order position 1 (for my search plugin anyway), but it's a smaller problem to work with for now.

EDIT: It doesn't cause any problems as far as my site is concerned - if you remove a single photo then you must be in the Edit Property page, and pressing Save to exit performs a property specific reorder anyway which is fine.

If you remove the property then there's no need to reorder so nothing is missed out. I can't see any major reason why that line of code was there in the first place, must be a reason but for my needs I'm not missing it.

11-18-2009, 12:09 AM
@ Padder

Any idea where that line would appear in the 1.04b version of HP?

I don't have a mosets folder within the plugins of my site.

11-18-2009, 02:21 AM
Sorry I moved from 0.98 straight to 1.05, only realised they'd done a 1.5 version a few weeks ago so missed out on 1.04.

When I need to find bits I open the original install file (like com_hotproperty.zip or whatever it was called) in WinRAR as it's got the feature to 'find' strings in the zipfile. Enter something unique to this issue, like maybe 'reorder()' or 'remove' (the function it's within on 1.05) and you get a list of files which contain the string, gives you a good place to start looking.

I don't think winZip has the 'find' feature, not sure with 7zip/gzip etc, but it's definately there in winRar. I'm sure there are trial versions out there somewhere.

02-01-2010, 07:15 PM
@andrewdferguson, stephenarmitage

Have you updated to 1.0b5?
How to update to 1.0b5?

02-01-2010, 08:01 PM
Whatever you do, DO NOT update to RC1!!!