Now before anyone says "No one can help you with that" please understand that the upgrade worked, this is just a weird bug.
Ok so I upgraded Joomla from 2.5.14 successfully and everything works, nothing out of the ordinary. Every component/module/plugin seems to be working as it should.
HOWEVER the extension manager has a strange behavior, it constantly says:
-1 Copy file failed
I would think file permission problems, but everything is writable. The wierdest thing is it actually installed perfectly, just get this error rather then it saying it worked. (Meaning that when I install the component, there is no error).
This also only happens with components.
Just strange, might be worthy of diving deeper into it in case others run into this with an upgrade. I do not know enough about how the extension manager works to try to identify the problem either, and the lack of a real (or accurate) error message makes it even harder. (the files did copy, so that error message seems out of place)
I will try to look a little deeper in it and see if I cannot isolate it, For those who want to try to recreate it, you can do it by upgrading from 2.5.14 to 3.1.5 though the update manager. The main components I have are no number extension manager, akeeba and admin tools that I feel might have something to do with it.
That most likely is a permissions issue. That error is a RuntimeException thrown by the JFolder class method copy() while trying to copy a file into a folder - src_folder/file to dest_folder/file.
Check your FTP settings in global configuration and then the directories permissions.
I had this error with my module and I did several tests. I removed one level to my image directories from my module and the upgrade finally work...
Related
We have a project that has been in production for months (all its configs were working fine, no issues - including https and user access).
We rewrote part of code under Symfony 4 (no framework was used before that). Everything works perfectly on local, but, in production we started getting the following error in logs:
vendor/composer/ca-bundle/src/CaBundle.php is_dir(): open_basedir restriction in effect. File(/usr/local/etc/openssl) is not within the allowed path(s)
Any idea what might cause that (well... the error is obvious and one fix would be just to include that in allowed paths, but I don't want to do that until I understand the root cause of the problem)?
Important notes:
We did not include that particular bundle, is part of the composer.
Composer doesn't fail and no errors are received during composer install command.
The project SEEMS to work as expected despite the log line.
We have Cloudfare in front and https certificate is correcty handled there.
The list of used bundles is rather short but if needed I can provide a list.
We make no specific calls to functions from that bundle (if any are made, are made by something in symfony/3rd party bundles but a quick search in all code (including vendor) revealed nothing).
I'm kind of running out of ideas what might be causing the problem, especially since it doesn't happen on local and even in production the project seems OK.
The CA-bundle is trying to read from the usr/local/etc/openssl, and it fails because it's not in one of the allowed directories for the PHP process.
It happens in one machine and not in the other because your local openbase_dir settings do not match those in production (and are likely to be much lax, as it usually happens on development).
Your have two options:
Change your openbase_dir setting on production so it's more permissive, at least for that specific virtual-host.
Check which package you are installing depends on Ca-Bundle, and remove that package so it's no longer included.
Further reading:
How to set for specific directory open_basedir
Composer: how to know a package by what other package is required
There is a project in a bitbucket repository where I am developing with 3 more other people. We have the development branch where we close versions and it is the main branch of the project. The thing is that in my computer all files pulled from that branch works fine and I can navigate trough all pages without getting any exception. On the other hand the other 3 people are getting this error in some pages:
Like I said, in my computer this page and some other ones work fine so my guess is that's most likely an error in a file that has .gitignore or individual computer file.
Already tried:
running composer update, composer dump-autoload, php artisan optimize;
clearing cache;
searching into real syntax error in controller (didn't find anything. If there really was this syntax error i'd be getting it too because files are pulled from git);
deleting logic inside controllers to check if it was syntax error (didn't find anything again);
replacing their vendor folder with my vendor folder;
cloning the project again in their machines
These exceptions occur mainly in namespaces after /admin/editar_paginas/vantagens
We are using AdminLTE package, not sure if there is something related with it.
Honestly I have no ideia what's going on. How can it work specifically in my computer and on theirs not? Let me know if it's not clear enough.
yesterday i got stuck on a similar situation where i was not getting what the error was all about, so what i did was i deleted the controller,model ,request and migration and recreated it all it removed the error. it worked for me and if there is not much data in the database you could give it a try, laravel does produce such errors from time to time.
It was really PHP version. They had PHP 5.6 in their machines. Upgrading it to ^7.0 solved the issue.
I have previously installed several different Joomla installation at the same hosting company without any major faults that couldn't be corrected quickly. Though I must say that I now find myself lost and don't know where to turn.. So here I am.
I have mulitple issues that I believe is all connected somehow.
Can't upload Images using the Media Uploader (Image size too large) though everything is set up correctly (max_file_size etc.) in PHP configurations and Joomla config.
Can't upload any other files in the Extension Manager either, since it says my PHP temp folder is not set. Though it is set, and writeble, have permissions etc. Also more than triplechecked the path, by FTP upload PHP-files to write out and verify the absolute path.
When I save something in the Global Configuration, it says my "Configuration.php" file is not writable. Permission is set to 777 even! If I go back and check, my settings is saved though it just said it couldn't save to the file?
Even tried to change to FTP-upload to see if I could bypass the fault somehow, tried both by setting it in Global Settings and by downloading the config file, change it manually and then re-upload it via FTP. No luck there either, seemed to just ignore my settings..
Updating Joomla seems to go just fine though, just updated to 3.4.1 to see if it made any difference but no. Running on PHP 5.6 right now though my hostingcompany just said they will downgrade to 5.4 to see if can make something change.
Otherwise, the website is fully functional! You can browse as usual, and write blogs etc. Though, not upload anything. Saving other settings work fine though. Should also mention that the website worked locally 100% before uploaded to the current server.
Any ideas where to start looking? Been Googling for the last 8 hours!
My webhost downgraded my PHP service to 5.4 instead, which solved all problems. Weird.
I've got a php-fpm 5.3.10 installation running on Ubuntu 12.04 on a remote server, and I'm trying to use PHPUnit from within PhpStorm 8 (as of yesterday). I don't have a local php installation.
I have installed PHPUnit on my server and can use it via the commandline.
I have (seemingly) successfully linked my PhpStorm to my remote server and remote interpreter, and configured the right deployment settings.
At first I had an issue where it would try to run my local paths remotely, but that issue has been sorted. However, I keep getting the error Cannot find PHPUnit in include path (.:/usr/share/php:/usr/local/bin). This is almost certainly a serverside error (PhpStorm also knows these include paths, it could be confusing them for local paths) as the paths change when I change my include path in my php.ini.
This is the same error it gives back if I don't install PHPUnit at all, so again it would seem this is a serverside issue.
I have tried installing PHPUnit through PEAR (which is deprecated and soon unsupported by PHPUnit but still mentioned in a lot of PhpStorm tutorials), through Composer (on the remote server, not in PhpStorm) and even just manually.
The server accepted these installation methods just fine (the PEAR method seems to install an older version of PHPUnit, 1.0.x instead of the apparently available 4.0.x) but they all give the same issue.
If I manually place PHPUnit in my include path (I'm unsure what kind of files it wants there, though. a .phar? Source files?) it does seem to pick up something, but I get an XDebug error instead and it tells me it can't find the necessary PHPUnit files so I assume it is not the way to go (it shouldn't have to be).
At this point I'm starting to run out of ideas and none of the Stackoverflow responses to similar issues or PhpStorm/PHPUnit documentations seem to be able to help me.
Edit 1: Included picture of settings, as requested.
(can't post images yet, not enough rep)
settings
Other than that it's probably worth noting I'm using a mounted folder for my deployment, which just refers to the filesystem of my server (it's in my local network)
Edit 2: Changed deployment to SFTP as suggested and updated my mappings, as PhpStorm is able to successfully validate my remote environment everything seems to be in order there.
After reinstalling PHPUnit via Composer and selecting the autoloader in my PHPUnit settings it was still giving the error about the include path (it shouldn't do when the autoloader is used, should it?) so I changed the include path to point to /usr/share/php/Composer/vendor/phpunit (and the two directories above it, for good measure).
It was still giving the error, however in the error it says it cannot find PHPUnit in the include path, while the installation is in a directory called phpunit (all lowercase). After changing the directory name to PHPUnit, it is no longer giving the include path error, but en XDebug error instead : Warning: include(/usr/share/php/Composer/vendor/phpunit/phpunit/PHPUnit/TextUI/ResultPrinter.php) [<a href='function.include'>function.include</a>]: failed to open stream: No such file or directory in /usr/share/php/Composer/vendor/composer/ClassLoader.php on line <i>382</i>
I'm unsure what this implies exactly, and I don't know whether the error is because I should not be changing the directory names (it seems as if that should not be necessary), because I haven't changed enough of them (other directories are likely still lowercase) or because these files should simply not be in the include path (composer should be managing my dependencies, shouldn't it?).
In some cases, this can be resolved extremely easily. PHPStorm looks for the folder PHPUnit in the include path(s), but I've found this is case sensitive! Installing through composer will install PHPUnit in a folder called /vendor/phpunit/phpunit/phpunit, this is all lower case. This means that PHPStorm will not be able to find the folder unless you change the folder name to 'PHPUnit'. The include path should therefore be: /usr/share/php/composer/vendor/phpunit/phpunit and in that folder, there should be another folder called 'PHPUnit' (case sensitive!). I'm sure this isn't the prefect solution, but it works.
I have an Apache vhost set up for the folder (say website) which is a symlink to another one linking to a folder with a current release (say website_N) where N is release number (website -> website_123). When a new release is deployed, another folder named website_N+1 is created and when its content is ready website symlink is recreated to link to that new folder (website -> website124).
This setup seems to confuse APC's cache of includes. Sometimes (not always, which is annoying) after a new deployment and the following symlink switch include and require instructions in application start to result in redeclaration errors:
Fatal error: Cannot redeclare class Foobar in /absolute/path/to/deployment/physical/folder/website_N/include_foobar.php
website_N folder in that message is usually one of the old build folders, sometimes even no longer existing. But sometimes error is generated showing the right physical location of the most recent release folder. What stays the same is "cannot redeclare" error for classes loaded for the first time.
I'm pretty confident that is an APC issue because every time that happens adding apc_clear_cache() to application bootstrap resolves the problem.
I guess that happens because different releases reside under the same symlink folder sharing the same "unresolved" path. As a result it could be that old include connections are loaded for precompiled images, and another attempt to include a dependency is performed for its "resolved" path, so it appears as a new one and results in double include and following redeclaration error. Although this theory might not make much sense, I don't understand APC internals very well.
There are many ways around that (to clear cache as a part of deployment process being the obvious one), but if anyone can explain to me the mechanism behind that error, i.e. what in this setup breaks APC behaviour and at which point (and why physically removed folder paths sometimes appear in those error messages) that'd be great.
I use TYPO3 and had the same problem. TYPO3 caches quite a lot. When changing the symlink to another source it is neccesary to go into the TYPO3 installation folder using a shell and manually delete the cached files.
After that all is good. It took a day to figure out.