I have installed TYPO3 on my Linux Ubuntu.
TYPO3 is version 11.5.4.
When I want to install TYPO3 CMS, errors like below shows up.
If you really want to start over, delete all files in your document root and all tables in the database. But beware, you will loose everything!
But most probably it's not necessary. First of all you should set display_errors to 1 in typo3conf/LocalConfiguration.php (don't forget to turn it off again once you found the error!). With display errors on, you should get a more verbose error message once you call frontend or TYPO3 backend.
Next you should check the error log in YOUR_PROJECT_ROOT/var/log (composer based installation) or typo3temp/var/log/ (classic installation).
If your really want to start from scratch, I recommend to follow the installation guidelines from the official TYPO3 documentation.
Maybe it's easier to start with a TYPO3 installation on your local machine. Here is a good documentation to get started with DDEV.
Related
I am currently working on migrating a non-Composer TYPO3 project to Composer.
From what I have seen and read, the autoloading changes and the file structure changes. You cannot import extensions via the extension manager anymore. Also, some extensions can only be installed via composer (unless you do ugly tweaking).
Also, from a security point of view, at least one attack vector is shut down because you can no longer install extensions via the backend.
The documentation and others state that using TYPO3 with Composer is recommended but what exactly are the advantages, do these apply in all cases?
For example, in my case, I maintain one site, updating both TYPO3 and extensions is easy. In practice there probably will be no huge improvement. I think working with a package manager is cool but I also have to "sell" why I am doing this now and other tasks are not getting done.
The advantages of running TYPO3 v8/v9/v10+ in composer-based mode:
Speed improvements for PHP, as the autoloader includes the requested extensions (and used system extensions)
Only the system extensions you use are using are available in your production site
If you are using Git, you do not need to add your typo3/ folder and your vendor folder with composer-based extensions, which makes your Git repository much smaller
You can add more PHP libraries via composer that you need in your site, and can fine-grain your dependencies based on your PHP environment
The differences:
You cannot use the Extension Manager to download extensions from TER anymore, you have to use the CLI tool for fetching third-party or system extensions
You still need to activate these extensions in Extension Manager or via TYPO3 Console to update your PackageStates.php file.
All your local extensions need to either be added via a) autoload sections in your root composer.json or b) include their own composer.json and include the autoload section in there.
The statements about the folder structure is wrong, in fact, Composer allows to configure having your vendor folder OUTSIDE of your document root, which makes your website more secure IMHO, but you do not have to.
In general, if you're not used to use CLI, or using Git or a deployment strategy, composer is actually not a practical solution for TYPO3 users.
I totally get your point in that you have to get it sell it.
Getting your project running with composer isn't that hard, but does come with some pitfalls. But once you get familiar with some basic commands, you will notice that it will lower your work time.
Not in all, but in many cases, managing your project with command line tools line https://github.com/TYPO3-Console/TYPO3-Console give your more powerful and faster tools to work with. And be honest, typing in a console always look cool.
So yes, even for a 'small site', learning a new tech always rewards in the long run. You don't sell time, you sell expertice. The learning price, you do have to pay for that yourself, but you get to keep the joy that you feel when you get it to work. win-win
short question. I got a site in Typo3 8.7 it was created in Classic Mode.
I installed a lot of extensions ( Realurl and stuff).
Now i want to port that to composer mode.
Is there a way to generate a composer.json/.lock from my site and then bring it over to my composer typo3 installation and let it download everything?
There is a good list of steps you need to take for switching from classic to composer mode from Mathias Brodala.
https://stackoverflow.com/a/46450927/1375055
No, not to my knowledge. You'll have to kickstart your composer.json manually (or with the composer cli interface) and evolve it until you reach a similar combination of dependencies in your project.
There is no Automated way of dooing this but a quick hack would be
the following bash command do get a list of all packages names of the extensions
for f in $(ls typo3conf/ext); do echo "typo3-ter/$f"; done;
I have successfully installed a Centos Vagrant box with Magestead (http://www.magestead.com/). This worked and I was able to log into the Admin section without any issues.
However, I am more comfortable using Ubuntu, so I created a new vagrant box using Ubuntu. I set it up as per the documentation and installed Magento without any issues. I have set up the correct file permissions etc. However, when I try and access the admin section, I receive the following error. The front pages work fine btw.
Warning: file_get_contents(/var/www/html/magento2/var/cache//mage-tags/mage---ea6_BACKEND_MAINMENU): failed to open stream: No such file or directory in /var/www/html/magento2/lib/internal/Cm/Cache/Backend/File.php on line 614
I have tried clearing the pub/static folder, cleared the various var/ directories as suggested in other posts etc.
Thinking it might be an issues with the vagrant shared folders. I started again and this time installed Magento on a folder inside the vagrant box (not on the folder share). This was a lot quicker so I hoped that this might have been the reason. Alas, this did not solve my problem and I still receive the same error.
I have tried the composer install and the manual compressed download install but I have the same error on both.
Looking at the location of the missing file, I can confirm that the file is not there. When I look at the Centos box, this file is there. If I remove the folder on the Centos box (var/www/html/magento2/var/cache/), the file gets created as expected and works fine. This does not happen with the Ubuntu box, however some of the mage---ea6 files are created so it's doing it stuff.
Does anyone have any ideas?
So I figured it out after some testing.
It turned out to be xDebug (or the way I was installing it) that was causing the issue. I ran some tests and the admin areas worked fine with xDebug not installed.
I needed Xdebug for development reasons so I installed it using Pear and Magento installed fine with everything working correctly!
Installation problem Typo3-Neos beta1
While composer is running the project-create, there are a lot of warnings that "class/TYPO3/Flow/Composer/InstallerScripts is not autoloadable -- post installation scripts cannot be called".
At the end there is no setup file in the Web folder.
Is this a problem with the order of composer's loading of files?
"This is just a warning during the composer installation because of the loading order of the packages. After it has gotten to the Flow package it will stop. Everything is fine and there’s no need to worry about it."
-- Aske Ertmann, core dev
http://forum.typo3.org/index.php/t/200300/
Ensure AllowOverride All and enable module rewrite (e.g. a2enmod rewrite on Debian based systems or in php.ini uncomment the line beginning with mod_rewrite on Arch or others)
Don't forget to restart or reload apache.
Took me ages to figure it out. Recreated entire servers for it.
MAC OSX 10.7.5 -- MAMP 2.1.3 -- XDEBUG 2.2.3
I used the xdebug wizzard to download and install using the terminal. After following the steps
Rebooted MAMP but no xdebug in phpinfo();
I thought it was weird that the wizzard says all you have to do it paste zend_extension = /Applications/MAMP/bin/php/php5.4.10/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so in the end of your php.ini file
I did add quotes around the pathname - the pathname from the wizzard came without them
Every other tutorial says there is more than just this one line that needs to be added
MAMP seems to have its own 'zend_extension = "/Applications/MAMP/bin/php/php5.4.10/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so"' that just needs to becommented out. Anyway I tried both the pasting from the wizzard as well as uncommenting.
Since I'm trying to use xdebug with my PHPstorm trial, I checked for the steps layed you at http://www.dotvoid.com/2012/09/using-xdebug-in-mamp/
Again it's weird: Here it says that all you need to do it add these 2 lines
xdebug.remote_host=127.0.0.1
xdebug.remote_enable = 1
It's weird because other tutorials make you add more lines (back when I tried to get xdebug on an older version of MAMP to go with netbeans without success) about the localhost.
Here's what's in my php.ini file now:
[xdebug]
zend_extension= "/Applications/MAMP/bin/php/php5.4.10/lib/php/extensions/no-debug-non-zts-20100525/xdebug.so"
xdebug.default_enable=1
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
I also checked if I'm configuring the right php.ini file, looking in phpinfo(); where it says which php.ini file is loaded. In this case /Applications/MAMP/bin/php/php5.4.10/conf/php.ini I verified if this is the correct php.ini file that I'm edititing and it is.
The last anwser in this SO question here speaks of two certain files that need to be the same binary maybe one file is 32bit binary and the other one is 64bit. When I tried to check this, the files mentioned in that question (/path/to/mamp/Library/modules/php5.3/libphp5.so) are not in my current installation of MAMP. In my current installation, I can go to Applications/MAMP/Library/modules, but there is no folder in that modules folder, leave alone one that says php of any sort.
In this tutorial, there is a mention of updating PEARL. This may not be relevant to my issue but I just followed it because I don't know really, I thought it wouldn't hurt. When I try to do that in my terminal the error message says
Xdebug requires Zend Engine API version 220090626.
The Zend Engine API version 220100525 which is installed, is newer.
Contact Derick Rethans at http://xdebug.org/docs/faq#api for a later version of Xdebug.
I found this issue in the xdebug FAQ. I quote
it is most likely because you compiled Xdebug against PHP headers that belong to a different PHP version that you're running
Further explanation confirms that the message about the zend api version points to the same issue and that two versions of PHP are colliding somehow.
The solution to this is explained on the same FAQ page where it says
Q: How do I find which phpize to use? [...]If it doesn't match up, and perhaps the wrong "phpize" binary is found on the path, you can
run configure as follows:
1. /full/path/to/php/bin/phpize
2. ./configure --with-php-config=/full/path/to/php/bin/php-config
I don't know how to interpret this in practice. But here's what I have tried
I was still in the /usr/bin and tried the first command usr/bin/phize. this returned Cannot find config.m4. Make sure that you run '/usr/bin/phpize' in the top level source directory of the module
I don't know what they mean by the top level source directory of the module. Maybe 1. and 2. are 1 command? And the module means xdebug.so?
No matter what I try though, I keep getting the Cannot find config.m4 error whenever I just even try to run phpize. I tried running phpize from /usr/bin/phpize or from /Applications/MAMP/bin/php/php5.4.10/bin/phpize. Same error came