I just completed the code changes to cw-func-mail.php that
will send a "Responsive Email" with no media queries
controlling the flow. I thought coding a "Responsive Site"
was a pain. It was nothing compared to trying to do an email. And
then you throw in High Resolution Displays with Outlook and you have
a situation that so far, for which I have been unable to find a fix.
(The logo appears at half this size on my 4k display in Outlook
2013. If I fix for the 4k, the logo appears at twice this size in
Outlook 2007, 2010 and 2013 in my Litmus tests and the header
"Payment Confirmation" appears below the logo, which it
is supposed to do only for mobile.) Given that Hi-Res Displays for
PC are just coming out, I'll keep searching for a fix.
I'm looking forward to CW Version 5 so I can see how CW
staff implements a "Responsive Design". After going
through the above I would have done things a lot differently in my
On a personal note:
I am almost to the point of concluding that the days of a
non-professional putting up their own website are numbered. I look
back over the last three years that I have spent on my site and add up
the costs and I could have easily hired a professional designer.
Furthermore, with all the "hacks" you read about, it is
becoming a security nightmare. I have spent an enormous amount of time
just trying to learn, understand and implement as much security as I
can figure out. But, how much do I NOT know and what will be the next
This may not be PC, but I'd like to go back and hang
whomever started the "... designer/developers must be
responsible for getting their sites to work in IE...". Imagine
the billions of man-hours over the years spent on trying to get
sites to work properly in IE. Now I understand the frustrations with
Outlook, add even more billions of man-hours spent trying to get
emails to work properly in Outlook. Way to go Microsoft, NOT!
Back to the email. For all who have taken the time to learn HTML
best practices, congratulations. Now set all of that aside if you want
to develop a "Responsive Email". Go back to the days of
layout using tables. That's right. You have to use HTML tables to
layout the email and use inline styles NOT internal (IE the
"style" tags in the head but style blocks on each element).
Seems there is NO specification for HTML emails. There is one for
text. So as one person on a site put it. "..You thought coding
for browsers was the Wild West, well HTML coding for emails, is a
JUNGLE...". Though I reference Outlook's shortcomings in the
previous paragraph, it is by no means alone.
This is rather difficult to say, but it must be said at some point, so
now is as good a time as any. CW4 will be the last ColdFusion version
of Cartweaver. We are working on a fully responsive CW5 and it will be
even easier to implement and more "universal" than CW4 but it
will be PHP only.
This is really hard for me to say because I've been a fan and big
supporter of CF since the Allaire days. When Macromedia had CF it was a
time of great strides forward, after Adobe took the rains it looked ok
for a while, but they started taking it more and more to the enterprise
level and they were less interested in the web community in general,
esspecially shared hosting environments, but there was hope with Railo,
but that stalled, then the dev staff jumped ship and formed Lucee, then
they decided to develop a Lucee centric branch while "still
All the while the development community has continued to shrink.
At some point you have to make a decision based on business and not
emotion, and even though I still REALLY like CF as a dev platform, there
just isn't the justification to allocate the resources necessary to
keep up with such a shifting and shrinking platform.
So when CW5 is released we will offer very good incentives to our CF
users to get the php version, which works out well because most develop
in both now anyway.
I know this is not good news to some, but it's what the market has
dictated. Hope you can understand, and please feel free to ask me any
questions you may have.
I had problems with my site sending emails as well. I did a search
on my hosting company for the PHP Mail Function and came across a
support article that stated "...PHP mail function is enabled on
all our servers. Since our servers use Linux, they use
'sendmail'. You can run a phpinfo and you should have a valid
location for 'sendmail_path'...." My search terms -
"InMotion Hosting PHP Mail Function". Substitute your
hosting company name and see if you come across an article or contact
Even after I determined that the PHP Mail function was enabled, I
had to make some changes to CW code to get the emails to go through.
The changes I made are referenced in my response to this thread. I cannot help much with the DKIM or SPF,
again I used support articles to configure them. Your hosting company
should be able to assist.
I've had a number of emails back and forth with your tech. For
everyone's benefit here's what i was able to tell him. There is
a known "issue" with CF11 - it is, for whatever reason Adobe
decided to have Session Variables turned off, rather than on by default.
Makes little scene to most why they would choose to do this since so
many CF sites use Sessions, but they did. All it takes is going into the
CF admin and enabling Sessions and you should be good to go. This is the
only issue being experienced by our general user community with the
current release of Cartweaver and CF11. After doing this your tech
explained that they were still experiencing an error, but did not have
details as to what exactly the error was, it also came to light that you
are self-hosting this site and administrating the server yourselves. I
told him to enable robust debugging, both in the Cartweaver admin and
the CF11 admin dashboard, this should provide full details on what was
going on. After this he said the error was a Java Permissions issue...
At this point, understandably we had to bow out. This is way beyond what
we can offer as free support as the issues are clearly server based and
not application based, after all your site has been working without
problems for three or four years, until you updated your server. I
understand your frustration, but hopefully you and everyone can see that
we cannot offer server set up and maintenance support, for free, on a
application that you bought four years ago, and has been working since
now. I recommended to your tech that he contact Adobe for support, or if
you like I can refer you to some good contractors that can help you
trouble shoot your setup. I'm always willing to help as much as I
can, and I hope you can sort things out soon.
The easy answer is sure if you really know your SQL and database
structure you can write a more automated way to update, ad, or archive
products. As Oli stated deleting them is a bad idea, unless you check
and are sure there has never been an order for the particular product
you are deleting. Generally it a bad idea though.
The other answer to your question is, this would be an "enter
at your own risk" proposition. This is definitely outside of what
we can reasonably offer support for. So proceed with caution and back
up everything before trying.
You'd need to do some handcoding . Best starting point:
\cw4\admin\cwadminapp\func\cw-func-adminqueries.php ( it has all the
admin side SQL queries for you to take a look at).
If you don't feel you have the necessary coding skills to perform
the desired modifications you could post a request to our web forums at
http://forums.cartweaver.com where there are a number of developers that
offer this sort of service.
First things first ... before you delete anything ... make a backup !!
Just to make sure you can revert the situation in case you delete
something that was actually needed.
Theoretically you only need one cw4 folder.. ( however, you may have
built your site and using two folders .. impossible to say if both are
needed without seeing the actual files (check your site files, and see
where the CW4 includes point to .. so as to know which folder is in use.
When migrating from/to any cart ... the database table will not match
.. since each system will use it's own structure.
Depending on how many products you have it may be convenient to just
enter them again .
If you want to migrate such data .. you would need to export the
information to a format you can handle (for instance Excel files) and
then adjust it to fit the needs of the new system.
I just found it much easier to zero in on actual HTML errors
(IE duplicate IDs and such) without having to scroll past all the
warnings for the ampersands. I have three navigation blocks containing
the products and the warnings were quite numerous.
Cartweaver 4 contains logic that can be used to build your menu
including your static pages and, in limited configurations, apply a
class="currrentLink" to the appropriate navigation link.
Whether you use the "Free Template" or not, the logic is
in the core code. See "Cartweaver Global Settings in text form" to
see if the currentLink logic works on your configuration.
There is another topic "Adding static pages to dynamic menus" which
shows various methods used to create a menu. Casey, Mick and myself
posted ways a menu could be generated, but, they all involved changes
to the core code. Unfortunately, at the time, none of us were
"experts" with the menu code in Cartweaver. Much later I
posted some edits to provide what I knew about the menu logic and
"append_links" and "prepend_links". But, I
recently discovered what I posted still wasn't quite right.
This post is to clear up my mistakes and provide you with
necessary instructions to use the menu logic without having to go
through that entire topic.
First, there are some limitations:
1. All of your categories will be on the menu bar.
2. The logic to apply
'class="currentLink"' does not work for all configurations.
3. The "Group Code" used in
"append_links" and "prepend_links" can not be
the same as a "Category ID" nor can the same code appear
in both "Append_Links" and "Prepend_Links".
4. In the "append_links" and
"prepend_links" you can only have one sub-level. In order
to get that sub-level, the links must immediately follow the top
level and have the same "Group Code".
If you want your static page links to come before your
product use "prepend_links". If you want the links to
come after your product use "append_links". Where you
place them in the "$module_settings" array and the order
in which you place them does not matter.
The syntax for "append_links" and
"prepend_links", when Cartweaver is installed at the root, is:
The syntax explained:
Group Code = 500 You can also use letters
here A, B, C...
Link Component Separator = | (pipe)
URL = index.php
Link Component Separator = |
Link Name = Home
Link Delimiter = ^ (carat) Not needed on the
1. Showing just the "$module_settings array" using
Cartweaver with the Free Template having Home, Clothing, Electronics,
Housewares, Lawn & Garden, About and Account on the menu bar:
I was testing the CW "currentLink" logic against
various server configurations and I documented the configurations I
used. Since the blog post on Global Settings frequently does not
display the images, I am posting the configurations here in text
Those with the green background are the recommended way
to configure your HOST and your Local Development Environment
(XAMPP, WAMP, or MAMP). The other Local Development Environment
configurations should only be used if you have a need to use them.
They each reflect the changes you will have to make should you
upload from them to your HOST.
Your configuration should be correct, if when checking
your images you see the following graphic:
CW Base files without the template:
Bring up the root index.php
file in your browser, click the "Search"
button. You will be redirected to the productlist
page with the graphic below showing for the products.
CW with Template:
Bring up the root index.php file in your
browser, all the featured products should show the
In either case, you will not see the images visible in
the online CW demo.
Note that the Site URLs below all use the"www."
prefix. If you do not plan on using it, input your Site URL
you must decide which way you will present
your site, with or without the "www." prefix
and either use your ".htaccess" or httpd-conf file
to redirect. See this topic for details.
Oli posts the htaccess solution near the bottom.
These configurations were tested using a XAMPP
installation at the root (C:\xampp), with the web sites
contained in C:\xampp\htdocs.
CW staff states
that this configuration works for some servers. I am
not familiar with this set-up and am unable to test it. I
include it for completeness. If anyone is using this
configuration and could explain what necessitates this
configuration feel free to comment.
Cartweaver installed at the site root:
Settings and Local Dev Environment (I.E. XAMPP) using