JaxSite

Thanks for the feedback. I'll check on /dev/urandom and watch the logs over the next few days. Now that I'm past this issue, everything else seems to be working. It was a smooth migration overall. Next on my list is to upgrade to the latest version. ?

Ok I've fixed my issue so I thought I would share in case anyone else runs into a similar issue. PHP's open_basedir was blocking those directories from being seen. I read that on several other blog posts but when I checked my php.ini file, that value wasn't even set. I'm running HestiaCP with Nginx + PHP-FPM. Apparently, there's an additional pool file created per domain located at /etc/php/7.x/fpm/pool.d/yourdomain.com.conf that was setting it. I simply updated it to include the directories and now they are writable as should be.

I've moved the directories up 2 levels. They have same user/group and permissions. I've even added some test code to write a file to the 3 directories. The tmp directory works and the other 2 fail. I am clueless as to why PHP is treating these other 2 folders differently. The user/group "jaxsite" on this server has id of 1003 where on the other server the id was 1004. Is there some code or settings in Blesta that tracks perms by id and perhaps they aren't matching on the server I migrated to?

app/controllers/admin_system_general.php I've been debugging this issue on the server (yikes!). I don't really have a local setup for Blesta dev (yet). Just some basic echo statements to analyze the settings. Looks like the foreach() loop that checks if the directories are writable are returning false for the 2 directories mentioned above. Those paths are coming from the database settings. I've checked and the syntax / path is correct - those directories exist. So the is_writable() never gets called, since is_dir() returns false. Any ideas why is_dir() is returning false on directories that are actually there? Thanks in advance.

Reluctant to post this but I've been trying to move past this for a while now. This is my 4th time to install Blesta. All other times have gone fairly smooth. This one was a migration to another server. I followed the guide and everything looks good. Site renders for both client and admin. Hostname didn't change and kept same db name / pw. Everything looks good except these directories won't show writable no matter what I do. Any thoughts or suggestions would be appreciated.

Another cool update. So this whole thing started when I tried to install Blesta locally on my MacBook Pro running AMPPS. I shifted to installing it on my production server via another subdomain. Thanks to your help Paul, I was able to get it running. So I went back to my laptop and turned on error reporting and debugging. It turns out I was getting a "Session already started..." error. AMPPS default setting in php.ini was session.auto_start = 1. I set that to 0 and everything works locally now too!

I just reset my password and removed the special character and everything works now! Woot woot! Thanks for all your help. -Jonathan

Yes I use a dollar sign like this: //////////////////////////////////////////////////////////////////////////////// // Database //////////////////////////////////////////////////////////////////////////////// // Database connection information Configure::set( 'Blesta.database_info', [ 'driver' => 'mysql', 'host' => 'localhost', //'port' => "8889", 'database' => 'some_database', 'user' => 'some_user', 'pass' => 'SomePassword1234\$', 'persistent' => false, 'charset_query' => "SET NAMES 'utf8'", 'sqlmode_query' => "SET sql_mode='TRADITIONAL'", 'options' => [] ] ); -Jonathan

Paul, I ran the installation via command line and it showed everything completed. It told me to go to /admin/login/ in browser and then I get the same blank screen. So I turned on errors and this is what I got: The installation connected to the database just fine because it creates all the tables. -Jonathan

Paul, Thanks for the response and suggestions. I've tried re-uploading several times. Based on your suggestion, I also re-uploaded blesta-new.php and deleted blesta.php. Re-ran install and still same result. PHP - 5.6 MySQL - 5.6.38 -Jonathan

I am attempting to install the latest version of Blesta 4.1.2 for development and testing. I first tried to install locally on my Mac but was unsuccessful. I knew there were differences in my local AMPPS setup vs my production server, so I opted to try and install on the production server in another subdomain/folder. This production server runs my main instance of Blesta. I just recently upgraded it from 3.x to 4.1.2 without problems. During installation, it tells me I meet the minimum and recommended requirements, etc. I fill out my database info and click INSTALL. The progress bar gets about 80% complete then routes me to ../admin/login/setup and the page is blank. I've checked Chrome Dev tools and nothing is returned. It does return a 200 OK. I've dropped the database tables, removed the code, and tried again with the same result. Upon checking my error log, it showed the following: Based on the post here I modified my MySQL my.cnf file with the following and restarted mysqld but still get the same error. wait_timeout=2400 connect_timeout=360 Any ideas or help would be much appreciated. Regards, Jonathan | JaxSite

Paul, We would like to get a dev license to test our existing customizations before upgrading to 4.x. Further, we have a module we would like to start developing as well. Please let us know how we can acquire a dev license to work locally. Thank you. Regards, Jonathan Griffin | JaxSite

Thanks Jawanet! It works great!!! I hadn't looked at code options yet, having just scanned the admin settings area. This was an easy fix. I settled on 125% for a size that works for me. #create_ticket textarea { font-size: 125%; }

Is there a config setting to control the font size used for the text entry on a support ticket? I'm on a MacBook Pro with 1440x900 resolution and using Chrome. I've attached a screenshot.

I'm having fun learning more about Blesta! Looks like system tasks are set with CompanyID=0. That's why I wasn't seeing the backups task run. I've set it back to CompanyID=0. Now the Amazon S3 backup task is running like a champ!