Messages

I think the sad aspect is finding a shopping cart system that doesn't work straight out of the box on all server platforms and having one's expectations, raised from the web site, not fully met.

The down side of switching to Unix, for me, is having to rewrite the parts of the site that use ASP instead of moving forward.

Before we get to that stage I did find something else  ..

Under System > Settings > Appearance > Template I found that the entry read "Template 2" despite the Extension not having installed properly (I used your built in install process) and having been deleted. Changing this to "Default" seems to have cured the problem and also cured the problem of some error messages refusing to depart this life despite several attempts to delete them via the System > Messages screen.

The only conclusion I can reach is that, on a windows server at least, installing extensions is a risky business; and uninstalling them even riskier. However, a brief bit of tinkering with the css files indicates I can customise the appearance of the shop site sufficiently and, by replacing graphic files, adjust the parts that the css doesn't reach.

Abantecart has said, in a different thread, that you don't 100% guarantee that the system will work in every respect on a windows server. I do think, in your own interests and that of your reputation, that you need to test the system yourselves on a windows platform by attempting all the system functions as a user and verifying they work. By doing this yourselves you will be able to dive 'behind the scenes' as necessary to resolve any issues that reveal and then include them in the next available upgrade.

Whilst I don't have time to do this for you I will be talking to my hosting company to see what is involved in putting this system in a HTTPS location and I will let you know of any more problems that surface. The 'clean installs' will then benefit form what I have learnt from the two threads I have so far started.

Thank you for your help.

Turned cache settings off as suggested. Noted there is a statement "Please be careful when disable caching. Cached pages will not be re-created and site might start loading slow."

Used FileZilla to delete the previous cached 100 files.

Created a new category 4. Despite the statement above that cached pages will not be re-created the system created 40 cache files!! Examination of the 'last modification' date shows that 22 of these were created currently and and 18 copied in from somewhere else - they had yesterday's date on them. Reloaded the shop front page and the new category was listed.

Created a new category 5. No change to the cached files. Reloaded the shop front page and Category 5 showed up immediately.

This seems to have resolved the problem of making freshly added categories visible but begs questions:

1. What value is there in having the cache at all.
2. If the shop becomes busy, how much does performance reduce with the cache turned off.
3. If the cache is disabled why are any cache files created at all.

I would appreciate answers to those points.

THE PROBLEM IS NOT FULLY SOLVED

With the cache files present I tried again to update the layout and a reload of the shop front page showed no change.
Emptied the cache (again) using FileZilla.
Reloaded the shop front page and this created two fresh cache files.
The changed display layout shows on the admin page but does not show up on the store front when reloaded.

So the problem that started this thread, the failure to make changes to the layout on the shop as initially reported, still remains even with all the cache files deleted.

Are the current layout settings kept in a different cache or file somewhere else and so that the updated layout information is not being read when the shop front is reloaded?

I have just used FileZilla to remove the 1033 files from the cache, leaving only the index.html file. Lo and behold, all the additional categories I had created have appeared in the shop front. Looking again in FileZilla - a fresh set of cache files has appeared, 101 in number.

Created a third test category. It doesn't show up in the shop front.

Are the cache files intended to be transient - and deleted by the system once the content has been used to generate the html delivered to the browser? If so, they are not disappearing / being emptied and are blocking the view-ability of subsequent edited information. They are flagged as read/write ok.

Oops, I should have checked by filetype. They're not all 136 etc filename extensions. But the filename extensions are all numeric and range from 1368871461 to 1369317255.

Setting to "777" doesn't work on Windows servers so all the settings have to be carried out via the Parallels Control Panel. It is that facility I have been using to initially set the permissions and then check they have not been changed.

I have just taken a look inside the System/Cache directory using FileZilla and it is full of files that include 1369317255 as the filename extension plus the index.html file placed there by the install process. Filedates vary from 17 May (when I installed) through to the current time. I then went to System > Cache, ticked all boxes and told it to clear the cache.

Looking again via FileZilla, no files seem to have been either deleted or changed. A further check using the Parallels panel shows the files to be flagged as read/write ok.

Is your php code trying to manipulate using a Unix style command (such as chmod) when handling the cache? Chmod doesn't work on a windows server.

I also took the trouble to check the content of three of the tables in the SQL database (using phpMyAdmin). Screen captures are attached. There are entries for all three categories that should be there - Category 1 placed there by the installer and the other two by me. This might help towards narrowing down the search for a solution.

When I changed System to read/write the process also changed the directories and files below it. The settings in System/Cache (and logs) do not allow me to change them once the higher level has changed. The 'ticks' against the permissions are present but greyed out as they have been inherited from System.

Have checked - it is set to English both for "Category 1" which was created by the installation program, and for "Test Category 1" which I added.

Have also created "Test Category 2" (language set to English) as this fails to appear on the shop front in either English or Spanish. And the server log doesn't show any POST commands to match saving anything at the relevant times when I saved the changes.

According to the install instructions the following should be set to 'read/write':
system/config.php
system/
system/cache/
system/logs/
image/
image/data/
image/thumbnails/
download/
I have checked again and these directories and files are all set to read/write.
Are there any other directories or files that should be set to read/write?

Fourth file of the set.

I'm not sure where, exactly, you are asking me to look so you may need to give more detail of where.

The installation instructions didn't mention any need to take any user action to install languages or language elements as both English and Spanish are installed by default.

Under admin > system > settings the language entries for both shop front and administration are set to English just as they were left set by the installation process.

The shop Front page url I am looking at finishes with "&language=en" which would appear to be correct. In case it is of any help I have attached the source code of the page delivered by the server itself for you. Whilst I have referred to it as 'source code' this is a bit of a misnomer as it is html generated by your system. The delivered html doesn't contain the words "content language switcher" although there is a switcher div present.

I have also attached the delivered html following a switch to Spanish (page url finishes with "&language=es"). Apart from the language differences one would expect, the various divs that should contain the details (such as the "main_content" div) contains only the header for the block when English is selected whereas in the Spanish the header is followed by the expected list of the relevant category or product entries.

Screen captures of what is visible on the shop front page are attached in case these are of any help. (the Spanish one follows due to the artificial constrain on attachment sizes!)

If you need me to look in any other settings please let me know.

I decided to explore a bit further - and see if there are any more clues to where the problem lies.

I added a category and a product to see if that part of the system would work. I was able to add them once the first reported issue had been resolved (see topic "Add Product" on the Fresh Installation board) by provision of a proper function instead of a call to unix one that doesn't exist on a windows server.

I then went to the Shop Front Home Page and expected to see the category that is automatically installed appear in the category box together with the category I created. I also expected the product to show up on the page. These expectations are not unreasonable. Neither appeared and the page stubbornly displayed the exact information it did when when first installed: category box no entries, no product on view. The product is, incidentally, flagged as 'featured' and failed to be shown there either.

As an experiment I changed the language setting from English to Spanish. Wow! - the product was displayed and the categories were listed and the product appeared in the featured panel. Change it back to English - and the entries all disappeared again.

This might give you a clue as to where to start looking for the solution to the problem of the system not working and your actions to solve the problem instead of nit-picking.

As for claims of 'no evidence' - read the above again and again. If the failure of the entered categories and products to appear on the shop front isn't clear evidence of a serious dysfunction then what is?

In order to satisfy myself that it is usable I require to customise the layout.

If the system is to be usable to me then all features need to work on my existing web site platform.

The fact remains that the problem prevents any use of the system.

If the problem is caused by 'third party' items, then you must assume responsibility for putting in calls to 'third party' systems that clearly aren't working.

Your final comment "nevermind" shows a cavalier attitude to potential users.

Are any of the support team really interested in solving this?

I thought I'd give matters another try - these errors appear in the Firefox error console.

There are quite a few, just a small selection in the attached file.