Testing Latest Version (error)

[joebordes]

Hi,

I deleted that directory a few days ago and missed that it was being controlled in the install. I deleted it because that functionality is not used anymore. I updated the install and also another deprecated function that used it. Download again and let me know how it goes.

Thanks for informing !!

Have a nice weekend

[joebordes]

does your install have this file:

https://github.com/tsolucio/corebos/blob/master/Smarty/libs/plugins/outputfilter.trimwhitespace.php

?

is it failing also with the fresh install?

[mweaver]

(02-24-2017, 04:56 PM)joebordes Wrote: does your install have this file:

https://github.com/tsolucio/corebos/blob/master/Smarty/libs/plugins/outputfilter.trimwhitespace.php

?

is it failing also with the fresh install?

It does have that file and is failing with a new install. Just tried it.

[joebordes]

I had a look at the code and see no reason why that would be happening. Searching on the internet doesn't turn up anything either, so I am a bit at loss here.


You can try this patch:

Code:

diff --git a/Smarty_setup.php b/Smarty_setup.php
index 7a13bb0..8cbb0f1 100755
--- a/Smarty_setup.php
+++ b/Smarty_setup.php
@@ -33,7 +33,7 @@ class vtigerCRM_Smarty extends Smarty{
               $this->setConfigDir('Smarty/configs');
               $this->setCacheDir('Smarty/cache');
               $this->setPluginsDir('Smarty/libs/plugins');
-
+var_dump($this->getPluginsDir());
               //$this->caching = true;
               $CALENDAR_DISPLAY = GlobalVariable::getVariable('Application_Display_Mini_Calendar',1,$currentModule);
               $CALENDAR_DISPLAY = empty($CALENDAR_DISPLAY) ? 'false' : 'true';

that will output the plugins directory to the browser screen just to make sure it is looking in the right place for this plugin.

Ultimately you can comment out this plugin:

Code:

diff --git a/Smarty_setup.php b/Smarty_setup.php
index 7a13bb0..34f0965 100755
--- a/Smarty_setup.php
+++ b/Smarty_setup.php
@@ -52,7 +52,7 @@ class vtigerCRM_Smarty extends Smarty{
                       //Added to provide User based Tagcloud
                       $this->assign('TAG_CLOUD_DISPLAY', self::lookupTagCloudView($current_user->id) );
               }
-               $this->loadFilter('output', 'trimwhitespace');
+               //$this->loadFilter('output', 'trimwhitespace');
               $this->registerPlugin('function', 'process_widget', 'smarty_function_process_widget');
       }
}

that will generate more spaces and make it go a little slower but it shouldn't have any other impact

Let me know what the output on screen is for the plugin dir and how the application performs without the whitespace filter

[mweaver]

I think my head just exploded or the Ale was too strong last night. If I could just peel my arse outa this recliner and get back to where the server rack is I might get something accomplished today.

[mweaver]

I am rather certain I'm not losing my mind, however I am also certain that I am stumped as to what exactly could be going on here:

As you can see there are some items on this list that appear to be refusing to cooperate. 

I have so far done:

1. Installed and done basic configuration of CentOS 7 (which includes first round of updates)
2. Installed MySQL and PHP and of course Apache.
3. Copied the latest version from GitHub of CoreBOS 7 to this new server and unpacked everything into it's final destination on the server. (Apache is running as apache:apache, so everything in the cbostest directory is owned by user/group apache.
4. I did not setup a web server container in httpd.conf simply because I'm testing and to date I've never had to do that before. 
   

What's got me absolutely stumped are the items in red on the screen shot above:

1. I do have IMAP support: Dovecot is both installed and running with a basic configuration meaning it's accepting connection, however there are port forwarding rules to it from the perimeter. But CoreBOS doesn't care about that.
2. Currently I have the permissions set on the entire dir tree for this app set to 775. I even tried 777 to see if the setup script saw things any differently, but no change in behavior.
   

I guess this is my punishment for working with Windows servers for so long and ignoring my Linux side. I know there's got to be something I'm missing, but for the life of me I can't imagine what it could be. And don't get me started on that blasted setting in the PHP.ini file. I've tried setting that critter three ways to Sunday and it continues to read that way. Current setting on that is: 

Code:

short_open_tag=

So...? Anyone see anything I've missed?

[joebordes]

first thing to look at is phpinfo

create a script inside the webserver root with this contents:

PHP Code:

<?php phpinfo(); ?>

now call that page in the browser.

search on that page for imap, that is where you need to have php-imap support, this is usually installed in the operating system, probably somthing like

Code:

yum install php-imap

Code:

short_open_tag = On

although this setting is really not important. after you make a change to php.ini you have to rester apache server:

Code:

apache2ctl restart

you can find the exact location of the php.ini file in the phpinfo output, search for "Loaded Configuration File"

as for the permissions look in the phpinfo for "User/Group" under the apache handler section, that will tell you who the files have to be assigned to. I am supposing that centos has a rather strict permission system and it won't let apache read files assigned to root. Try changing the owner of the files and directories to the webserver user

Finally, that PHP version is rather old, I would recommend a php5.6 or higher if possible.

Keep asking....

[mweaver]

(02-26-2017, 03:19 PM)joebordes Wrote: first thing to look at is phpinfo

create a script inside the webserver root with this contents:

PHP Code:

<?php phpinfo(); ?>

now call that page in the browser.

search on that page for imap, that is where you need to have php-imap support, this is usually installed in the operating system, probably somthing like

Code:

yum install php-imap

Code:

short_open_tag = On

although this setting is really not important. after you make a change to php.ini you have to rester apache server:

Code:

apache2ctl restart

you can find the exact location of the php.ini file in the phpinfo output, search for "Loaded Configuration File"

as for the permissions look in the phpinfo for "User/Group" under the apache handler section, that will tell you who the files have to be assigned to. I am supposing that centos has a rather strict permission system and it won't let apache read files assigned to root. Try changing the owner of the files and directories to the webserver user

Finally, that PHP version is rather old, I would recommend a php5.6 or higher if possible.

Keep asking....

Hi Joe,

I finally got PHP upgraded tol 5.6, however there is no php-imap package. To get 5.6 on CentOS 7.3 I had to enable the epel-release repo and IUS repo.

As I mentioned before the web server directory root: /var/www/html and everything under that is owned by apache:apache. Current permissions are set all the way down through the tree to 775:

Code:

[root@merlin cbostest]# ls -l config.inc.php

-rwxrwxr-x. 1 apache apache 0 Feb 10 19:14 config.inc.php
[root@merlin cbostest]# ls -l tabdata.php 
-rwxrwxr-x. 1 apache apache 1967 Feb 10 19:14 tabdata.php
[root@merlin cbostest]# ls -l install.php 
-rwxrwxr-x. 1 apache apache 1820 Feb 10 19:14 install.php

That is just a small example of the permissions settings. I've done lots of Apache web servers and I can't remember ever running into something like this.

Apache is setup to run as apache (user) apache (group) and since this is the case I'm at a total lost as to why I'm seeing the program install check returning information to the screen that claims the file permissions need adjusted. I though perhaps there was something odd with Apache's configuration but while I've been comparing the differences between the old and new server config files I don't see any real differences.

[mweaver]

Yes... I took a breath and realized I was asking yum for the wrong package and found the correct php-imap package: Perms haven't changed though.


I know it's right in front of me and I'm gonna feel really stupid when I see it.

[joebordes]

paste here the value of "User/Group" in phpinfo output and a screen capture of an "ls -l" of the top directory if the coreBOS application