[Old] Royal Mail Modules

I want to add another shipping part for special delivery on Saturday, which cost an extra £2.00 on top of normal SD price, ive copied the two files from SD and renamed them, uploaded them, but do i need to adjust the DB?

thanks

Andy

As i understand it, you want to offer the Special Delivery Saturday service, which would cost an extra £2 ?

This would be difficult as you would have to turn it on every Thursday after 5 o'clock and then turn it off on Friday at 5 o'clock. I think maybe you should just add a £2 extra handling charge during these times and change the define text. Creating a new module entirely is a little trickier than copying the files over. The problem with turning on and off something is that say, they want to order on a Friday but have it delivered to a work address on Monday ? then you're a bit stuffed unless you have a unique Saturday delivery module to turn on and off.

To create a special Saturday delivery module, you would have to copy the files across to new names, rename the class inside the include file to the new names of the files, change all of the constants in the include file (which go into the database) and then add £2 somehow to the rates, change the text in the new define file and then either turn it on and off on a Thursday/ Friday or write a bit of php to do it for you.

It's not impossible, it's very easy for a normal php programmer, it's just a bit time consuming.

Philip (the bloke wot wrote the modules).

Don't know what its call but could you use the rountine that allow you to run scripts at set times? This rountine could than run the script which turn on seperate special delivery by Sat and still keep the others after 5pm on Thursday and turn it off at 4pm Friday.

side note they will still try and deliver normal special delivery on Sat.

I think I will just leave it on and call it saturday only, im not a script writter, I can just about edit the pages to look like i want them ;-)

thanks for the options

Andy

iceburn:

Don't know what its call but could you use the rountine that allow you to run scripts at set times? This rountine could than run the script which turn on seperate special delivery by Sat and still keep the others after 5pm on Thursday and turn it off at 4pm Friday.

side note they will still try and deliver normal special delivery on Sat.

Yes it is possible as mentioned above, it would also only take a couple of hours if someone were familiar with the modules (that would be me). It would also require an override to test that it worked, or to display the option so that someone ordering from work on a Wednesday could get it delivered to their home address on Saturday. It also does depend on whether the server time is correct.

andy:

I think I will just leave it on and call it saturday only, im not a script writter, I can just about edit the pages to look like i want them ;-)

thanks for the options

Andy

we do not solicit on the forums

Hope you can help

Ive just added Taiwan to the zones and setup for no UK VAT, all this works ok, but when I check out on a test with an Taiwan address i get international signed for show up as expected, but also special delivery, but not special delivery 9.ooam

any ideas?

Andy

Have you added anything to the modules themselves ?

both of your international modules have TW already in, but cant see why SD comes up

Andy

andy:

both of your international modules have TW already in, but cant see why SD comes up

Andy

In the module code, it looks for a valid country, in the case of the british ones it is only configured to looked for things with a country code of GB, the only way for special delivery to come up, is if somehow you've got Taiwan somewhere attached to England, the problem is going to be finding the little sucker. Now how did you create the taiwanese address ? as a guest, as a logged in person ? if you were logged in, there is a possibility that a british account then changed to a taiwanese one would trigger the country code, but it's unlikely because it's only triggered special delivery. Now with special delivery, is it giving a price, does your special delivery 9am have any pricing limits that may cause it not to display ? as the modules are virtually identical. There is another option, in that your session could be corrupt, recently I diagnosed an error in the zencart database setup for storing sessions, but it still does not explain why only one british option would be showing.

bouncingltd:

we do not solicit on the forums

Righty ho, so I am imagining the donate button up there then ? so it's okay for me to write modules for zen cart, it's okay for me to correct your rather serious cock up with session storing in the database that's leading to hundreds of erroneous errors on any installation since 1.3.5, but it's not okay for me to suggest that I should be renumerated for my work ? instead you can ask for money and then remove my post. Okay then how about this, would anyone like to DONATE large sums of money to me then ?

I quit

the Taiwan address is a new acount to test with.

Had to put taiwan into zones

Zone definitions is
EU and rest of world

Tax classes is
with vat
without vat

rates are
0%
17.5%

Taiwan is in rest of world

i thought it might be to do with the above, but it checks out

Andy

Hi,

I'm having a problem upgrading to v2.11 from v1.1....

I have upated all the files as it said in the installation instructions (and run the SQL queries), however I can't get most of the shipping options to display.

I can install them ok in the Admin interface but there's something weird with the Minimum & Maximum Order Value boxes.... The boxes are there, but they are not titled... and if I put values in them, I can't save them - they're just blank every time.

I'm guessing the reason that the shipping options won't display on the front is because it thinks that my products aren't meeting the min order value.

Does anyone know how I can fix this problem?? I've tried deleting the module files and starting again but that doesn't work!

Cheers,
Oli

Oli,
I would suggest having a look at your SQL database in the configuration table. Sounds to me like the update did not go to plan, or you didn't run the 1.2-1.3 update. Each module should have a slew of RMAMSMALLPACKET_MIN_ORDERVALUE and similar defined.
Use phpmyadmin or your favourite SQL admin tool.
Rgds,

Hi,

I did run the update ok, but looking at the SQL in the update, it only adds the following configuration key:

MODULE_SHIPPING_RMAMSMALLPACKET_HIDE_SHIPPING_ERRORS

Noting to do with the Min/Max Value...

If someone would be able to send me exactly what entries I should have in the configuration table for all the shipping modules, then maybe I could just import them in??

Oli

Oli,
Those values are all added by the module install. If you look at one of the version 1.1 modules and compare it to version 2.11, or any version after 1.1, you will see that the install around line 254 or so in the version 2.11 incarnation, that min and max order value are inserted into the configuration table.
At a guess I'd say pick one installed Royal Mail module in Admin, explicitly remove it with the Remove button, immediately reinstall it with the Install button, and then edit it. That should create all the missing values automatically.

Hope that helps.

Rgds,

Hi,
I've just installed the royal mail module and if I load more than about 8 of the module options I get this error message on my page;

1064 You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXPECTED_PRODUCTS_SORT limit MAX_DISPLA
in:
[select p.products_id, pd.products_name, products_date_available as date_expected from zen_products p, zen_products_description pd where p.products_id = pd.products_id and p.products_status = 1 and pd.language_id = '1' and p.products_date_available >=20070212 order by EXPECTED_PRODUCTS_FIELD EXPECTED_PRODUCTS_SORT limit MAX_DISPLAY_UPCOMING_PRODUCTS]

Any ideas?

mike1969:

Hi,
I've just installed the royal mail module and if I load more than about 8 of the module options I get this error message on my page;

1064 You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXPECTED_PRODUCTS_SORT limit MAX_DISPLA
in:
[select p.products_id, pd.products_name, products_date_available as date_expected from zen_products p, zen_products_description pd where p.products_id = pd.products_id and p.products_status = 1 and pd.language_id = '1' and p.products_date_available >=20070212 order by EXPECTED_PRODUCTS_FIELD EXPECTED_PRODUCTS_SORT limit MAX_DISPLAY_UPCOMING_PRODUCTS]

Any ideas?

Looks like a common issue with this module - had it ourselves, had to reduce the number of options down to registered first class packet and same with insurance, along with standard parcels and the error went away - seems to be hit and miss with the number of options being enabled that the error appears.

Look at a couple of posts before this from bouncingltd more info, unless there is an updated module released I dont think there is any progress in resolving these issues unless you want to rewrite some code..

Philip discovered the cause of this problem and posted the solution in the 'Bug Reports' forum a while back:

http://www.zen-cart.com/forum/showthread.php?p=318018#post318018

Here's a copy of his post:

Affects versions 1.3.5 and above

For people that are using database caching, if the serialized session variable reaches 64Kb then the constants collapse throughout the site. This is commonly presented as a SQL error with something allong the lines of

error: check your sql syntax where EXPECTED_SORT_ORDER

this collapsed constant is not predictable as it depends on how zencart is configured and which constants are looked for first. The main cause is installing many shipping and payment modules so that the stored session variable is over 65k, which is leading to people saying "something's wrong with your module". Commonly the first time the site is visited, nothing will go wrong as the data is pulled from the database and then stored in the cache, the second time when the data is retrieved from the cache the site collapses.

The fix: The database db_cache should be created with the column cache_data as a mediumblob not as a blob for future version of zencart.

Current users of zencart can either change to to file based sessions or can upgrade their database manually by using the query

ALTER TABLE db_cache CHANGE COLUMN cache_data cache_data MEDIUMBLOB NOT NULL

This query should be run through either a mysql console or phpmyadmin. It should also be included in the upgrades from version 1.3.5 upwards.

Philip.

Is it possible to stop the shipping weights being shown to the customer? We have customers that will quibble if the parcel should be lighter than shown!