[RISOLTO] Modifica degli utenti non funziona

22 contenuti / 0 new
Ultimo contenuto
[RISOLTO] Modifica degli utenti non funziona

Ciao sono un nuovo utente, ben trovati nel vostro utilissimo sito!
Mi serve un aiuto tecnico se possibile sperando di non aver sbagliato la sezione del forum.
Il mio sito www.anarchia.info è costruito con drupal 6.17 su template "newsflash" da me modificato a livello di css. Il sito risiede su server Aruba, semplice server, non dedicato, che mi da un unico problema (per il resto il sito risulta veloce e performante): non posso accedere alla sezione modifica degli utenti registrati ... mi spiego: se mi logo come amministratore (super admin) e voglio cambiare user e/o password di un utente registrato al sito (Gestione utente -> Utenti) NON posso farlo perché cliccando su "modifica" la pagina "gira" su se stessa e rimane dov'era. In pratica non và alla pagina di modifica... rimane in http://www.miosito.info/admin/user/user (dov'era prima). Se invece clicco sul nome dell'utente (http://www.miosito.info/users/TizioCaio) vado sul suo profilo ma anche qui se clicco sul tab "modifica" (http://www.miosito.info/user/2/edit) firefox mi dà: "Questa pagina non reindirizza in modo corretto. Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata. Questo problema spesso è causato dal blocco o dal rifiuto dei cookie.". Ovviamente i cookie sono abilitati! Ho provato con tutti i browser maggiormente presenti.
Mi è impossibile anche modificare me stesso, la mia password che risulta modificabile solamente direttamente dal database.
Per me forse si tratta (forse) di modificare qualcosa nel file .htaccess per fare in modo che al click su "modifica" la pagina venga reindirizzata nel giusto modo. Ad ora non sono riuscito a risolvere. Ho anche ricostruito i permessi dei file e cartelle pensando che qualche file fosse in sola lettura senza che doveva esserlo ... ma nulla.
In locale, su server Xampp tutto funziona ma spostando il file .htaccess del locale sul server aruba mi da errore ed il sito non risulta visibile. Ovviamente ho provato tutti gli .htaccess che andrebbero bene per aruba (conosco i problemi di aruba per ciò che concerne .htaccess).
Ho anche letto moltissimo il forum di drupalitalia.org così come tutto ciò di “trovabile” in google, ma non ho ancora una soluzione.
Ho anche controllato le tabelle del database mysql ma mi sembra tutto a posto anche se non sono un esperto di database mysql.
Ho aggiornato tutti i moduli aggiuntivi e ho provato a cambiare template ma niente non funziona! Gli utenti si possono registrare ma io non ho il controllo della loro password o username.
Per ora nel nostro sito, non sono previsti utenti anonimi per quanto riguarda i commenti ai contenuti.
Ciao

Nella pagina utenti->permessi come sono impostati i permessi di modulo user?

________________________________________________________________________________________
Quando risolverai il problema, scrivi come hai fatto, e se puoi scrivi [RISOLTO]
Sarà utile ad altri. Grazie
enzoazzolini.it

Ciao,
grazie per la risposta,
penso che quando è il super admin ad agire sul sito dovrebbe avere tutti i permessi aperti a prescindere da quelli settati sull’area “permessi”…. Comunque i miei settaggi sono:
Accede ai profili utente -> tutto disattivato
Amministra permessi -> tutto disattivato
Amministra utenti -> tutto disattivato
Cambia il tuo nome utente -> attivato utente autenticato
Ciao

Nessun’altra idea?
Il seguente è il mio file .htaccess nella root del sito:

#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
  Order allow,deny
</FilesMatch>
# Don't show directory listings for URLs which map to a directory.
# Options -Indexes
# Follow symbolic links in this directory.
# Options +FollowSymLinks
# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php
# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
  # There is no end quote below, for compatibility with Apache 1.3.
  ErrorDocument 404 "The requested file favicon.ico was not found.
</Files>
# Set the default handler.
# DirectoryIndex index.php
# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.
# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value memory_limit 128M
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>
# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On
  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600
  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on
  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # adapt and uncomment the following:
  # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment and adapt the following:
  RewriteCond %{HTTP_HOST} ^www\.anarchia\.com$ [NC]
  RewriteRule ^(.*)$ http://anarchia.info/$1 [L,R=301]
  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /
  # Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
RewriteCond %{HTTP_HOST} ^sito\.com$ [NC]
RewriteRule ^(.*)$ http://www.anarchia.info/$1 [L,R=301]
# $Id: .htaccess,v 1.90.2.4 2009/12/07 12:00:40 goba Exp $

L’altro .htaccess è in sites/default/files con le stringhe: # SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
# Options None
# Options +FollowSymLinks
Come vedete sono disattivate così come aruba vuole.
Ciao

Quote:
Questa pagina non reindirizza in modo corretto. Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata

Il messaggio mi insospettisce.
In un mio vecchio file .htaccess di Aruba ho visto che avevo impostato la riga
# RewriteBase /
alla fine del file senza commento, ma non ricordo perchè lo avessi fatto e se servisse.
(Sempre annotarsi perchè si fanno le cose!)
Poi aruba lo abbandonai. Magari prova a togliere quel commento ....

________________________________________________________________________________________
Quando risolverai il problema, scrivi come hai fatto, e se puoi scrivi [RISOLTO]
Sarà utile ad altri. Grazie
enzoazzolini.it

Ho provato a decommentare RewriteBase / ma niente: la modifica utenti continua non funzionare!
Penso RewriteBase / indichi solamente che il sito è installato nella root … ma anche prima andava bene!
Ciao.

Ho fatto l’ugrade alla versione 6.19, che è andato tutto bene, come spiego in www.drupalitalia.org/node/11503 ma nessun miglioramento per la modifica degli utenti registrati … il problema permane.
Ciao

Mi sembra di capire che non puoi cambiare il password di un utente perchè non riesci ad accedere alla pagina di editing, giusto?
Succede con altri pagine di amministrazione?

Cambia qualcosa se disabiliti clean URLS (admin/settings/clean-urls)? Togliendo Clean URLs fa che non scatena nessun regole Apache nel .htaccess.

Il file .htaccess che hai pubblicato ha qualche 'errore':

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On
  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600
  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

Sui siti Aruba che ho io, dopo l'ultima 'miglioramento' da parte del provider, io ho dovuto commentare tutto questo sezione, altrimenti errore 500. Ma credo che saresti accorto se dava errore anche a te...

  # uncomment and adapt the following:
  RewriteCond %{HTTP_HOST} ^www\.anarchia\.com$ [NC]
  RewriteRule ^(.*)$ http://anarchia.info/$1 [L,R=301]

Questo non fa niente. www.anarchia.com sta su un altro IP (213.175.207.24) da www.anarchia.info (62.149.140.125)

RewriteCond %{HTTP_HOST} ^sito\.com$ [NC]
RewriteRule ^(.*)$ http://www.anarchia.info/$1 [L,R=301]
# $Id: .htaccess,v 1.90.2.4 2009/12/07 12:00:40 goba Exp $

Oltre ad essere fuori della chiusura di regole rewrite (<IfModule mod_rewrite.c>) anche sito.com ha un altro IP.

HTH

John

Più imparo, più dubito.

jhl.verona wrote:
Mi sembra di capire che non puoi cambiare il password di un utente perchè non riesci ad accedere alla pagina di editing, giusto?
Succede con altri pagine di amministrazione?

No!

jhl.verona wrote:
Cambia qualcosa se disabiliti clean URLS (admin/settings/clean-urls)? Togliendo Clean URLs fa che non scatena nessun regole Apache nel .htaccess.

Ho provato e non cambia nulla. Problema permane!
jhl.verona wrote:
Il file .htaccess che hai pubblicato ha qualche 'errore':

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On
  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600
  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

Sui siti Aruba che ho io, dopo l'ultima 'miglioramento' da parte del provider, io ho dovuto commentare tutto questo sezione, altrimenti errore 500. Ma credo che saresti accorto se dava errore anche a te...

Non ho provato dato che non ho errori 500.

jhl.verona wrote:
  # uncomment and adapt the following:
  RewriteCond %{HTTP_HOST} ^www\.anarchia\.com$ [NC]
  RewriteRule ^(.*)$ http://anarchia.info/$1 [L,R=301]

Questo non fa niente. www.anarchia.com sta su un altro IP (213.175.207.24) da www.anarchia.info (62.149.140.125)

Ho provato a sostituire ^www\.anarchia\.com$ con ^www\.anarchia\.info$ e stranamente il sito NON va più ... firefox dice: "Questa pagina non reindirizza in modo corretto
Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata." PERCHE'???

jhl.verona wrote:
RewriteCond %{HTTP_HOST} ^sito\.com$ [NC]
RewriteRule ^(.*)$ http://www.anarchia.info/$1 [L,R=301]

Avevo di già corretto con anarchia.info\.com$
# $Id: .htaccess,v 1.90.2.4 2009/12/07 12:00:40 goba Exp $

jhl.verona wrote:
Oltre ad essere fuori della chiusura di regole rewrite (<IfModule mod_rewrite.c>) anche sito.com ha un altro IP.

Ti puoi spiegare meglio, per favore?
Comunque grazie dei tuoi suggerimenti!
Ciao

Ci sono due problemi qui. Prima l'editing degli utenti:

hyme wrote:
jhl.verona wrote:
Mi sembra di capire che non puoi cambiare il password di un utente perchè non riesci ad accedere alla pagina di editing, giusto?
Succede con altri pagine di amministrazione?

No!

No alla seconda domanda, presumo.
hyme wrote:
jhl.verona wrote:
Cambia qualcosa se disabiliti clean URLS (admin/settings/clean-urls)? Togliendo Clean URLs fa che non scatena nessun regole Apache nel .htaccess.

Ho provato e non cambia nulla. Problema permane!

OK, quindi non c'entra Apache o .htaccess. Forse è un problema del record di menu. Hai detto sopra che in locale tutto funziona. Presumo però che non hai copiato il db da locale al server su aruba, ma che hai semplicemente replicato il lavoro sul server (correggimi se sbaglio).

Prima qualche domanda:

  1. ?q=user/1 ti porta alla pagina del superuser? (Penso di si)
  2. ?q=user/1/edit ti porta alla pagina di editing del superuser? (Penso di no)
  3. ?q=user/1/edit/account ti porta alla pagina di editing del superuser? (Forse...)

Prova andare in ?q=admin/build/modules e (senza cambiare niente) cliccare su 'Salva configurazione' - questo dovrebbe ricostruire il menù del ruoter (che salva gli percorsi tipo user/%/edit nel DB).

Altrimenti dovremmo smanettare un pò il DB stesso.

Per quanto riguarda il secondo problema (il file .htaccess):

hyme wrote:
jhl.verona wrote:
Il file .htaccess che hai pubblicato ha qualche 'errore':

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On
  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600
  <FilesMatch \.php$>
    # Do not allow PHP scripts to be cached unless they explicitly send cache
    # headers themselves. Otherwise all scripts would have to overwrite the
    # headers set by mod_expires if they want another caching behavior. This may
    # fail if an error occurs early in the bootstrap process, and it may cause
    # problems if a non-Drupal PHP file is installed in a subdirectory.
    ExpiresActive Off
  </FilesMatch>
</IfModule>

Sui siti Aruba che ho io, dopo l'ultima 'miglioramento' da parte del provider, io ho dovuto commentare tutto questo sezione, altrimenti errore 500. Ma credo che saresti accorto se dava errore anche a te...

Non ho provato dato che non ho errori 500.

Buon per te. Puoi ignorare quello che ho scritto prima allora.

hyme wrote:
jhl.verona wrote:
  # uncomment and adapt the following:
  RewriteCond %{HTTP_HOST} ^www\.anarchia\.com$ [NC]
  RewriteRule ^(.*)$ http://anarchia.info/$1 [L,R=301]

Questo non fa niente. www.anarchia.com sta su un altro IP (213.175.207.24) da www.anarchia.info (62.149.140.125)

Ho provato a sostituire ^www\.anarchia\.com$ con ^www\.anarchia\.info$ e stranamente il sito NON va più ... firefox dice: "Questa pagina non reindirizza in modo corretto
Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata." PERCHE'???


Perchè c'è già un comando (credo fornito da aruba stesso, non nel .htaccess) che converte anarchia.info in www.anarchia.info. Questo ho provato non mettendo il www. per il tuo sito - mi manda a http://www.anarchia.info
Se però tu aggiungi la regola inverso allora hai creato un ciclo infinito - uno aggiunge il www. l'altro lo toglie. Ed entrambe reinidirizzono...
Con aruba non puoi vincere, quindi cancella quei due righe e lascia che anarchia.info va a www.anarchia.info

hyme wrote:
jhl.verona wrote:
RewriteCond %{HTTP_HOST} ^sito\.com$ [NC]
RewriteRule ^(.*)$ http://www.anarchia.info/$1 [L,R=301]

Avevo di già corretto con anarchia.info\.com$
# $Id: .htaccess,v 1.90.2.4 2009/12/07 12:00:40 goba Exp $

jhl.verona wrote:
Oltre ad essere fuori della chiusura di regole rewrite (<IfModule mod_rewrite.c>) anche sito.com ha un altro IP.

Ti puoi spiegare meglio, per favore?

Senza scrivere un mio solito libretto, no.

  1. La regola è nel posto sbagliato
  2. La regola è sbagliato
  3. Sono due sbagli che non si compensano ;-)

Leva quei due righe e basta (fidati, ma fai anche un backup del file)

John

Più imparo, più dubito.

Prima qualche domanda:
1. ?q=user/1 ti porta alla pagina del superuser? (Penso di si)
2. ?q=user/1/edit ti porta alla pagina di editing del superuser? (Penso di no)
3. ?q=user/1/edit/account ti porta alla pagina di editing del superuser? (Forse...)

1. Si
2. NO … firefox mi dice: “Questa pagina non reindirizza in modo corretto Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata.”
3. NO … stessa situazione del punto 2 con stesso messaggio di firefox.

Prova andare in ?q=admin/build/modules e (senza cambiare niente) cliccare su 'Salva configurazione' - questo dovrebbe ricostruire il menù del ruoter (che salva gli percorsi tipo user/%/edit nel DB).
Fatto! Problema rimane!
Ho tolto le due righe che mi dicevi nel file .htaccess: Tutto bene il sito reindirizza anarchia.info => www.anarchia.info.
Mi sà che dovremmo aggire sul database.
Grazie
Ciao

hyme wrote:
Prima qualche domanda:
1. ?q=user/1 ti porta alla pagina del superuser? (Penso di si)
2. ?q=user/1/edit ti porta alla pagina di editing del superuser? (Penso di no)
3. ?q=user/1/edit/account ti porta alla pagina di editing del superuser? (Forse...)

1. Si
2. NO … firefox mi dice: “Questa pagina non reindirizza in modo corretto Firefox ha rilevato che il server sta reindirizzando la richiesta per questa pagina in modo che non possa mai essere completata.”
3. NO … stessa situazione del punto 2 con stesso messaggio di firefox.


OK. Come immaginavo...

hyme wrote:
Prova andare in ?q=admin/build/modules e (senza cambiare niente) cliccare su 'Salva configurazione' - questo dovrebbe ricostruire il menù del ruoter (che salva gli percorsi tipo user/%/edit nel DB).
Fatto! Problema rimane!
Ho tolto le due righe che mi dicevi nel file .htaccess: Tutto bene il sito reindirizza anarchia.info => www.anarchia.info.
Mi sà che dovremmo aggire sul database.

Not yet! Prova invece ?q=admin/build/themes e (senza cambiare niente) cliccare su 'Salva configurazione' - anche lui lo ricostruisce...

Altrimenti vedremo cosa fare domani...

John

Più imparo, più dubito.

Ho fatto come dici (?q=admin/build/themes) senza cambiare nulla ... Non è cambiato niente tutto come prima.
Quando puoi interveniamo sul database.
Ciao e grazie ancora!

Per curiosità:

  1. ?q=user/1/contact funziona?
  2. ?q=user/1/view funziona?
  3. ?q=user/1/delete funziona? (non cancella subito, ma va alla pagina di confirma)
  4. ?q=user/vatelapesca va sulla pagina 404? (questo è importante, credo)

Stai usando qualche modulo particolare per l'utenti, tipo LoginToboggan o User Protect?

Va bene. Prima di tutto bisogna fare un backup del DB (non si sa mai).
Poi controlliamo l'URL user/%/edit faccendo il query:
SELECT * FROM `drupal_menu_router` WHERE path LIKE "user/%/edit"
(Aruba mi ha aggiunto il prefisso 'drupal_' la tabella di solito si chiama 'menu_router'.)
Ci dovrebbe essere solo un risultato - in formatto Yaml, il risultato da me è:

%YAML 1.1
---
# Sqlxxxxxx_x.drupal_menu_router
-
  path: user/%/edit
  load_functions: a:1:{i:1;a:1:{s:18:"user_category_load";a:2:{i:0;s:4:"%map";i:1;s:6:"%index";}}}
  to_arg_functions:
  access_callback: user_edit_access
  access_arguments: a:1:{i:0;i:1;}
  page_callback: user_edit
  page_arguments: a:1:{i:0;i:1;}
  fit: 5
  number_parts: 3
  tab_parent: user/%
  tab_root: user/%
  title: Edit
  title_callback: t
  title_arguments:
  type: 128
  block_callback:
  description:
  position:
  weight: 0
  file: modules/user/user.pages.inc
...

Se non hai questo, o è diverso, puoi cancellarlo e lascia Drupal a ricostruirlo, sempre andando in ?q=admin/build/themes e (senza cambiare niente) cliccare su 'Salva configurazione'

Se invece il tuo db è identico, il problema sta altrove, e richiede un indagine più approfondito...

Più imparo, più dubito.

Ciao,
Per rispondere alle domande fatte da te:
1. ?q=user/1/contact funziona? SI
2. ?q=user/1/view funziona? SI và in nella pagina dell’user come quando entro come superadmin.
3. ?q=user/1/delete funziona? (non cancella subito, ma va alla pagina di confirma) SI
4. ?q=user/vatelapesca va sulla pagina 404? (questo è importante, credo) mi dice: “Pagina non trovata. La pagina richiesta non è stata trovata”. Ma non mi dice errore 404 e i menù primari e secondari spariscono.

La mia tabella drupal_menu_router è:

# Sqlxxxxxx_x.drupal_menu_router
path: user/%/edit
  load_functions: a:1:{i:1;a:1:{s:18:"user_category_load";a:2:{i:0;s:4:"%map";i:1;s:6:"%index";}}}
  to_arg_functions:
  access_callback: user_edit_access
  access_arguments: a:1:{i:0;i:1;}
  page_callback: user_edit
  page_arguments: a:1:{i:0;i:1;}
  fit: 5
  number_parts: 3
  tab_parent: user/%
  tab_root: user/%
  title: Edit
  title_callback: t
  title_arguments:
  type: 128
  block_callback:
  description:
  position:
  weight: 0
  file: modules/user/user.pages.inc

Penso sia uguale al tuo.
Ciao

Si infatti sembra identico.

Allora, avanti. Forse hai un problema di alias. Prova eseguire la query:
SELECT * FROM drupal_url_alias d where src LIKE "user/%"
Ci sarà qualche record, ma non dev'essere uno con src == "user/%/edit"

Se non dà frutti quello, entriamo in sala operatoria (guanti, maschera e pazienza...)
Nel file includes/menu.inc c'è una funzione menu_get_item alla riga 302 circa. Quel funzione (che è risponsabile per abbinare l'URL con un unico record nella tabella menu_router) finisce con:

    $router_items[$path] = $router_item;
  }
  return $router_items[$path];
}

Aggiungi le righe:
if($path == 'user/1/edit') {
  print('<pre>'. print_r($ancestors, TRUE) .'</pre>');
  print('<pre>'. print_r($router_item, TRUE) .'</pre>');
  exit();
}

così finisce con:
if($path == 'user/1/edit') {
  print('<pre>'. print_r($ancestors, TRUE) .'</pre>');
  print('<pre>'. print_r($router_item, TRUE) .'</pre>');
  exit();
}
    $router_items[$path] = $router_item;
  }
  return $router_items[$path];
}

Copiare il file modificato sul server aruba tramite FTP, poi vai alla pagina ?q=/user/1/edit dovrebbe aparire del testo (e niente tema normale), da me viene fuori:
Array
(
    [0] => user/1/edit
    [1] => user/1/%
    [2] => user/%/edit
    [3] => user/%/%
    [4] => user/1
    [5] => user/%
    [6] => user
)
Array
(
    [path] => user/%/edit
    [load_functions] => Array
        (
            [1] => user_category_load
        )
    [to_arg_functions] =>
    [access_callback] => user_edit_access
    [access_arguments] => a:1:{i:0;i:1;}
    [page_callback] => user_edit
    [page_arguments] => Array
        (
            [0] => stdClass Object
                (
                    [uid] => 1
                    [name] => admin
                    ...snip...
                )
        )
    [fit] => 5
    [number_parts] => 3
    [tab_parent] => user/%
    [tab_root] => user/%
    [title] => Modifica
    [title_callback] => t
    [title_arguments] =>
    [type] => 128
    [block_callback] =>
    [description] =>
    [position] =>
    [weight] => 0
    [file] => modules/user/user.pages.inc
    [href] => user/1/edit
    [options] => Array
        (
        )
    [access] => 1
    [localized_options] => Array
        (
        )
    [map] => Array
        (
            [0] => user
            [1] => stdClass Object
                (
                    [uid] => 1
                    [name] => admin
                    ...snip...
                )
            [2] => edit
        )
)

Come si vede nel secondo array, ha trovato l'URL giusto, ed anche abbinato l'utente corretto (sto usando superuser).

Se hai qualche dubbio, provalo sul tuo sistema in locale prima...

Più imparo, più dubito.

Ho fatto prima, come mi hai detto:
SELECT * FROM drupal_url_alias d where src LIKE "user/%"

E Non c’è src == "user/%/edit"

Se non dà frutti quello, entriamo in sala operatoria (guanti, maschera e pazienza...)
Nel file includes/menu.inc c'è una funzione menu_get_item alla riga 302 circa. Quella funzione (che è responsabile per abbinare l'URL con un unico record nella tabella menu_router) finisce con:
$router_items[$path] = $router_item;
}
return $router_items[$path];
}

SI

il mio risultato è:

Array
(
    [0] => user/1/edit
    [1] => user/1/%
    [2] => user/%/edit
    [3] => user/%/%
    [4] => user/1
    [5] => user/%
    [6] => user
)
Array
(
    [path] => user/%/edit
    [load_functions] => Array
        (
            [1] => user_category_load
        )
    [to_arg_functions] =>
    [access_callback] => user_edit_access
    [access_arguments] => a:1:{i:0;i:1;}
    [page_callback] => user_edit
    [page_arguments] => Array
        (
            [0] => stdClass Object
                (
                    [uid] => 1
                    [name] => antoine
                    ...snip...
                )
        )
    [fit] => 5
    [number_parts] => 3
    [tab_parent] => user/%
    [tab_root] => user/%
    [title] => Modifica
    [title_callback] => t
    [title_arguments] =>
    [type] => 128
    [block_callback] =>
    [description] =>
    [position] =>
    [weight] => 0
    [file] => modules/user/user.pages.inc
    [href] => user/1/edit
    [options] => Array
        (
        )
    [access] => 1
    [localized_options] => Array
        (
        )
    [map] => Array
        (
            [0] => user
            [1] => stdClass Object
                (
                    [uid] => 1
                    [name] => antoine
                    ...snip...
                )
            [2] => edit
        )
)

Ora ho tolto le righe che mi hai fatto aggiungere (non devo lasciarlo così vero?), cosa devo fare ora?. Non capisco cosa ho ottenuto. Qual è l’url giusto nel secondo array? Scusami ma io non riesco a vederlo!
Ciao e spiegami ancora con la pazienza che dimostri!

hyme wrote:
Ho fatto prima, come mi hai detto:
SELECT * FROM drupal_url_alias d where src LIKE "user/%"
E Non c’è src == "user/%/edit"

OK. E' fin troppo facile creare un alias che 'oscura' un'altra pagina...

hyme wrote:

Se non dà frutti quello, entriamo in sala operatoria (guanti, maschera e pazienza...)
Nel file includes/menu.inc c'è una funzione menu_get_item alla riga 302 circa. Quella funzione (che è responsabile per abbinare l'URL con un unico record nella tabella menu_router) finisce con:
$router_items[$path] = $router_item;
}
return $router_items[$path];
}

SI

il mio risultato è:
SNIP


Quasi identico al mio. OK, questo vuol dire che il routing sta funzionando perfettamente, anche i cookie, perchè ha dato accesso, ed ha caricato l'utente richiesto.

hyme wrote:

Ora ho tolto le righe che mi hai fatto aggiungere (non devo lasciarlo così vero?), cosa devo fare ora?. Non capisco cosa ho ottenuto. Qual è l’url giusto nel secondo array? Scusami ma io non riesco a vederlo!
Ciao e spiegami ancora con la pazienza che dimostri!

Hai fatto bene togliere quelle righe - erano solo per prova.
Abbiamo ottenuto che il sistema di routing sta funzionando, ma che il problema non è li.
L'URL giusto era proprio user/%/edit come scritto nel secondo array.

Quindi il problema sta nel fatto che Drupal 'muore' tentando di produrre l'HTML di quella pagina. A questo punto penso che hai qualche modulo 'aggiuntivo' intorno ai user che da noia. Potrebbe essere Profile o Content Profile, anche Ubercart... Possiamo aggiungere altri print di qui e là, ma solo tu sai quale moduli stai usando.

Prova semplicemente disabilitare questi moduli (magari uno alla volta) in ?q=/admin/build/modules. Consiglio caldamente di fare un backup del DB prima.

Ci siamo quasi...

John

Più imparo, più dubito.

Ok, provo a disabilitare i moduli uno per uno e vediamo quale dà fastidio.
Ti farò sapere!
Grazie ancora
Ciao

Solo moduli di profilo ovvio, non tutti i moduli ;-)

Più imparo, più dubito.

Carissimo jhl.verona ORA FUNZIONA!!!
(ho inserito RISOLTO al primo post).
Ho disattivato Content profile ma prima è stato necessario disattivare altri moduli che lo richiedevano.
Quindi ho disattivato:
Content Profile Tokens
Content Profile User Registration

Ed infine
Account profile
Stranamente togliendo account_profile si è (da solo) disattivato anche content profile.
Nota: In locale i suddetti moduli erano disattivati … per questo tutto funzionava!
Caro jhl.verona ti ringrazio tantissimo per la pazienza e la bravura che hai dimostrato nonché per la tua modestia. Inoltre hai un buon piglio didattico.
Ora mi rinfrescherò la memoria ristudiando a cosa servivano quei moduli e se hanno portato altri problemi (non certamente seri come l’attuale!).
Ciao

Mi sembra che hai una buona capacità anche tu - con pocchi suggerimenti sei andato a segno.

La modularizzazione di Drupal è il suo forte, ma anche il suo tallone di Achille. Speso succede che Drupal + modulo A funziona, e Drupal + modulo B funziona, ma Drupal + moduli A + modulo B da problemi. Sarebbe impossibile (o molto difficile) testare tutte le combinazioni e permutazioni, dato il numero (sempre crescente) di moduli in giro.

Il morale è di essere molto selettivo nella scelta dei moduli (in produzione) anche per questo motivo. Un sandbox in locale va benissimo per esperimentare tutti i moduli che vuoi. Basta pulirlo ogni tanto in tanto...

Più imparo, più dubito.