AltoRouter conflicteert met Bootstrap.js

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Donald Boers

Donald Boers

29/09/2018 13:33:14
Quote Anchor link
Voor een meertalige website gebruik ik voor de routing AltoRouterAltoRouter Ik heb AltoRouter voor verschillende andere meertalige websites gebruikt zonder enig probleem. Maar om een of andere reden werkte de navigatie op deze website niet (bij het klikken op een menu-item gebeurde er niets). Sinds gisteravond laat ben ik aan het werk om erachter te komen wat de reden hiervoor zou kunnen zijn. Een voor een heb ik de verschillende plug-ins, stylesheets en andere afhankelijkheden verwijderd en teruggezet als bleek dat deze geen invloed hadden op de werking van de navigatie. Ik heb net de laatste Bootstrap.min.js, verwijderd en het bleek dat dat de boosdoener is. Na het verwijderen werkte de navigatie weer gewoon. Weet iemand wat de reden kan zijn? Ik heb in de console gekeken maar zie tot nu toe niets vreemds.
 
PHP hulp

PHP hulp

22/11/2024 06:11:36
 
- Ariën  -
Beheerder

- Ariën -

29/09/2018 14:01:43
Quote Anchor link
Ik snap de relatie tussen je navigatie(menu?) en AltoRouter niet?
AltoRouter is serverbased en Bootstrap is clientside.
 
Rob Doemaarwat

Rob Doemaarwat

29/09/2018 14:10:36
Quote Anchor link
Maar die AltoRouter is PHP = server-side. Bootstrap is javascript = client-side. Bootstrap kan geen invloed hebben op wat je server-side doet. De navigatie (linkjes?) die je genereert (server-side of client-side) werken dus op de een of andere manier niet meer als je Bootstrap d'r overheen gooit (en daarom wordt er geen call meer naar de server gemaakt, en heeft de AltoRouter dus niks te doen, maar dat is alleen maar een gevolg).

Heb je een live voorbeeld, of kun je anders de resulterende HTML van het menu laten zien?
 
Donald Boers

Donald Boers

29/09/2018 19:37:12
Quote Anchor link
@- Ariën - en @Rob Doemaarwat Ik moet mezelf corrigeren. Was idd niet Bootstrap.min.js dat er voor zorgde dat de navigatie niet werkte. Uit eindelijk blijkt het een conflict te zijn tussen jquery en Bootstrap wat de oorzaak is/was. Want ook als ik jQuery verwijder en Bootstrap laat staan werkt het opeens wel. Hetgeen op zich wel vervelend is daar ik beidde eigenlijk nodig heb
 
- Ariën  -
Beheerder

- Ariën -

29/09/2018 19:53:07
Quote Anchor link
Heb je een voorbeeld?
 
Rob Doemaarwat

Rob Doemaarwat

29/09/2018 21:01:09
Quote Anchor link
Zit jQuery dan al niet in je bootstrap.min.js in (of wordt die eerder al een keer geladen)? Door dubbel laden worden "onload" events die tussen beide keren worden gebonden (soms?) weer verwijderd. Dus zoiets:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<script src="/js/bootstrap.min.js"></script> //incl. jQuery?
<script>
//bind logica voor je menu
</script>
<script src="/js/jquery.min.js"></script> //hierdoor worden voorgaande bindingen ongedaan gemaakt / overschreven

Kan ook zijn dat je een async of defer aan je script bestand hebt hangen, en dat ze niet in de volgorde laden die je in gedachte had.
 
Donald Boers

Donald Boers

29/09/2018 22:34:19
Quote Anchor link
@Rob Doemaarwat. Dank je voor de reactie en tip. Door jQuery na Bootstrap te laden werkt het inderdaad. Hartstikke bedankt helemaal top
 
Donald Boers

Donald Boers

21/10/2018 17:09:48
Quote Anchor link
Ik heb hier nog een aanvullende vraag over. Door het laden van jQuery na Bootstrap werken bepaalde functies inderdaad weer. Maar er zijn nog steeds functionaliteiten die niet naar behoren werken. Nu heb ik in de root een test pagina gemaakt om bepaalde functies te testen , deze bleken echter nog steeds niet te werken. Vervolgens ben ik stap voor stap gaan bekijken waar dit aan kon liggen, en uiteindelijk, althans dat denk ik, bleek het de .htaccess file te zijn die me de nek om doet. Voor de betreffende site (meertalig) ziet de .htaccess er als volgt uit:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
RewriteEngine On

RewriteRule ^([a-z]{2})/(.*)$  index.php?lang=$1&route=$2 [NC,L,QSA]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$  index.php?lang=&route=$1 [NC,L,QSA]


en voor de reguliere websites waar ik aan werk:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

Toen ik op de eerder genoemde test pagina bepaalde functionaliteiten teste werkte deze nog steeds niet. Toen ik echter tijdelijk de .htaccess verving werkte alles zo als het zou moeten. Is er iets in het .htaccess dat ik zou kunnen aanpassen?

Edit het .htaccess file in zijn geheel te vervangen is geen optie, want dan werken de routes niet meer

Alvast bedankt
Gewijzigd op 21/10/2018 17:13:58 door Donald Boers
 
Thomas van den Heuvel

Thomas van den Heuvel

21/10/2018 17:47:14
Quote Anchor link
Als je de logica van de taal nu eens overhevelt naar je applicatie, dan hoef je hier ook geen aparte rewriterule(s) voor te maken die de applicatie ingewikkelder maakt en roet in het eten gooit t.a.v. andere functionaliteit?

Oftewel ontleed $_SERVER['REQUEST_URI'] in je code zelf in plaats van de taal te injecteren in $_GET.
Gewijzigd op 21/10/2018 17:47:47 door Thomas van den Heuvel
 
Donald Boers

Donald Boers

21/10/2018 18:47:52
Quote Anchor link
@Thomas van den Heuvel. Bedankt voor je reactie. Dit is allemaal vrij nieuw voor mij. Het enige file waar momenteel $_SERVER['REQUEST_URI'] in voorkomt is in de AltoRputer class"
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
if($requestUrl === null) {
    $requestUrl = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
}

De server request methode staat ookin deze class
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
if($requestMethod === null) {
     $requestMethod = isset($_SERVER['REQUEST_METHOD']) ? $_SERVER['REQUEST_METHOD'] : 'GET';
}

Hoe zou jij dit anders aanpakken.

Ik sta voor andere suggesties open
Gewijzigd op 21/10/2018 18:48:47 door Donald Boers
 
Thomas van den Heuvel

Thomas van den Heuvel

21/10/2018 22:46:55
Quote Anchor link
Zorg dat je alles gewoon doorstuurt naar de voordeur van je applicatie, doorgaans /index.php.

Vervolgens controleer je hier ergens welke taal je gaat gebruiken. Dit doe je dus in de code zelf, gebruik geen RewriteRules etc. want dat compliceert alles alleen maar.

Het "huiswerk" wat daar ongeveer gedaan zou moeten worden komt min of meer op het volgende neer. Als je meer routing-functionaliteit in je applicatie hebt (waar ik eigenlijk wel vanuit ga) dan zou je daar het een en ander van kunnen lenen. Ook ga ik er vanuit dat je ergens de geselecteerde taal bijhoudt, in het onderstaande fragment ga ik er gemakshalve vanuit dat deze is opgeslagen in $config['lang']. Alle taalgerelateerde zut (iig tav configuratie en navigatie) wordt dan zoiets:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<?php
// init
$validLanguages = array('en', 'nl'); // etc.
$defaultLang = 'en'; // the default language should preferrably not be added in the URL
$config['lang'] = $defaultLang; // default language stored in some configuration - this determines the language used in the application

$uriData = @parse_url($_SERVER['REQUEST_URI']);
if ($uriData === false) {
    die('bad url');
}


$path = '/'; // default path
$pathParts = array(); // default path, in parts

// determine language

if (isset($uriData['path'])) {
    $path = trim($uriData['path'], '/'); // strip leading and trailing slashes
    $pathParts = explode('/', $path);
    if (isset($pathParts[0]) && in_array($pathParts[0], $validLanguages)) {
        $config['lang'] = $pathParts[0]; // overwrite default
    }
}


// swap language?
// if a valid language is set and is not the current language, swap languages

if (isset($_GET['lang']) && in_array($_GET['lang'], $validLanguages) && $_GET['lang'] != $config['lang']) {
    if (isset($uriData['path'])) {
        $path = trim('/', $uriData['path']);
        $pathParts = explode('/', $path);
    }


    // if we swap to the default language, strip language from URL
    if ($_GET['lang'] == $defaultLang) {
        unset($pathParts[0]); // it doesn't matter if it was not set
    } else {
        $pathParts[0] = $_GET['lang']; // replace lang
    }

    // redirect - note that the rest of $_GET will be lost
    $targetPath = '/';
    if (count($pathParts) > 0) {
        $targetPath = '/'.implode('/', $pathParts);
    }

    header($_SERVER['SERVER_PROTOCOL'].' 303 See Other');
    header('Location: '.$targetPath);
    exit;
}

?>

EDIT: verder niet getest dus kunnen nog fouten in zitten, het idee spreekt echter voor zich, lijkt mij.

EDIT: en geef niet nogmaals dit pad mee in $_GET['route'], dat is helemaal niet nodig. In de REQUEST_URI zit alle informatie, hier hoef je $_GET niet (nogmaals) mee te vervuilen. Houd $_GET transparant. Wat de gebruiker in de browser ziet in de querystring is alles wat in $_GET zou moeten/mogen zitten, manipuleer dit het liefst niet of zo min mogelijk aan de serverzijde.
Zo ook: de taal kun je ook uit de URL vissen, die hoef je niet nogmaals in de (serverside) URL te stoppen. $_GET['lang'] zou je wel kunnen gebruiken om tussen talen te schakelen zoals in het bovenstaande codevoorbeeld gebeurt.

EDIT: is je pagina ook voorzien van een base href? Anders wordt mogelijk in de verkeerde directory gezocht naar een javascript-bestand.
Gewijzigd op 22/10/2018 15:01:06 door Thomas van den Heuvel
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.