Typo3 classic mode generate composer file - typo3

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;

Related

Broken TYPO3 installation on Linux Ubuntu. What to do now?

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.

TYPO3 composer installation - differences to non-Composer

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

Enabling DHL Marketplace in Magento 2

How can I add DHL Market Place in my Magento 2 admin? Been searching on how to enable it but can't find any solution. Should I just copy the download file into the app folder? or do I need to go to the admin panel?
Note: Beginner here
Ok for those who will be encountering the same issue as I have here is the answer and I'm referring this to the answer that the developer gave me.
If you are running in PHP 7+ and want to install via VCS then below are the command you need to run and DON'T use installation that they provided in the README.md specially for version 0.10.0. It lacks the proper instruction on how to install it in Magento 2.3 using version 0.10.0 Below are the correct command needed to run and install DHL in your Magento project
composer config repositories.dhl-shipping-m2 vcs git#github.com:netresearch/dhl-module-shipping-m2.git <-- This is the important part to make it work
composer require dhl/module-shipping-m2:0.10.0
Magento2 follows a structure to add custom modules .. Their are two ways to add extensions in m2..
1 : Install it from the composer Eg: for DHL to install from composer
composer require dhl/module-shipping-m2:0.10.0
It will directly saved in vendor folder
2 : Manual installation , Download the extension and copy that into the magento root ie.. app/code/yourextension

Configure dependencies in RPM

I have built a RPM-package for Centos 6.6 that is installed on a machine of our customer.
This package contains our own software, customized for the specific use case, but also uses the open-source package HAProxy.
HAProxy (RPM-version 1.5.4-2.el6_7.1) comes with a default-configuration in /etc/haproxy/haproxy.conf and it cannot be customized without changing this file.
But I want the configuration to be part my generated package. RPM throws an error if the /etc/haproxy/haproxy.conf file is in my package, because it is also part of the haproxy-package.
I have worked around this problem by providing a custom upstart-script which starts HAProxy with a different config file, but this does not seem to be the right way to do this.
Is there a preferred way to handle such customizations?
In cases like this, I've created an RPM which installs configuration files into a different subdirectory, and in its %post and %preun scriptlets modifies the uncooperative package's config-files:
when installing, I renamed the original config-files, and made symbolic links from those pathnames to the overwriting config-files, and
when uninstalling, the package removed the symbolic links and restored the original package's files.
Doing it that way of course meant that my config-RPM was dependent on the original RPM. A little awkward to describe, but it works.
In followup, the issue of updating was mentioned. Updating an RPM requires special handling to avoid uninstalling things. The rpm program passes a parameter $1 which you can test in the %pre and %preun scriptlets to notice that this is an upgrade and that there is no need to save the original config-files (or restore them). The rest of the scriptlet would be the same, by copying the new versions of your config-files over the others.
Further reading:
Defining installation scripts (shows the use of `$1)
RPM upgrade uninstalls the RPM
Your approach is correct. On EL6 and sysv there is no other choice than creating custom haproxy package or custom haproxy service or create script which customer runs after installation. I see creating another service as best option.
Note that on EL7 with SystemD you have much better option as you can use Drop-In feature of SystemD. For more information see:
https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html
https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets
https://wiki.archlinux.org/index.php/Systemd/User#Service_example
The usual way this is done is to have a drop-in configuration directory, e.g. /etc/httpd/conf.d/, where your package would drop its configuration, and you would tell the other daemon, e.g. httpd, to do a graceful restart in your %post/%postun.
I don't know anything about HAProxy, but a quick search implies that they do not support this configuration directory concept that has been around for many years. A few people have hacked it in, but unless it is out-of-the-box, you will run into your original problem again.

Golang auto completion nsf package

I have installed sublime and go.
Tried the autocompletion feature offered by https://github.com/nsf/gocode.
It works perfectly for standard packages.
But not working for external packages like the ones fetched from github.
Any help on this appreciated. Thanks.
It will only work if you build and install those external packages.
if you just go get their sources, the completion won't work, even said sources are in the GOPATH/src/....
Those packages need to be at least compiled (GOPATH/pkg).
As mentioned in "How does Go update third-party packages?", a go get -u all can help.
For go autocomplete to work (Atom Editor, Sublime, even vim with autocomplete)
Your package must be placed in the go path. (this can be automatically done if the project is on github and you use the get tool)
go get -u github.com/username/packageName
you must build your package
go build $GOPATH/pathToYourProject...
you must install your package
go install $GOPATH/pathToYourProject...