I applied Step 2 (edit DBmanager.php) in include/database at line 256
So far so good but I’ll let you know if anything goes wrong. For now, I have to say I’m relieved as I had a lot of pressure on me to get it to work ! So thank you guys 
!
Actually, I was a bit too optimistic. It fixed the issues I had with email campaigns (ie. blank page at step4) but I still have the same issue with the postal campaign ie. generating a link to a PDF document.
Generating links for PDF docs works on my local Ubuntu (PHP7.08 and MySQL 5.7) but campaigns won’t. (Haven’t applied the fix locally yet)
On my remote host (OVH servers), Neither campaigns nor generating documents worked till about 2 hours ago. Now Email campaigns work after I applied the fix but generating links to pdf docs still does not work, which somehow tends to prove both issues are not related.
And by the way, I still get a blank screen for email campaigns but at step-5 and it seems to work anyway.
Kindly check if implementing the STEP -1 works, for removing the blank page, when you click on NEXT after completing the Step-4 of campaign wizard. I had to implement both steps.
In the meantime, @pgr has raised this issue at github: https://github.com/salesagility/SuiteCRM/pull/2454#issuecomment-271187177
Also note that: My version of PHP was 5.6.
With thanks,
RK
I can’t. I don’t have access to the variable tab at my webhost service provider. Not much I can change on their side… 
Hello,
Why don’t you check it on your localhost (local development environment) first. If things work, the consult with the Webhost for the possible solution.
@pgr, may offer alternative solution of how to make such modifications in my.ini or my.cnf on live webserver.
Buddy, there is definitely some serious problem with Campagin module or wizard w.r.t., MySQL 5.7. Have a look at this issue at github: https://github.com/salesagility/SuiteCRM/issues/1719
This ZERO date is breaking the campaign created. May be something related with that problem is not allowing you to do what you are looking to do.
That’s why STEP-1, as of now may be needed. Let us see how do they respond to @pgr at github.
With thanks,
RK
I’ll do it but sadly that won’t help much as my main concern is to address this issue on my remote host. My company actually doesn’t care that I can have it work on my home computer if I can’t get it to work for our business needs…
Did you mean ‘Variable’ tab in phpMyAdmin?
If yes, then the changes made there won’t be saved. I have attempted that. It won’t work, as the default sql-mode is automatically reverted back to.
You can tell your webhost that what is happening is :
STRICT_ALL_TABLES is messing up with NO_ZERO_DATE
You can guide them to URL: http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html
They must understand that NO_ZERO_DATE will be deprecated in future versions of MySQL, and that they can safely remove it.
Alternative solution mentioned there is:
Setting the GLOBAL variable requires the SUPER privilege and affects the operation of all clients that connect from that time on. Setting the SESSION variable affects only the current client. Each client can change its session sql_mode value at any time.
With thanks,
RK
[quote=“theachiever” post=42584]@vincegar72,
Did you mean ‘Variable’ tab in phpMyAdmin?
If yes, then the changes made there won’t be saved. I have attempted that. It won’t work, as the default sql-mode is automatically reverted back to.
Thank you for your follow up. There’s actually no my.ini file to be found on the remote SQLprivate server of my service provider. I’ll call their tech support but I don’t feel too optimistic about it. I’m actually planning on reinstalling SuiteCRM’s database on a prior version of MySQL (5.6) and leave 5.7 for when SuiteCRM will be ready for it.
Basically, the marketing team needs their work to be done and I have to provide them with a solution as soon as possible.
I’ll keep you informed.
it is
my.cnf (Unix operating systems) or my.ini (Windows)
I actually edit the previous reply and mentioned my.cnf also
Another edit was:
Alternative solution mentioned there is:
Setting the GLOBAL variable requires the SUPER privilege and affects the operation of all clients that connect from that time on. Setting the SESSION variable affects only the current client. Each client can change its session sql_mode value at any time.
The Database Admin has provide some solution.
RK
Another thing which I would like to share with you is that:
I had to implement Step-1, then Step-2, Deleted the old campaign (which was actually broken and not able to send a single email), Created a new one. New campaign worked very with respect to everything concerning Campaign.
With thanks,
RK
Refer to your original issue:
You need is postal campaign.
You should create non-email type campaign which will allow you to insert fields such as address, city etc.
You were not able to do last time. Because nothing was happening. Now we know that MySQL 5.7 is not allowing the smooth creation of any type of campaign.
Please look to get is going. When you complete all 5-stages of campaign creation, you campaign would work, whether to generate PDF or anything else.
You currently might be nearer to solution than you think you are!
With thanks,
RK
Ok. I tested everything that had been suggested here and in other posts to no success BUT I’ve found out a few things that may be of interest.
1- Log doesn’t report any error while generating the document but there’s no pop up window to download the link
2- PDF documents are actually generated correctly and can be found in ./crm/upload (so yes, I can retrieve them and use them)
3- Strangely enough, the same setup works like a charm on my local host but not on my OVH webhost.
I’ve actually tried to reproduce this “bug” in the exact same conditions (same CRM version, same MySQL version, same PHP version, same database, same document…) localhost vs. webhost OVH and the “bug” only occurs with OVH and amazingly, both logs show exactly the same info !
As a conclusion, all I can think about is it may be something related to my webhost but it’s still hard to say for sure as the logs remain silent about it and since I have absolutely no idea what causes this “bug”, it’s pretty hard to ask for support at OVH.
If you guys have any idea feel free to join in !
Maybe look for Apache logs and try to figure out if it is the Web Server that’s refusing to serve PDF files or something. Sometimes there are extension limitations in .htaccess or in Apache config.
Maybe you could try testing placing a simple PDF file with all filesystem permissions on the root of your webserver. Then try to download it from a direct URL (www.yoursite.com/file.pdf) and see how it behaves on each of your two systems…
This is just an exploration of a possible cause…
1 Like
Good idea ! Interesting…
Generated PDF files get a file permission of 644 on my localhost and file permission of 604 on my webhost at OVH.
Even more interesting is the fact I can access the files with a link on my local host and even if I change file permissions to 777 on my webhost, I still get a 403 error i.e. Forbidden You don’t have permission to access /upload/file.pdf on this server.
NB: on both host the permission are set correctly (775 for the upload folder) and the ownership is set correctly on my webhost in the config.php file.
Unfortunately, I can’t access the apache logs at my webhost.
Wow, that “604” permission really catches my eye. I’ve been diving into this whole permissions issue in SuiteCRM for quite a while and that looks like an interesting “real-world” instance of our nasty bug(s). And a reproducible one, which is great!
Do you mind if I ask you some more info on your OVH host, so we can try to get to the bottom of this?
-
First, I would ask the for every answer when you talk about permissions, always include the user and group of the ownership. So, for example, when you say 604 what user and what group own that file? It’s actually four things together that define access to a file: permissions, owner user, owner group, and current user trying to access.
-
Can you tell me the permissions and ownership on the parent directory where that file is created? This might be limiting permissions, especially if the “sticky bit” is set.
-
What do you have set in config.php and utils.php? Look for something like this:
in config.php:
'dir_mode' => 493,
'file_mode' => 420,
'user' => ' ',
'group' => ' ',
include/utils.php:
'dir_mode' => 02770,
'file_mode' => 0660,
'chown' => ' ',
'chgrp' => ' ',
-
What is your umask? You can get this by typing “umask” at the command-line.
-
What user and group is your Apache server running under?
-
If you have cron (Scheduler jobs) set up, what user and group is your crontab running under?
Let me know if you have trouble getting any of these. And thanks in advance for your cooperation.
Thank YOU for your time.
To give you further info on what actually happens :
-rw----r--+ 1 omegatrawf users 31229 févr. 7 01:22 159cd6e8-bfdc-c3e5-5ac0-589921632b5d
-rwxrwxr-x 1 omegatrawf users 32173 févr. 2 00:53 1738f78e-3b4a-71d6-44c6-58928317c189
The first line is a pdf file I’ve just generated and it gets the permissions granted by the crm.
The second line is also a pdf file I generated but this one got the permissions I granted it afterwards (chmod 775 -R on the whole upload folder)
Yet, if I ever try to access them via my web browser, I get the following message :
Forbidden
You don’t have permission to access /upload/1738f78e-3b4a-71d6-44c6-58928317c189 on this server.
Ok, I’m trying to digest all that : - )
First, some information for you, just so you get to know some of the quirks of SuiteCRM permissions:
-
Your config.php specifies 1517 decimal which is 0755 octal - for directories. If you prefer to specify it as octal, just make sure you include the leading zero. It’s more intuitive this way.
-
The same for files, you have 420 decimal which is 0644 octal.
-
Don’t assume that these values are actually used! This is a very buggy area of SuiteCRM. Some of them are never applied. I hope to fix that one day.
I see a couple of independent problems in your case: one is why are group permissions dropping to zero when the CRM creates the file? That is very weird. The other one is: why isn’t Apache serving the file, even when you do grant permissions? Let’s keep both of these avenues open in our investigation. So moving forward let me just ask you some more info…
-
Directories have more permissions bits (setgid and sticky), can you give me the full permissions (in a form like this drwxr-s—) of the parent directory (upload)?
-
Do you have any .htaccess file in the root folder? And in the upload folder? If so, please consider posting the contents (or relevant parts).
Thanks
Wait! I just noticed something important: you have a “+” in your file permissions. That means an ACL is having effect.
Please run
getfacl
for both files (the one with 604 and the one with 755) and post results here. It might be also useful to compare with a file that serves correctly through the web browser, if you have one.