Similar questions have been asked, but what makes mine different is that I seem to have the configuration correct. Here is my configuration (my name has been redacted, for privacy reasons).
What I know is that my PhpStorm IDE has not been activated yet; is that required or is my configuration incorrect, despite the folder and file being at these places?
So you're trying to use PhpStorm from within VSCode to format your files. Which means: calling PhpStorm as a command-line app.
I'm pretty sure that PhpStorm has to have a valid active licence or be in the evaluation period (so it has be "activated" in some way). I remember seeing tickets with similar issue when using PhpStorm for code inspections in Continuous Integration tools.
In any case:
Check what command VSCode is trying to execute here, then open your OS console and try to run it there -- will you see any errors/warnings in the output?
If you do not see any such messages there then check the idea.log file -- the IDE will write everything there for sure.
On Windows it would normally be in the C:\Users\USERNAME\AppData\Local\JetBrains\PhpStorm2022.2\log folder (for the current 2022.2 version). Other OS / cusom location -- check https://www.jetbrains.com/help/phpstorm/directories-used-by-the-ide-to-store-settings-caches-plugins-and-logs.html#logs-directory
...or is my configuration incorrect, despite the folder and file being at these places?
As per docs the Code Style settings file can be located anywhere: it can be in the default place as well as any other as it can be passed as an argument in the command line (-s parameter). So keeping the file with Code Style settings in the VSCode extension folder is OK as long as that parameter is used.
vscode keeps adding a file named .dccache. How can I prevent this?
It messes up the github diffs and I keep on having to add .dccache to the .gitignore for several different projects.
I can't find anything about why .dccache is being created in the first place
It can also be created by the Snyk extension.
I have the same file, I believe this is being created from DeepCode: https://www.deepcode.ai/
This is a code analysis tool to try to find issues. Check if you installed the DeepCode extension in VSCode if you want to get rid of this file, otherwise ignoring it should be fine.
The DeepCode plugins or the CLI is using this file to create a cache for the source code bundles send to the analysis engine. Without this cache, the collection and upload would be very time-consuming.
As it only serves as a caching mechanism, you can exclude it from git uploads and ignore it otherwise.
Snyk extention has a Help&Feedback tab, on the FAQ there is a 'Add custom .dcignore file to your workspace'.
Sometimes git ignore doesn't work for me
I used this file: https://github.com/DeepCodeAI/dcignore/blob/master/full.dcignore.js
just create .dcignore and copy all contents to that. I manually add .dccache and .dcignore just in case.
I had the same issue and when I disabled Snyk extension on VS code editor is disappeared, if you don't have Snyk installed and still have .dccache appearing every now and them, just keep an eye on the other extensions, disable each one at a time and see which one is creating the .dccache file
After I instaled extension in typo 3 version 4.5 I can't log in to backend, my page is blank and after I try to go on http://mydomain/typo3/install/index.php I get this message :
The Install Tool is locked.
Fix: Create a file typo3conf/ENABLE_INSTALL_TOOL
This file may simply be empty.
For security reasons, it is highly recommended to rename
or delete the file after the operation is finished.
If the file is older than 1 hour TYPO3 has automatically
deleted it, so it needs to be created again.
Installing any extensions in such an old TYPO3 probably will kill your installation, as any modern extension is incompatible to the old sources.
Modern extensions have namespaces, autoloader, use API classes and functions unknown to the old installation, maybe even use PHP7 features unknown to the old PHP which is needed to run those old TYPO3.
now for your cleanup:
For entering the instal-tool do as the message indicates:
create/update that file and then you can enter the install tool.
but in 4.5 you will not get much help to get the system running again.
you must disable the malicious extension:
in the file typo3conf/localconf.php you need to delete the extension key from the list of installed (active) extension. For this you can use any editor. One is build in the InstallTool.
After that you need to remove the cached version of the localconf.php: remove the temp* files in the folder typo3conf/.
Now your system should work again (but still might be unclean).
you should remove the extension (typo3conf/ext/extensionkey).
Maybe there are new tables and fields in the database. Therefore do a database compare in the InstallTool.
What are the recommended steps to upgrade TYPO3 4.5 (or 6.1) to 6.2? I have a mac and my site is running on a shared Linux account.
Here's a step by step guide from my upgrading practice which I would like to share. Thanks for the guide on https://jweiland.net/typo3/vortraege/typo3camp-berlin-2014.html that has helped me a lot.
Note that these are my personal experiences which may or may not apply to your environment. Treat everything carefully.
I differentiate between "Quick" and "Long" upgrades. With "Long" upgrades, you do the upgrading twice. First, you upgrade a copy of the live site, get all extensions and templates working, and when you're ready, you declare the content freeze, re-doing the upgrade, using the files modified in the first step. For a "Quick" upgrade, you declare a content freeze right away, do the upgrade and tests, and then deploy to the test or live environment directly.
Set up the site locally
When you're ready to freeze the content (BE][adminOnly] = 0), don't forget to check if the site has user contributed content? If so, either disable the possibility to submit it, or note which tables you have to re-import after enabling the upgraded site.
Hint:
Work locally. I can only refer to using MAMP Pro (be sure to get the
pro version) on a mac. Always be aware on which site (and with which
DB) you are working, btw! And attention: OS X file system is case
insensitve, which can be a bummer when deploying to Linux (see below).
For the database administration, I prefer http://www.sequelpro.com/ to
phpMyAdmin for most tasks. It's very handy to make backups or to
quickly browse tables, although it has a few missing features in
comparison with phpMyAdmin. It is also extremely reliable for
importing dbs onto a live server - where phpMyAdmin can stall often.
Beware if [SYS][UTF8filesystem] is set: transferring files to OS X via popular (S)FTP clients like Coda or Transmit (haven't tested Cyberduck) can damage the filenames containing UTF-8 filenames. Thus all links to such files will be invalid when you deploy. Pack them into an archive befor transferring or use scp. Avoid the setting in the first place.
Create your local TYPO3 instance. It's practical if you keep an "old" and a "new" core in the same location, so you can switch between them easily by symlink. Create and connect the local database.
Hint:
If you're working on MAMP, you'll have to chown all the files (except
templates and config files of your apps (like Sublime)) to _www:_www.
I have found it useful to define some aliases for the sudo chown in
~/.bash_profile, like alias chownmamp="sudo chown -R _www:_www ."
and vice versa to your own user. Another possibility might be to
temporarily chmod 777 everything - when deploying, taking extra care
this is removed (find . -type f -exec chmod 644 {} \;find . -type d -exec chmod 755 {} \;)
Duplicate the site and the DB to keep an un-upgraded version for comparison - even after you've deployed
Init a local git repo, don't forget to add .gitignore for temp data. Commit from time to time!
Hint:
If you use different hostnames for your local and the live site,
replace them where needed. For the command line, I have found grep -rl 'www.site.ch' ./ | xargs sed -i 's/www.site.ch/www.localsite.dev/g' useful. But of course you can
do that in your IDE or editor too. Don't forget to check
realurl_conf.php and .htaccess too. For a quick run, it is also
possible to use the real hostnames, so you don't have to replace
anything (but won't be able to compare sites from the same machine).
You should now be able to log into the backend and into the install tool
Hint: On MAMP, I've had issues with $TYPO3_CONF_VARS['BE']['warning_email_addr'] which prevented logging into the install tool with an error 500, as it couldn't sent the email. Remove that setting in localconf.php for the local upgrade if it happens.
Prep the upgrade
Make a backup of files and DB. (make frequent db dumps later on too)
Important: Install tool > Database Analyser > Clear Tables: clear all caches, logs, also the history data (if that's ok with you). The less huge the database is, the smoother the upgrade will go.
Get the frontend running.
Also, make sure you have the admin Panel. It's very helpful to override TYPO3 caching and to debug performance bottlenecks. Also, you can reliably force TS rendering at every reload. Set config.admPanel = 1 in page TS, enable it in your admin user's TS by admPanel=1, and log in with the domain you will be viewing the FE from. The adminPanel only shows up if you're logged in on that domain! While you're there, also add options.clearCache.system = 1 to the admin's TS, so you can clear the system cache also when in production mode.
Install http://typo3.org/extensions/repository/view/smoothmigration and run it. Fix the issues you can fix now, e.g. UTF8 issues in the DB. Copy the remaining report and save it in a word file or similar - you can't run smoothmigration after the upgrade anymore
Go through all extensions. Do we need them at all? You can find out if a plugin is used with (for example) SELECT * FROM tt_content WHERE list_type = 'news_pi1' or by looking at all cType = 'list' entries in tt_content. If it's not used, consider removing the extension too. Or can it be replaced by a better extension, or re-built by hand / via tt_content? (For example a carousel, I'd rather not have to maintain an extension for that. But check the budget! Everything takes time.
I get rid of indexed_search, as ke_search is a very reliable alternative that is quick to set up.
Hint: with FAL, the _cli_scheduler user needs rights for every file mount you want to index with ke_search, else the indexing via scheduler will fail.
Main task: Check for extension updates. If a compatible extension update is available, do it. But first check if it works with the old and the new site: http://typo3.org/extensions/repository/view/realurl : This version works for TYPO3 4.5.0 - 6.2.999 - if it doesn't, don't update yet.
Be sure to remove realurl_clearcache, the TER version will break on 6.2
When you're done removing, uninstall all remaining local extensions. You don't have to uninstall sysexts.
in typo3conf/ext we will have a quite short list of extensions now. That is good!
Backup the db and make a DB-Compare in the install tool. CAUTION: don't touch extension data you will need for importing later on (tt_news, powermail, dam). If you dare, you can rename or remove other, 100% obsolete data.
Study the "Reports" module in the BE and take the recommended actions
If you have the patience, check for broken links on the site - they may make problems when converting to FAL.
Is there content / pages that can be deleted for sure? (E.g. ancient test pages, duplicates, etc?) Delete it if you dare.
Don't forget: Empty the trash (Module "Trash") for all pages recursively. No need to migrate deleted content. Cf. https://forge.typo3.org/issues/62360 to delete many items at once
Important: Update the reference index (in the module "DB Check"). It has to be PERFECT before the upgrade.
Make that backup...again
Do the upgrade
-> Switch the core to 6.2
Reload the backend, you will land in the install tool. To connect to the DB, you may have to enter "localhost" instead of 127.0.0.1 as prefilled
Install tool: check folder structure and system environment, make it all green. Read System Environment until the bottom: "Red" items are on the top, but "blue" items (recommended) are on the bottom (e.g. a missing system locale, which is needed if you use UTF8-Filesystem).
Hint: don't be too eager with APC, the availability check
in 6.2 isn't perfect, cf. https://forge.typo3.org/issues/64030 (you
can't use it if your shared hosting relies on suPHP).
Install tool: Run the first wizard. Just the first one. Do NOT run "Migrate all file links of RTE-enabled fields to FAL" yet.
Important: Log into the backend as admin. Go to filelist, refresh the file tree if necessary. Now set the filemounts (fileadmin...) to "Use case sensitive identifiers" in it's settings. Otherwise, you may end up with all filenames in lowercase in sys_file, which will not work on the live linux system.
Also, run the task File Abstraction Layer: Update storage indexin the scheduler and update the reference index.
Install tool: Go through the rest of the upgrade Wizards. To debug broken links that can't be migrated, use the workaround from https://forge.typo3.org/issues/64122 (6.2.10 up)
Hint: If something doesn't seem to be complete after all wizards went through, you can re-enable the upgrade wizards in LocalConfiguration.php under ['INSTALL']['wizardDone']. (Like if the whole sys_file_reference table empty and there are no images in tt_content table - remove the line for TceformsUpdateWizard, so it can run again).
Important: Install tool: All Configuration: Deactivate content adapter! Else you will be running in a slow kind of compatibility mode and not really doing the entire Upgrade.
Check "Reports". Make it all green!
Install tool: Check image rendering (I prefer GD), set fitting Configuration presets
Hint: Check typo3conf/AdditionalConfiguration.php and make sure there are no values in it that override values from LocalConfiguration.php. I've had this on a 6.1->6.2 upgrade, and thus was unable to enable error logs (the devIPmask was overridden all the time).
Main task: Update and install Extensions that have updates that were not compatible with the old core.
Hint: here are a few occasional replacements I had to make
for 6.2 compatibility:
require_once(PATH_tslib . 'class.tslib_pibase.php‘);
-> if (!class_exists('tslib_pibase')) require_once(PATH_tslib . 'class.tslib_pibase.php');
require_once(PATH_t3lib . 'class.t3lib_scbase.php‘);
-> require_once(\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::extPath('backend'). 'Classes/Module/BaseScriptClass.php‘);
t3lib_div::GPvar()
-> \TYPO3\CMS\Core\Utility\GeneralUtility::_GP()
mysql_num_rows($res)
-> GLOBALS['TYPO3_DB']->sql_num_rows($res)
t3lib_div::intInRange
-> t3lib_utility_Math::forceIntegerInRange
t3lib_div::view_array()
-> t3lib_utility_Debug::viewArray
t3lib_div::testInt
-> t3lib_utility_Math::canBeInterpretedAsInteger
EDIT: a much more comprehensive list is on https://github.com/FriendsOfTYPO3/compatibility6/blob/master/Migrations/Code/ClassAliasMap.php
Updating from DAM? Use https://github.com/b13/t3ext-dam_falmigration, following Installation and Scheduler Task and Usage. Be aware that with MAMP, you have to run MAMPs PHP from the command line, for example /Applications/MAMP/bin/php/php5.5.18/bin/php ./typo3/cli_dispatch.phpsh extbase help
Moving tt_news to tx_news? I've had an issue with the importer where not all translations were imported. There is a newer version now.
Updating Powermail? Nice, there is an updater! Thanks! I also encountered issues with translations. In one case, they could be solved by hitting the "localise" button for a form, though.
rlmp_tmplselector: either use https://github.com/jweiland-net/rlmp_tmplselector/ or move page type seletion to core's backend layout.
Hint: In the last case, take care, to select the page template in
accordance to the selected BE Layout, never use .if, always use CASE.
See With TYPO3 be_layout, how to choose frontend template correctly (performance-wise)?
Main Task: Templates have to be updated. Just a few things: New IMAGE / FILES TS, config.doctype=html5 (not html_5), replace all HTML Objects by TEXT. Use the TypoScript Object Browser (TSOB) at least check that there are no errors in TS.
If you haven't done it before ("Long" Upgrade), install extension after extension and fix what has to be fixed (google the errors). Install https://github.com/medialis/realurl_clearcache by hand if you need it.
Do you use imagemap_wizard? https://github.com/lorenzulrich/imagemap_wizard and add the css fix from https://forge.typo3.org/issues/58212
Hint:
Btw, extensions I use on all sites: realurl_clearcache,
nc_staticfilecache, sourceopt, ke_search. On most sites
(feature-based), of course: news, powermail.
Don't forget: Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer). If you have to modify content, use a simulated editor user to spot problems early.
Update Translations via the "Language" Module, so editors will get translated Backend and Extensions
Hint: Also make sure that the "page tree rights" group is properly set
up, cf http://typo3.uni-koeln.de/typo3-admin-access-default.html?&L=0
There may be problems with filenames containing special characters like umlauts, sometimes resulting in broken file links (I use Integrity or Scrutiny for mac to check the whole site), sometimes only in ugly filenames. Check and process manually (if FAL works, you can just rename them in the backend) if required.
Hint:
Here's a snippet I add to all user's userTSConfig.
Go through everything. If you have the time and budget, make the website better, use webpagetest.org to spot performance holes, clean the .htaccess, combine assets, check the page rendering times in the admin tool, update frontend dependencies, check 404 handling, move templates to typo3conf/ext/templates (best search-replace all paths in a dump of the db!), tidy up users and groups, move all templates from db to includes, clean up template structure etc etc - it all depends on the time you have available for that site.
Make the backup. Again.
Test and deploy
Test it on a live server! Or, if it's not a high profile site that can afford some downtime, just go live, moving files (without typo3temp) and db to the server, setting the symlinks, clearing all caches etc.
On the live system, check the install tool. Probably you'll have to adapt some php.ini settings. And set the configuration preset to "Production".
Rebuild the reference index
Check "Reports". Regarding the case sensitivity issue, you might now see missing references here - you haven't seen those on the Mac, as you the file system was case insensitive. Also, you can query sys_file for missing = 1. You could re-run the scheduler FAL task mentionned above locally to see it can fix some filenames. If there are no other means, you could still rename all files to lowercase, cf. How do I rename all files to lowercase?
Check the cronjobs and scheduler tasks (go to "Check configuration" in the scheduler module as well, see if cli user exists). Ah, also see if you're running a current php version. Also check if you don't forbid google to crawl the live version in robots.txt
Do you have to configure some backup routines or update scripts? Do it now.
And don't panic if it's not working yet. Probably it's just the cache. Or something else.
When the site has been running to satisfaction for some time, run another dbcomp and delete all old tables.
Wait. What did I forget? Will add that later.
Check the backend permissions of non-admin users. It may be necessary to add rights for the tables and fields of the FAL (File Abstraction Layer).
In TYPO3, Version 6.1.5, I'd like to split my configuration in typo3conf in three parts:
One part generated by the install-tool, under version control.
One manually managed part, under version control.
One manually managed part, containing server specific stuff, not under version control. Contains e.g. database credentials.
I've tried to do it like this:
is done using LocalConfiguration.php,
is done using AdditionalConfiguration.php
is done by and additional file, included by the AdditionalConfiguration.php.
This does not work, as it seams that the files are evaluated in this order:
LocalConfiguration.php
AddtitionalConfiguration.php
LocalConfiguration.php
So the changes from my server specific file (and AdditionalConfiguration.php) are simple overwritten by the stuff from LocalConfiguration.php.
Any idea how to get around something like this?
First: don't apply any manual changes in your: LocalConfiguration.php file as it will be removed after each operation in the Install Tool, Extension Manager etc.
For adding custom configuration, you should use AddtitionalConfiguration.php file which isn't changed (as probably you know while you are using it). In this additional conf you need to use 'old' syntax for overwriting values, ie:
<?php
$GLOBALS['TYPO3_CONF_VARS']['DB']['database']='some_db_loc';
$GLOBALS['TYPO3_CONF_VARS']['DB']['host']='localhost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['username']='jost';
$GLOBALS['TYPO3_CONF_VARS']['DB']['password']='yourpass';
finally at the end of the additional conf use common include() for including next PHP file in which you can overwrite these values again:
#include('jost_localconf_dont_commit.php');
At least in TYPO3 ver. 6.1.1 this scenario works like a charm.
EDIT: also take a look at Viktor's answer according to accessing the properties in additional config.
BTW: I'm not really sure why you need to commit AdditionalConfiguration.php , IMHO it should be ignored in the git, and on every environment it should have this file filled with local data typical for this env. Main (production) instance should keep whole its config in LocalConfiguration.php
Just one things to add to biesior's answer:
For security reasons, it is even better not to have the DB credentials in AdditionalConfiguration.php. It's better to include a PHP file with the credentials from a path that is outside the document root of the host. Therefore if PHP doesn't work properly, the file cannot be downloaded and the DB credentials are not exposed.