Ja, jag har stött på en liten myra där "rebuild permissions" stannar på 40% hela tiden. Kikar jag manuellt i node_access-tabellen så är det också lika många rader som byggs efter varje försök. Urpsrungligen hade jag Taxonomy Access Control Lite installerat, men samma problem uppstår även med t.ex. endast ACL installerat. Utan några åtkomstkontrollsmoduler så är det förstås inga problem.
Jag har kikat runt ganska mycket igårkväll (och natt) efter lite lösningar, och det verkar ju finnas många olika bud.
*Jag har kollat igenom min databas så jag inte har några noder utan title, content type eller uid.
*Prövat köra node_access_rebuild(); manuellt genom att lägga in det på en sida med php input filter, då stannar det bara på en helvit sida (wsod?)
*Stängt av sidcachning och andra optimeringsfunktioner under Performance
*Prövat lägga till en debugkod i _node_access_rebuild_batch_operation() men den gör inget nytt vad jag kan se, stannar fortfarande på 40% utan några meddelanden
Jag kör på en shared hosting, så jag har inte åtkomst till ex. kommadolinjeverktyg. PHP-minnet är på 128mb och jag har inte märkt av andra minnesrelaterade problem, så spontant känns inte det som problemet. Mer generellt är det en 6.x-sida, http://www.skillpoint.se
Senast jag vet att det fungerade var nog några månader sedan, när jag behövde bygga om permissions av en annan anledning. Jag tror mig att prövat att inaktivera alla moduler som tillkommit sedan dess.
Är det någon som har några andra smarta förslag hur jag kan lösa detta, eller jaga ned om det är någon eventuell nod/user som orsakar problem?
Comments
Du verkar ha testat det mesta
Du verkar ha testat det mesta och efter en liten googling var en drush-genomkörning mitt bästa tips. Du har kanske möjlighet att dra ner databasen lokalt, följa denna tråden: http://drupal.org/node/498140 och sedan ladda upp databasen igen om det funkade.
Annars har jag tyvärr inget bra råd, har aldrig stött på det här problemet själv.
/Adam
✄-----------------------------------------------------
Adam Evertsson - Came for the code, stayed for the community!
Ja, jag håller på och väntar
Ja, jag håller på och väntar på en SQL-dump av min databas så jag kan testa runt med en lokal kopia. Då kan man ju göra saker man inte vågar på en live-sajt :)
Tack för tipset att pröva Drush på min lokala installation, det hade jag inte tänkt på!
Eftersom du får en vit sida
Eftersom du får en vit sida och eftersom du kommer till 40% varje gång skulle jag gissa på något resursproblem...
128 MB låter lite lite. Men du tror tydligen inte att det är problemet.
Det finns även max exekveringstid som jag har haft problem med några gånger. Du hittar dem här:
http://din.site/admin/reports/status/php
Du hittar värde en bit ner under "Configuration / PHP Core". Det finns två värden. Det du har och det som är globalt. Behöver du ändra dem kan du göra det i din settings.php fil.
Okej, trodde 128 var ganska
Okej, trodde 128 var ganska drägligt tilltaget, men där ser man. Får kika ytterligare på minnet också då, jag är ju verkligen inte villig att utesluta det men det var inte det första jag trodde på. WSODen kommer ju inte när jag kör rebuild "normalt", utan bara via fulvarianten.
Exekveringstiden var ett bra tips, min ligger på 60 (både local och master). Tackar!
Prövade dubbla både minnesmängden och execution time i settings.php och .htaccess men "master"-värdet står ju kvar på det lägre i bägge fallen vilket jag antar är för att jag inte får komma åt php.ini. Så det är väl också något jag får testa lokalt, fungerar endera får jag prata med hostingen och se till att de skruvar till det i så fall.
För alla er som sitter som på
För alla er som sitter som på nålar där ute och undrar hur det går så har jag efter lite om och men satt upp sajten i en virtuell miljö hemma på kammaren (courtesy of Quickstart).
Behövde jag trixa med PHP-inställningar eller Drush? Nej - det funkade på en gång! Tyvärr får man väl säga, för det hjälpte ju inte direkt att lösa problemet med driftsajten.
Att fixa node_access lokalt
Att fixa node_access lokalt och ladda upp den tabellen till driftsajten har åtminstone "fixat" problemet, om än inte "löst" det.
Detta (och lite annat, som några valideringsfel jag dragits med som inte heller dykte upp på testsajten) har dock fått mig att vilja testa ett annat webhotell. Så nu har jag dragit upp ett trial-konto på Manufrog, som man ju hört mycket gott om, för att se om det är värt att migrera till.
Uppdatering: Nu var det en
Uppdatering: Nu var det en klåfingrig redaktionsmedlem som tryckte på "rebuild permissions" så problemet återuppstod.
Den här gången hittade jag dock en riktig lösning på sådär en minut, inte utan att man känner sig lite korkad.
Jag kollade i den halvfärdiga node_access var processen stannat, och kikade till noden efter. Den hade jättemycket embeddade youtube-filmer (via CCK-fält). Gick inte att editera i Drupal (WSOD), så tog bort fälten via PHPMyadmin, så gick processen vidare. Stötte på två till noder som stoppade processen, även de med väldigt många embeddade filmer.
Så kontentan är att det antagligen var ett resursproblem ändå, det blev för mycket att processa för webhotellet.
Tänk på att vi har testkonton
Tänk på att vi har testkonton där du kan utan problem testa din kod samt köra drush/ssh i 14 dagar utan kostnad.
De tas bort automatiskt efter den tiden så slipper du sätta upp hela miljön lokalt.