Uwaga! Od sierpnia 2017 forum jest w trybie tylko do odczytu.

Dlaczego? Dlatego, że społeczność TYPO3 przeniosła się na slack'a i stackoverflow:
  • Przeczytaj artykuł wprowadzający do slacka, w którym dowiesz gdzie i jak się zarejestrować.
  • Jeżeli masz pytania odnośnie Polskiej Społeczności TYPO3 zapraszamy na kanał slack'a #community-pl. Rozmawiamy tam w języku polskim.
  • Pytania dotyczące samego TYPO3 zadawaj po angielsku na stackoverflow oznaczając je tagiem "typo3". Następnie posługując się linkiem do tego pytania postaraj się zachęcić ludzi z kanału slack'a #typo3-cms lub bardziej pasujących kanałów tematycznych, żeby na nie odpowiedzieli.
  • Możesz też oczywiście zadawać pytania na slacku bez zakładania wątków na stackoverflow, ale wówczas wiedza ta nie jest indeksowana przez googla i część osób nie będzie chciała Ci z tego powodu pomagać.
  • Dla części osób dzielących się wiedzą ważne jest też budowanie reputacji na stackoverflow. Jest to kolejny powód dla którego powinieneś zadawać pytania na stackoverflow by zwiększyć swoje szanse na znalezienie odpowiedzi. Pamiętaj, żeby oceniać odpowiedzi!
Forum » TYPO3 » Ogólne
Temat z wieloma odpowiedziami

6.2 i localconf


Autor Wiadomość
Napisane: 22.01.2015 [20:48]
wolo
Twórca tematu
zarejestrowany: 04.09.2007
Posty: 26
Witam
W szóstce zmienił się główny localconf. Od zawsze trzymałem w nim jakieś rzeczy, w rodzaju definicji stałych DEV czy LOCAL, redirect z www, czy switch ustawiający odpowiednie dostępy do bazy w zależności od środowiska... Teraz to wszystko jest z LocalConfiguration automatycznie kasowane przez install tool, nawet komentarze :/ nie można już zanotować sobie lub wykomentować tymczasowo jakichś opcji, bo za chwilę wszystko znienacka znika.
Czy ktoś potrafi mi wytłumaczyć, jak się teraz robi takie rzeczy, gdzie można dodawać taki niskopoziomowy kod, jeśli nie tu? Jak mogę zrobić osobne konfiguracje w zależności np. od subdomeny, tak jak to można było łatwo zrobić do tej pory?
Oraz czemu to musi być tak kretyńsko rozwiązane, jak to zrobiono tutaj?

`Well! I've often seen a cat without a grin,` - thought Alice, `but a grin without a cat! It's the most curious thing I ever saw in all my life!`
Napisane: 11.02.2015 [03:02]
kss
zarejestrowany: 19.07.2007
Posty: 1341

Teraz jest to zrobione lepiej niż było icon_smile.gif

W 6+ z automatu wczytywany jest plik AdditionalConfiguration.php
Jeżeli chcesz nadpisać tam wartości z LocalConfigration to używaj już
$GLOBALS['TYPO3_CONF_VARS']...... =

Sprawdź też podejście przedstawione tutaj. Dobre bo pozwala na trzymanie w git AdditionalConfiguration zależnych od kontekstu.
https://github.com/georgringer/TYPO3.base/tree/master/typo3conf



=======================================
t33k
Napisane: 13.02.2015 [09:26]
wolo
Twórca tematu
zarejestrowany: 04.09.2007
Posty: 26
Dzięki Krystianie, faktycznie coś takiego jest, przy update się tworzy, a na nowej instalacji plik mi się nie pojawił.

Jeśli nie zawracam dupy, to mam jeszcze garść pytań i narzekań, apropo mojej spóźnionej migracji 4 -> 6.
Jedno z nich:
- gdzie jest teraz "get extension updates" z ext managera, który fajnie pokazywał listę wszystkich extów możliwych do aktualizacji? Rozumiem, że jest to teraz rozwiązane tak, że po Update list na liście Manage exts pojawia się po prostu ikonka update przy danym. Ale ta ikonka pojawia się tam nie zawsze - prawdopodobnie system sprawdza dependencies. Efekt jest taki, że mając starą Templavoilę 1.8, a najnowsza to 2.0, nie pokazuje mi się ten przycisk - zapewne dlatego, że ta wersja jest tylko pod Typo 7...
Wobec tego nie mam w ogóle możliwości zaimportowania - ostatniej kompatybilnej z 6 (LTE...) templavoili 1.9.2 - poprzez extension manager, tak jak to było dawniej.

Czy ja czegoś nie widzę, czy to następna durna nieprzemyślana rzecz, i muszę wszystkie exty prześledzić ręcznie czytając każdego emconf i zastanawiając się, czy może na repo jest inna wersja dla 6.2....? :\

Mam wrażenie, że od Typo 3.8 do 4.5 extension manager działał super, a potem z wersji na wersję jest coraz bardziej nieużyteczny.


[Ten temat był edytowany 2 razy. Ostatnio 13.02.2015 o 11:39.]

`Well! I've often seen a cat without a grin,` - thought Alice, `but a grin without a cat! It's the most curious thing I ever saw in all my life!`
Napisane: 13.02.2015 [23:32]
kss
zarejestrowany: 19.07.2007
Posty: 1341

Można.

Wejdź w "Get Extensions"
Odszukaj kolumnę Versions.
Wersja jest klikalna - możesz wybrać dowolną i zaimportować.

Co do EM to faktycznie tak było, że pewna osoba zaczęła go przerabiać na huurra i efekty był marny.
W 6.2 przepisano go jeszcze raz od nowa bardzo go upraszczając.




=======================================
t33k
Napisane: 22.02.2015 [20:13]
tomkraw1
admin
zarejestrowany: 14.07.2008
Posty: 530
Wtrącę się w kwestii localconfa.
Chyba od 6.2 wprowadzono TYPO3_CONTEXT. Już w .htaccess wstawiam

PHP
SetEnv TYPO3_CONTEXT Development
#SetEnv TYPO3_CONTEXT Production


i dalej czytam w AdditionalConfiguration.php
PHP
if ($GLOBALS['TYPO3_CONF_VARS']['SYS']['applicationContext'] == 'Development' ) {
 
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = 1;
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['devIPmask'] = 'x.y.z.q,127.0.0.1';
(...)


oraz w TypoScript
TYPOSCRIPT
[applicationContext = Development, Testing]
config {
	debug = 1
(...)


Całkiem użyteczne.

pozdrawiam
Tomek
Napisane: 10.04.2015 [12:41]
wolo
Twórca tematu
zarejestrowany: 04.09.2007
Posty: 26
Wybaczcie, że odgrzebię.

- Rzeczywiście ten sposób z AdditionalConfiguration po czasie jest całkiem niezły, przyznaję.

- Context. Ja wolę jednak dawny sposób Ryżego z constantsami w localconfie:
PHP
define('LOCAL', intval(
	preg_match('/(localhost)/', $_SERVER['HTTP_HOST'])
));
define('DEV', intval(
	preg_match('/(dev\.)/', $_SERVER['HTTP_HOST'])
	||	LOCAL
));
putenv("DEV=".intval(DEV)); // make them available from TS: [globalVar= ENV: DEV=1]
putenv("LOCAL=".intval(LOCAL));
...
if (LOCAL)  {
	$GLOBALS['TYPO3_CONF_VARS']['DB']['host'] = '127.0.0.1'; ....

Prosty, szybki, elastyczny i w jednym miejscu. Łatwo w kodzie użyć warunku typu if (DEV) itd zamiast tego długiego wywołania. Łatwo można zdefiniować takich environmentów choćby i trzysta, a o ile pamiętam, z applicationContext są z tym jakieś schody. Może ma to jakieś inne zalety, ale doc core api na ten temat milczy.

- Z Templavoilą chodziło mi o to, że owszem jest tak taki selektor, ale trzeba dokładnie sprawdzić, która wersja będzie u nas działać, bo dependencies z em_conf em olał i zainstalował mi wersję 7-only. Bo taką znalazł najnowszą.

- Skoro zniknęła opcja extList z localconfa na rzecz PackageStates, odpadła nam ważna możliwość - warunku na context właśnie. Chyba, że da się jakoś inaczej odpalić jakiś ext np. tylko na dev?

- I rzecz, o którą właściwie chciałem spytać wchodząc tutaj.
Są 3 lokalizacje rozszerzeń: systemowe (typo3/sysext), globalne (typo3/ext) i lokalne (typo3conf/ext).
Dokumentacja mówi to, co właściwie wiadomo:
"Loading precedence
Local extensions take precedence which means that if an extension exists both in typo3conf/ext/ and typo3/ext/ the one in typo3conf/ext/ is loaded. Likewise global extension takes precedence over system extensions. This means that extensions are loaded in the order of priority local-global-system."

Sytuacja:
Potrzebowałem przerobić ext sysext/felogin, bo nie dało się osiągnąć hookami pewnych rzeczy. Więc skopiowałem go do typo3conf, przerobiłem i oczywiście nie zadziałało.
Znalazłem więc w PackageStates opcję 'packagePath', którą ręcznie zmieniłem na 'typo3conf/ext/felogin/'.
Ext ruszył, wszystko super. Do pierwszej instalacji czegoś przez ext manager - plik zostaje nadpisany, wartości domyślne i znów nie działa. Za każdym razem. Dzieje się tak w bodaj około wersji 6.2.7 - 10.
Jakieś pomysły, czemu tak jest i jak go zmusić do moich ustawień bez nadpisania exta w oryginalnej lokalizacji?

[edit] Jeszcze jedno icon_smile.gif
Czy ktoś jest mi w stanie sensownie wyjaśnić, po jaką cholerę w każdej jednej nazwie tabeli dla extów typu extbase musi się znajdować "_domain_model_"? Strasznie jest to wygodne w przeglądaniu bazy... Nie rozumiem, co to ma na celu i co daje wymuszenie tego, poza trzymaniem się na upartego jakiejś konwencji.
Osobiście wydaje mi się, że porządki w kodzie porządkami, ale nieraz zostało to posunięte za daleko, jak np. wydłużanie wszelkich nazw i wywołań do granic szerokości ekranu, w stylu RTE.default.buttons.blockstyle.tags.div.allowedClasses. Co komu przeszkadzało RTE.default.classesParagraph?
RTE.Możemy.tu.napisać.co.nam.przyjdzie.do.głowy.bo.mamy.dużo.czasu.i.miejsca.na.ekranie.dopiszę.jeszcze.trochę.bo.za.krótkie... Tak to widzę.

[Ten temat był edytowany 2 razy. Ostatnio 10.04.2015 o 12:55.]

`Well! I've often seen a cat without a grin,` - thought Alice, `but a grin without a cat! It's the most curious thing I ever saw in all my life!`
Napisane: 11.04.2015 [13:08]
kss
zarejestrowany: 19.07.2007
Posty: 1341
To czego szukasz to w AdditionalConfiguration.php:

$GLOBALS['TYPO3_CONF_VARS']['EXT']['runtimeActivatedPackages'] = array('{packageKey}')

Packages that gets initialized right after the package management initialization.

=======================================
t33k
Napisane: 11.04.2015 [13:17]
kss
zarejestrowany: 19.07.2007
Posty: 1341

A odnośnie swoich patentów na wszystko to IMO lepiej jest używać standardowych jeżeli zamierzasz współtworzyć serwis z wieloma osobami i zostawić go na jakimś sensownym poziomie upgradowalności.

Być może patent, który wykombinujesz jest lepszy o 20% niż standard, ale nikt go nie zna i czas potrzebny na wejście dodatkowego developera w rozwiązanie się wydłuża a dodatkowo zawsze jest ryzyko, że własne patenty nie będą wspierane przez wyższe wersje TYPO3, bo nikt nie się nimi nie przejmuje.

Przerabiałem to ze swoimi patentami. Teraz nie używam już żadnych. Ciągnę na core.

=======================================
t33k
Napisane: 11.04.2015 [14:36]
wolo
Twórca tematu
zarejestrowany: 04.09.2007
Posty: 26
Ta metoda nie stoi w konflikcie z core'owym, w takiej sytuacji zmieniam preg_match na:
define('DEV', intval(
$GLOBALS['TYPO3_CONF_VARS']['SYS']['applicationContext'] == 'Development'
));
i nadal wszystko działa.

`Well! I've often seen a cat without a grin,` - thought Alice, `but a grin without a cat! It's the most curious thing I ever saw in all my life!`
Napisane: 11.04.2015 [15:26]
kss
zarejestrowany: 19.07.2007
Posty: 1341
Akurat ten patent który przedstawiłeś jest mały, ale pewnie masz inne patenty bardziej ingerujące w cora icon_smile.gif

Moja uwaga była bardziej do ogólnego "nadpisywania" standardowych rozwiązań swoimi własnymi.

Jako przykład. Mamy parę spadkowych wdrożeń po dużej agencji z Niemiec. Zrobiła ona exta, którego instalowali standardowo w każdej z ich instalacji TYPO3. Ext ten nadpisywał z 10% cora. Wsadzili tam takie ficzery jak autowczytywanie cssów z folderu, auto łączenie css/js, i masę innych rzeczy, które miały ułatwiać development wg ich ustalonej ścieżki (min. ingerowali też w sposób działania extbase / storage folder / określanie akcji do wykonania itp). Był również patent z łączeniem TS w jeden plik (sic!).

No i teraz horror. Część z tych patentów nie działa na instancjach lokalnych (tu przewaga cora, który jest jednak przetestowany znacznie lepiej niż autorskie poprawki). Druga cześć patentów po upgrade TYPO3 też leży. Wywala nawet zwykły upgrade powermaila.

Na jednej z instancji po prostu odinstalowaliśmy ten ext i straciliśmy z 8h, żeby przystosować rozwiązanie do standardowych metod. Powiodło się - wszystko działało bez zarzutu. Wniosek - cały ext jest zbędny.

Takie ulepszacze dają złudny przyrost prędkości. Być może sam development TYPO3 jest z nim szybszy o kilkanaście procent, ale później traci się czas przy upgradzie rozwiązania i wdrożeniu w nie nowych developerów.

Żeby było jasne - nie chodzi mi o ten konkretny patent, który przedstawiłeś - raczej o tendencję do ulepszania core na siłę.

=======================================
t33k