I made a fully functioning website with the Bolt CMS system on my home (development) system. After finishing and testing everything, I've put the site on the production webserver and it works like a charm, except for one thing: accessing, uploading and selecting files does not work. Furthermore, when I try to access the files section in the backend (http://.../bolt/files) I get the error:
Whoops\Exception\ErrorException thrown with message "syntax error, unexpected '['"
Stacktrace:
#0 in /home/etxean/domains/etxean.net/public_html/vendor/league/flysystem/src/Filesystem.php:154
This is inside the writeStream function I checked file permissions and these are okay. Any idea where to look to debug this error?
#lxg is correct in that this is being caused by a PHP 5.3/5.4 error.
To maintain compatibility with 5.3 we use a forked version of the Flysystem repo, but it seems that you are loading the real one.
I'm guessing this may be because you have installed Bolt as a composer package rather than downloading the distribution version.
If so then you can add the fork to your composer.json file in the root of your Bolt site. It should look like this:
"repositories": [{
"type": "vcs",
"url": "http://github.com/rossriley/flysystem"
}],
then run a composer update and the Flysystem package will be replaced with the fork.
The file in question uses the PHP 5.4. array notation.
Prior to 5.4, an array would always be declared like
$foo = array(1, 2, 3);
Since PHP 5.4, you can use the JS(ON)/Python style array notation:
$foo = [1, 2, 3];
Solution: If you want to use this library, you should upgrade your server to at least PHP 5.4.
Theoretically, you could also modify the source file to run with PHP 5.3, but that would be a really bad idea in regard to maintainability.
Related
I just picked up a project from another developer, and I don't know why, maybe this is because it's my first time remotely connecting to an EC2 instance, but PhpStorm isn't recognizing parts of the file paths in the "use" namespace section.
However, the code runs very well with no errors on the EC2 instance.
Here is what it looks like:
Why are "Common", "ORM", "Validator", "Constraints", "User", and "Collections" in red?
Is there any extra configuring I need to do in PhpStorm?
I know that these directories are there, for example the "use App\Entity\User" namespace is accounted for in the "User" entity file:
You need to install PHP Annotations plugin. Plus it looks like you haven't run composer install against the project's composer.json
Terminal is giving me an issue where it prints "false"
Additionally, "false" shows up before the html view in the Laravel output.
I am running into this on codecourse's Classified's Site tutorial
Any idea how to remedy?
More detail:
I think what set this off was I changed the config/database.php for mysql from strict = true to false (have since changed back).
After changing mysql strict = true, I reloaded vagrant with provision on and did a migrate:reset and migrate then reseeded the database. Yet, when I run commands in terminal (eg. php artisan migrate), 'false' gets displayed on the next line before the migrations happen. and annoyingly, my website displays "false" in the top of the view, before the html doctype in the source gets written I took a look around the routes and views and cannot see how the false is creeping in there (especially since I changed it back to true!)
Any idea how to remedy, or suggestions for what to try?
See sample terminal Code below
vagrant#homestead:~/code/fresh$ php artisan migrate
falseMigrating: 2018_02_16_130447_create_listings_table
Migrated: 2018_02_16_130447_create_listings_table
vagrant#homestead:~/code/fresh$ php artisan make:controller Listing\ListingController
falseController created successfully.
vagrant#homestead:~/code/fresh$
Thank you Sam for the answer, I had accidentally put "false" ABOVE the start of the php declaration on the first line of my database config file
A PHP file can contain non-php and remain valid, i.e the following is valid:
false <?php echo '<h1>Hello World!</h1>'; ?>
That would produce the following:
false <h1>Hello World!</h1>
Laravel configuration files are simple PHP files that return an array, that file is included by the framework and the app configuration is populated from the values in the array. The behaviour you're seeing is indicative of a file within your application containing content that shouldn't be there, and based on what you were doing when the issue occured it's probably one of your configuration files.
Run the following command from your project root:
$ grep -r "false" config
Then review each instance of "false". You'll most likely find that at the top of your config/database.php file you've mistakenly placed false before the opening tag <?php.
For future reference, if you're using version control it is much easier to identify the cause of issues like this because you can step through every change you've made since the issue started. GitHub has a great desktop client that makes version control very easy :-)
I started a Django 1.7 OpenShift instance. When I have python print all of the paths from sys.path I do not see OPENSHIFT_REPO_DIR (/var/lib/openshift/xxxxx/app-root/runtime/repo).
When I use https://github.com/jfmatth/openshift-django17 to create a project I do see OPENSHIFT_REPO_DIR in the path.
Looking through the example app above I don't see anywhere that this is specifically added to the path. What am I missing?
To clarify:
I have to add the following to my wsgi.py:
import os
import sys
ON_PASS = 'OPENSHIFT_REPO_DIR' in os.environ
if ON_PASS:
x = os.path.abspath(os.path.join(os.environ['OPENSHIFT_REPO_DIR'], 'mysite'))
sys.path.insert(1, x)
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
OPENSHIFT_REPO_DIR is not in my path as I would expect. When I used the example git above, I did not have to add anything to the path.
A little while back I had issues with some of the pre-configured OpenShift environment variables not appearing until I restarted my application.
For what its worth, I started up a brand new Django gear, printed the environment variables to the application log, and verified that I do see OPENSHIFT_REPO_DIR (and all other env vars) properly.
This issue appears to be caused by trying to use the standard file structure layout that django produces when you use startproject. Openshift appears to need a flatter file structure. As soon as I moved wsgi up to a sibling of mysite it resolved the issue.
im running Hudson continuous integration for db unit.
when i run the job the console output is displaying the SUCCESS, but then why do the Parsed Console Output keep returning this error:
ERROR:Failed to parse console log :
log-parser plugin ERROR: Cannot parse log: Can't read parsing rules file:
i already installed the parse-log plugin & i already restarted the Hudson..
i installed the plugin using remote PC
any help and suggestion is appreciated. Thanks!
1) Place the Parser Rule File in the JENKINS_HOME location.
2) Configure that log parser console output in the Global COnfiguration settings and Name it.
3) Add this option in the Post Build Actions and Select the Name
ok silly me..
i forgot to configure the global configuration in hudson that link to the parser rule file..
problem solved.
I'm posting this in case anyone else has a specific case of this problem. This issue started when upgrading from 1.509.2 to 1.554.3... I had the parsing rules file in the win\system folder which was a known issue when running Jenkins as a service. Well I guess they fixed it by this version. I moved the parsing rules back into Jenkins Home folder and it worked fine again.
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.