How to clear SellerDeck HTML Cache?

[Jack_C]

Hi guys,

I recently changed some layouts and yet the page preview (and when I update) does not reflect the changes, unless I switch to the design tab which re-generates the preview, updating the layout.

I have 10,000 pages so I can't do this for every page, is there any way to force sellerdeck to see all the new changes without manually previewing every page in design mode?

Cheers,
Jack

[peblaco]

The preview folders are by default in ProgramData which is usually a hidden system folder, if you can't see it you can show hidden system folders, then you can try clearing the files inside the sub folders of "C:\ProgramData\SellerDeck 2013\Site1\". The sub folders are: DesignPreviewHTML, PreviewHTML, SiteHTML (contains files to be published to web so you may want to leave those, but if they are removed they are regenerated) and SitePreviewHTML.

[Jack_C]

Hi peblaco,

Sadly that was my first instinct and it has not changed anything, in fact loading pages in the preview window doesn't regenerate anything, no folders are created and it's still showing me cached pages which update if I flick to the design tab..

Very strange!

[Mike Hughes]

This may or may not help, but when directly populating the stock levels in the database I discovered that the on page HMTL display that depends on them wasn't being updated if sellerdeck was already open, even during an upload after the changes.

I found the quickest way to get sellerdeck to update everything was to just close it down and reopen it again. It only takes a few seconds (at least with around 1,500 pages)

Mike

[Jack_C]

Thanks Mike,

I've experienced that too as most of the work I do is in the database rather than using the SellerDeck interface, but in this case it was a simple design change within the SD interface which updated live in the preview pane when I clicked apply, but doesnt carry over to all the other pages on the site unless I view each and every one of them in design view first. I've tried shutting sellerdeck a few times with no results unfortunately.

The change is a colspan value on tables, which is generated by a $count++; certain cells above it, so all I can think is that the general content preview pane does not check for new php, only the design tab?

My last resort is going to be to reboot my machine.. But since this machine runs a lot of scripts that are depended on by others in the office, I have to wait until after hours to see if it helps.

Failing that I guess I will have to uninstall sellerdeck as it's clearly holding all the html somewhere no one knows about!

[NormanRouxel]

SellerDeck has always uploaded changes for the several hundred sites I've worked on.

If you're making changes via the Database then that may be skipping code that the SD UI runs.

Try looking at the FileInfo and FileList tables in the database. They have some date and MD5 fields. These are used to ensure that only changed pages upload. They were especially important when SD was a young system as we were mainly on dial-up then, so uploading only changed files was a real time-saver.

P.S. Don't overlook browser caching.

[Jack_C]

Thanks Norman,

I'm used to making sure that DB changes reflect within SD, but in this instance changes were made within the SD interface.

If there is a way to clear out the cache of the embedded IE platform within sellerdeck I would love to do that, but I don't see a way to do it!

[NormanRouxel]

As I said, I've never seen the problem you're reporting, so have never had to deal with it.

A nice point re the embedded IE's cache but I don't know where it's located or if it can be controlled.

You're posting this in SD 2013, and that's been out for some time now. If this was a common problem there would be many posts about it but I don't recall any.

[Jack_C]

I reproduced the same issue in SD11 too..

It seems to relate directly to PHP, like the php count is only working in design mode and not in content mode..

It's only a minor change, before I used to have a row with a <td colspan="7">title here</td>, and now because the table is no longer going to always be 7 cols wide, I have added a php counter to each table header so I can then echo the count for the colspan figure.

I'm going to try clear everything relating to Internet Explorer, to see if that helps. And failing that I'm going to have to do something drastic with the layout to force it to update.

[NormanRouxel]

There are known issues with ListIndex and ListCount. E.g. http://community.sellerdeck.com/show...=list+sequence - a V8 thread but the problem persists today.

[Jack_C]

Thanks Norman,

Really appreciate your efforts with this - sadly though, not the issue here.. I had an error with my original php count, and I fixed it - now it's all fine but the changes are only being reflected on the preview (and uploaded html) if I first view the page in Design view then flick back to content view, and that page will forever be fine after doing it once..
But I need for this to happen to every page without manually viewing each one in design view, even though it would just be a one-off - there are too many pages to do this on..

I've no idea where SellerDeck is storing these cached page files.. I've used cCleaner to wipe everything it can (including things associated with SellerDeck and IE), and still seeing cached pages. And I know they're cached because they load quickly.

[NormanRouxel]

Another (may not be your problem but SD PHP related) is that many PHP variables persist from product to product. So if something isn't being initialised or set, it may well contain the value it last had when a previous product was parsed.

Also, I've sometimes had to do the following to get ListCount as I've found it sometimes not set correctly. Lets say we want the listcount for Products - N.B. Pseudo code:

Block type=SectionEntireProductList
$listcount = <actinic:variable: name="ListIndex" />;
/Block

Computationally expensive but sometimes necessary.

There are many "gotcha's" in using SD's built-in PHP

[Jack_C]

Yeah I've experienced many of them lol.. I generally avoid using it, and often use <?php ?> (if isnotpreviewmode) and have my webserver set to parse PHP from .html files, so I get around most issues that way..

This strategy would work for this but ultimately I dont really want it looking totally messed up in sellerdeck, so I'm stuck to using SD's php.

Nonethtless it's not the issue here, it really is just some weird caching I can't get rid of.. running in Design mode just one time per page fixes the issue permanently - so I'm not really sure what options I have other than to totally delete selledeck and start from scratch with just the .mdb

[Mike Hughes]

So if the page isn't reflecting the result of the php calculation then have you considered adding a php write element to see if you can force the page to update after the php has run. It could be something really simple and would also allow you to debug the problem by seeing on the page whether it has run or not.

Something as simple as

<actinic:block php="true" >
echo "Hello";
</actinic:block>

placed somewhere on the page might do it.

Hmm. Except of course you're already echoing the Colspan figure. Maybe forcing a file import and display could do it. There should be someway of getting the page to update. I've never come across this problem where php hasn't run and updated the page before a site update.

[Mike Hughes]

I wonder if there's a problem with what you're doing.

The change is a colspan value on tables, which is generated by a $count++; certain cells above it,

When you talk about 'cells above it' what do you mean? And what is it you're actually counting? You're not trying to count something that can't be determined until the page has been created by sellerdeck are you?