1
Joomla! 3 / Re:JavaScript bug: non posso cliccare sulla pagina superiore
« il: 01 Mag 2015, 21:30:16 »
Nessun problema. Grazie comunque.
Visualizza post
Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.
2
Joomla! 3 / Re:JavaScript bug: non posso cliccare sulla pagina superiore
« il: 01 Mag 2015, 20:19:30 »
Ok, nessun problema.
Possiamo continuare a parlarne, focalizzandoci sul bug JavaScript?
Come faccio, con FireBug, a vedere il problema mentre si presenta? Su che file devo mettere le mani per sistemare?
Tu ne hai idea?
Possiamo continuare a parlarne, focalizzandoci sul bug JavaScript?
Come faccio, con FireBug, a vedere il problema mentre si presenta? Su che file devo mettere le mani per sistemare?
Tu ne hai idea?
3
Joomla! 3 / Re:JavaScript bug: non posso cliccare sulla pagina superiore
« il: 01 Mag 2015, 18:43:24 »
Ciao,
i dati ce li ho ma non volevo scrivere subito troppo.
Il negozio e' JoomShopping 4.9.2 (il problema credo sia nato dopo un suo aggiornamento).
Joomla e' 3.4.1
Il template è *******
Il sito e' questo: ************ (ve l'ho aperto temporaneamente)
Da qui riesco a cliccare di nuovo indietro su "Shop Online": *************
Da qui no, mi apre solo i sottomenu *************
Ho chiesto anche in "JavaScript" su HTML.it ma per ora silenzio totale
Non ho piu' il supporto del produttore del template perche' mi e' scaduto l'abbonamento ma, se proprio me la vedo male, compro qualche altro mese.
Consigli?
i dati ce li ho ma non volevo scrivere subito troppo.
Il negozio e' JoomShopping 4.9.2 (il problema credo sia nato dopo un suo aggiornamento).
Joomla e' 3.4.1
Il template è *******
Il sito e' questo: ************ (ve l'ho aperto temporaneamente)
Da qui riesco a cliccare di nuovo indietro su "Shop Online": *************
Da qui no, mi apre solo i sottomenu *************
Ho chiesto anche in "JavaScript" su HTML.it ma per ora silenzio totale
Non ho piu' il supporto del produttore del template perche' mi e' scaduto l'abbonamento ma, se proprio me la vedo male, compro qualche altro mese.
Consigli?
4
Joomla! 3 / JavaScript bug: non posso cliccare sulla pagina superiore
« il: 01 Mag 2015, 04:54:14 »
Ciao a tutti,
vi scrivo dopo aver gia' scritto su un altro forum dove mi hanno dato una risposta che non so interpretare.
Il problema e' questo: ho un menu Negozio, con sottomenu Collane, Bracciali, Borse; se clicco su Negozio si apre la vetrina. Mettendo in mouse in hover su Negozio si apre il sottomenu. Ecco: se entro in un prodotto, ad esempio Negozio > Collane > Collana 1, non riesco piu' a ri-cliccare su Negozio. Mi apre solo i sottomenu e devo fare un altro giro.
Sull'altro forum mi hanno detto:
Io, purtroppo, di JavaScript ne so zero. Zero di zero.
Non so neanche dove guardare per provare a mettere le mani.
Mi potete dare qualche consiglio? Anche solo dove iniziare a guardare?
Grazie
vi scrivo dopo aver gia' scritto su un altro forum dove mi hanno dato una risposta che non so interpretare.
Il problema e' questo: ho un menu Negozio, con sottomenu Collane, Bracciali, Borse; se clicco su Negozio si apre la vetrina. Mettendo in mouse in hover su Negozio si apre il sottomenu. Ecco: se entro in un prodotto, ad esempio Negozio > Collane > Collana 1, non riesco piu' a ri-cliccare su Negozio. Mi apre solo i sottomenu e devo fare un altro giro.
Sull'altro forum mi hanno detto:
Citazione
Bug in javascript
http://www.dominio.it/templates/******/assets/***/js/jcarousellite_1.0.1.pack.js line 1 > eval
TypeError: a[0] is undefined
...nt($.css(a[0],b))||0};function width(a){return a[0].offsetWidth+css(a,'marginLef...
Example use firefox + firebug - See errors.
Io, purtroppo, di JavaScript ne so zero. Zero di zero.
Non so neanche dove guardare per provare a mettere le mani.
Mi potete dare qualche consiglio? Anche solo dove iniziare a guardare?
Grazie
5
SEO / Joomlatwork SEF patch per 1.5: servono i meta tag delle voci menu?
« il: 02 Mag 2009, 19:31:00 »
Ciao ragazzi.
Stavo cercando di far indicizzare un po' meglio alcune sezioni del mio sito, in particolare "Concerti" e "Download".
Ho notato, nel farlo, che grazie all'installazione della SEF Patch di Joomlatwork (di cui ho sentito parlare al seminario tenuto da Zalexo l'hanno scorso, qui in riviera romagnola), e' possibile inserire le meta tag key e description anche per ogni singola voce di menu.
Ho gia' provato ad inserirli nella voce "Concerti", che vorrei che risultasse piu' in alto in google, quando qualcuno ricerca "concerti punk".
Ho inserito questo:
Description: Un elenco continuamente aggiornato dei concerti punk in Italia.
Keys: concerti punk, concerti hardcore, concerti rock, locali, centri sociali,
Non credo pero' di aver visto miglioramenti di sorta nella posizione che ottengo su google.
Quindi mi chiedevo:
- Quanta importanza da google a questi meta tag delle voci di menu? Sono veramente utili?
- E' meglio che io rinomini direttamente la voce "Concerti" in "Concerti Punk"? Mi piaceva poco, stilisticamente...
- Le meta keys e la description che ho inserito si possono considerare pen pensate e scritte?
Spero che sappiate darmi qualche consiglio...so bene di essere ancora abbastanza digiuno di SEO ma da quando ho iniziato a lavorare con Joomla sto continuando ad imparare ed a migliorare il posizionamento del mio sito
A presto!
sberla
Stavo cercando di far indicizzare un po' meglio alcune sezioni del mio sito, in particolare "Concerti" e "Download".
Ho notato, nel farlo, che grazie all'installazione della SEF Patch di Joomlatwork (di cui ho sentito parlare al seminario tenuto da Zalexo l'hanno scorso, qui in riviera romagnola), e' possibile inserire le meta tag key e description anche per ogni singola voce di menu.
Ho gia' provato ad inserirli nella voce "Concerti", che vorrei che risultasse piu' in alto in google, quando qualcuno ricerca "concerti punk".
Ho inserito questo:
Description: Un elenco continuamente aggiornato dei concerti punk in Italia.
Keys: concerti punk, concerti hardcore, concerti rock, locali, centri sociali,
Non credo pero' di aver visto miglioramenti di sorta nella posizione che ottengo su google.
Quindi mi chiedevo:
- Quanta importanza da google a questi meta tag delle voci di menu? Sono veramente utili?
- E' meglio che io rinomini direttamente la voce "Concerti" in "Concerti Punk"? Mi piaceva poco, stilisticamente...
- Le meta keys e la description che ho inserito si possono considerare pen pensate e scritte?
Spero che sappiate darmi qualche consiglio...so bene di essere ancora abbastanza digiuno di SEO ma da quando ho iniziato a lavorare con Joomla sto continuando ad imparare ed a migliorare il posizionamento del mio sito
A presto!
sberla
6
Installazione, migrazione e aggiornamento / Re: Problemi con com_content da admin, aggiornamento a 1.5.9 e metadata
« il: 17 Feb 2009, 23:14:36 »
Rieccomi.
Mi rispondo da solo come al solito perche' credo di essere gia' arrivato alla soluzione: era tutta colpa della Joomla SEF Patch....mi ero dimenticato che la stavo usando e mi e' tornato in mente solo dopo.....
Semplicemente, non appena aggiornato Joomla alla 1.5.9 bisognerebbe applicare immediatamente la SEF Patch per 1.5.9, poiche' va proprio a modificare il file /administrator/components/com_content/admin.content.html.php
Quindi, ho dato una pulita a tutto il casino che avevo fatto, in questo modo:
1) Ri-uppato com_content della 1.5.8
2) Uppato i files di com_content dell'aggiornamento da Joomla 1.5.8 a 1.5.9
3) Applicato a com_content i relativi files della SEF Patch 1.5.9, uppandoli via ftp e sovrascrivendo i vecchi.
Ora sembra andare tutto a meraviglia.
Speriamo che tutto sto papiro che ho scritto possa servire ad altri con lo stesso problema
Mi rispondo da solo come al solito perche' credo di essere gia' arrivato alla soluzione: era tutta colpa della Joomla SEF Patch....mi ero dimenticato che la stavo usando e mi e' tornato in mente solo dopo.....
Semplicemente, non appena aggiornato Joomla alla 1.5.9 bisognerebbe applicare immediatamente la SEF Patch per 1.5.9, poiche' va proprio a modificare il file /administrator/components/com_content/admin.content.html.php
Quindi, ho dato una pulita a tutto il casino che avevo fatto, in questo modo:
1) Ri-uppato com_content della 1.5.8
2) Uppato i files di com_content dell'aggiornamento da Joomla 1.5.8 a 1.5.9
3) Applicato a com_content i relativi files della SEF Patch 1.5.9, uppandoli via ftp e sovrascrivendo i vecchi.
Ora sembra andare tutto a meraviglia.
Speriamo che tutto sto papiro che ho scritto possa servire ad altri con lo stesso problema
7
Joomla! 1.5 / Aumentare i caratteri del motore di ricerca interno
« il: 17 Feb 2009, 19:35:10 »
Ciao a tutti.
Mi sono accorto soltanto ora che il campo "cerca" del motore di ricerca interno, non accetta piu' di 20 caratteri totali.
Possono sembrare sufficienti pero', spesso, sul mio sito ho bisogno di qualche carattere in piu', poiche' gli utenti possono cercare i titoli dei dischi, che in linea di massima sono abbastanza lunghi. Intendo dire, una query del tipo "Artista Titolo Dell'Album" ci mette poco ad andare oltre i 20 caratteri....ed una query incompleta non restituisce nessun risultato utile, ne' consiglia una query alternativa come fa Google.
Come faccio ad aumentare questo limite?
Ho ovviamente gia' cercato su Google ed anche nei parametri del componente e del relativo menu "Cerca", pero' non presenta nessun settaggio a riguardo.
Voi sapete dove devo mettere le mani?
Grazie in anticipo come sempre
Mi sono accorto soltanto ora che il campo "cerca" del motore di ricerca interno, non accetta piu' di 20 caratteri totali.
Possono sembrare sufficienti pero', spesso, sul mio sito ho bisogno di qualche carattere in piu', poiche' gli utenti possono cercare i titoli dei dischi, che in linea di massima sono abbastanza lunghi. Intendo dire, una query del tipo "Artista Titolo Dell'Album" ci mette poco ad andare oltre i 20 caratteri....ed una query incompleta non restituisce nessun risultato utile, ne' consiglia una query alternativa come fa Google.
Come faccio ad aumentare questo limite?
Ho ovviamente gia' cercato su Google ed anche nei parametri del componente e del relativo menu "Cerca", pero' non presenta nessun settaggio a riguardo.
Voi sapete dove devo mettere le mani?
Grazie in anticipo come sempre
8
Installazione, migrazione e aggiornamento / [Risolto] Problemi con com_content da admin, aggiornamento a 1.5.9 e metadata
« il: 17 Feb 2009, 19:15:20 »
Ciao a tutti ragazzi.
Spero davvero che sappiate aiutarmi perche' e' la prima volta che incappo in un errore relativo al Joomla core, a seguito di un aggiornamento.
Ho appena aggiornato dalla 1.5.8 alla 1.5.9 usando l'aggiornamento in italiano presente qui su Joomla.it; ho fatto cio' che faccio ogni volta, ovvero semplicemente decomprimere lo zip e uppare i file via ftp, sovrascrivendo i vecchi.
Purtroppo, appena ho provato a modificare una news vecchia (o ad inserirne una nuova) ho notato che la pagina di gestione della news si era completamente rovinata.
In top mostrava questo errore:
Allora ho pensato di risolvere temporaneamente in due maniere.
Per prima cosa ho notato che admin.content.html.php non era fra i files aggiornati dall'aggiornamento 1.5.8 ---> 1.5.9.; allora ho scompattato Joomla 1.5.9 completo (non l'aggiornamento), ho rinominato sull'ftp remoto admin.content.html.php in admin.content.html.php_OLD ed ho fatto l'upload di admin.content.html.php preso dalla 1.5.9.
In questo modo la schermata di modifica della news e' tornata perfettamente a funzionare, pero' i campi meta (keys e description) risultavano bianchi.
Sono andato a controllare nel database ed i dati, fortunatamente, erano ancora li, nel campo metadata di jos_content.
Ho provato a rinominare in _OLD e sostituirli con quelli della 1.5.9 completa, tutti i files che avevano una dimensione diversa rispetto al pacchetto della 1.5.9 stessa, ma non e' cambiato nulla.
Ho notato, allora, che questo nuovo file admin.content.html.php, a quanto pare, salva le informazioni relative ai campi meta, in 2 diversi campi del database, metakey e metadesc, a differenza di quanto faceva la 1.5.8, che le salvava unite nel campo metadata, come ho appena detto.
Il problema, oltre al fatto che non c'era piu' modo di accedere dal back-end di amministrazione ai campi metadata gia' inseriti, era che, dando un "salva" o "applica" ad una news visualizzata cosi', i campi meta venivano addirittura svuotati.
Non sapendo come risolvere ho rinominato in com_content_NEW la cartella della 1.5.9 (anzi, quella specie di mischuglio che ho fatto, che non mi da poi troppa sicurezza) ed ho riuppato come com_content la cartella del backup della 1.5.8 che avevo fatto giusto un attimo prima di aggiornare.
In questo modo tutto funziona come prima ed i campi metadata sono tornati ad essere visualizzati e modificabili; la cosa strana, per altro, e' che vengono visualizzati correttamente anche i meta key e la meta description dell'unica news che ho inserito con il com_content della 1.5.9, nonstante questi siano salvati nei campi separati metakey e metadesc invece che in metadata come tutte le news vecchie.
A questo punto vi chiedo: come posso sistemare la cosa, per avere il com_content della 1.5.9?
Non vorrei che col tempo emergessero altri problemi, tenendo un componente di admin cosi' importante non aggiornato. Inoltre, il giorno che dovro' aggiornare alla 1.6, probabilmente verra' fuori qualche altra pippa.
A cosa puo' essere stato dovuto il bug iniziale? E perche' questo diverso comportamento relativamente ai campi del database?
Spero mi risponderete....non ricevo quasi mai risposta qui dentro e non riesco proprio a capirne il perche'
Mi costringete sempre a tradurre tutto in inglese e postare sul forum di Joomla.org
A presto e grazie in anticipo!
Spero davvero che sappiate aiutarmi perche' e' la prima volta che incappo in un errore relativo al Joomla core, a seguito di un aggiornamento.
Ho appena aggiornato dalla 1.5.8 alla 1.5.9 usando l'aggiornamento in italiano presente qui su Joomla.it; ho fatto cio' che faccio ogni volta, ovvero semplicemente decomprimere lo zip e uppare i file via ftp, sovrascrivendo i vecchi.
Purtroppo, appena ho provato a modificare una news vecchia (o ad inserirne una nuova) ho notato che la pagina di gestione della news si era completamente rovinata.
In top mostrava questo errore:
Citazione
Warning: Missing argument 7 for ContentView::editContent(), called in /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/administrator/components/com_content/controller.php on line 572 and defined in /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/administrator/components/com_content/admin.content.html.php on line 435mente dove solitamente ci sono i campi dei meta c'era soltanto questo errore:
Citazione
Fatal error: Call to a member function render() on a non-object in /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/administrator/components/com_content/admin.content.html.php on line 538e non era piu' possibile salvare o modificare una news.
Allora ho pensato di risolvere temporaneamente in due maniere.
Per prima cosa ho notato che admin.content.html.php non era fra i files aggiornati dall'aggiornamento 1.5.8 ---> 1.5.9.; allora ho scompattato Joomla 1.5.9 completo (non l'aggiornamento), ho rinominato sull'ftp remoto admin.content.html.php in admin.content.html.php_OLD ed ho fatto l'upload di admin.content.html.php preso dalla 1.5.9.
In questo modo la schermata di modifica della news e' tornata perfettamente a funzionare, pero' i campi meta (keys e description) risultavano bianchi.
Sono andato a controllare nel database ed i dati, fortunatamente, erano ancora li, nel campo metadata di jos_content.
Ho provato a rinominare in _OLD e sostituirli con quelli della 1.5.9 completa, tutti i files che avevano una dimensione diversa rispetto al pacchetto della 1.5.9 stessa, ma non e' cambiato nulla.
Ho notato, allora, che questo nuovo file admin.content.html.php, a quanto pare, salva le informazioni relative ai campi meta, in 2 diversi campi del database, metakey e metadesc, a differenza di quanto faceva la 1.5.8, che le salvava unite nel campo metadata, come ho appena detto.
Il problema, oltre al fatto che non c'era piu' modo di accedere dal back-end di amministrazione ai campi metadata gia' inseriti, era che, dando un "salva" o "applica" ad una news visualizzata cosi', i campi meta venivano addirittura svuotati.
Non sapendo come risolvere ho rinominato in com_content_NEW la cartella della 1.5.9 (anzi, quella specie di mischuglio che ho fatto, che non mi da poi troppa sicurezza) ed ho riuppato come com_content la cartella del backup della 1.5.8 che avevo fatto giusto un attimo prima di aggiornare.
In questo modo tutto funziona come prima ed i campi metadata sono tornati ad essere visualizzati e modificabili; la cosa strana, per altro, e' che vengono visualizzati correttamente anche i meta key e la meta description dell'unica news che ho inserito con il com_content della 1.5.9, nonstante questi siano salvati nei campi separati metakey e metadesc invece che in metadata come tutte le news vecchie.
A questo punto vi chiedo: come posso sistemare la cosa, per avere il com_content della 1.5.9?
Non vorrei che col tempo emergessero altri problemi, tenendo un componente di admin cosi' importante non aggiornato. Inoltre, il giorno che dovro' aggiornare alla 1.6, probabilmente verra' fuori qualche altra pippa.
A cosa puo' essere stato dovuto il bug iniziale? E perche' questo diverso comportamento relativamente ai campi del database?
Spero mi risponderete....non ricevo quasi mai risposta qui dentro e non riesco proprio a capirne il perche'
Mi costringete sempre a tradurre tutto in inglese e postare sul forum di Joomla.org
A presto e grazie in anticipo!
9
Gestione Forum / Re: Fireboard 1.0.5 RC2 mostra No Posts e Recount Categories Stats non funziona
« il: 17 Feb 2009, 18:40:57 »
Alla fine credo che il problema fosse a monte, a livello server....il mio Grid Server condiviso blocca tutti gli script che lavorano per piu' di 120 minuti o si mangiano piu' di tot di ram, e forse per questo lo script del Recount Categories veniva bloccato con l'errore 500.
In generale, Fireboard s'e' rivelato inadeguato al mio hosting ed alle mie esigenze....continuava a dare errori 500 ovunque ed ad essere parecchio lento.
Sono passato ad Agora, un fork di PunBB, velocissimo, abbastanza carino e che fa cio' che deve fare. Sul sito ufficiale ho comprato un convertitore da Fireboard ad Agora cosi' non ho perso nessun dato
In generale, Fireboard s'e' rivelato inadeguato al mio hosting ed alle mie esigenze....continuava a dare errori 500 ovunque ed ad essere parecchio lento.
Sono passato ad Agora, un fork di PunBB, velocissimo, abbastanza carino e che fa cio' che deve fare. Sul sito ufficiale ho comprato un convertitore da Fireboard ad Agora cosi' non ho perso nessun dato
10
Gestione Forum / Re: Fireboard 1.0.5 RC2 mostra No Posts e Recount Categories Stats non funziona
« il: 08 Dic 2008, 19:42:17 »Citazione
Puoi abilitare gli errori?Oddio, scusa la mia "niubbita'" ma non so ne' dove si abilitano gli errori (intendi la modalita' debug di joomla?) ne' quali permessi devo ripristinare (quelli del filesystem? a che valore?)
Altrimenta ripristina i permessi
Scusami
Nel frattempo ho fatto altri test ed ho notato che ricevo un errore 500 praticamente su ogni operazione di amministrazione (spostare o cancellare un topic, oltre che quel benedetto bottone di Recount); il sito rimane in loop a lavorare per qualche minuto, poi compare l'errore 500 ma perlomeno l'operazione viene effettuata (a differenza del Recount).
Ho scritto all'hosting (Media Temple) se credono che possa dipendere da htaccess, poiche' ho notato, googlando un po', che molto spesso viene collegato l'errore 500 a problemi di htaccess e mod rewrite.
P.S.
Ops, non avevo notato che ci fosse una sezione del forum adibita alle discussioni sui componenti forum..scusate
11
Gestione Forum / Fireboard 1.0.5 RC2 mostra No Posts e Recount Categories Stats non funziona
« il: 08 Dic 2008, 06:21:09 »
Ciao a tutti ragazzi,
spero veramente che questa volta sappiate aiutarmi.
Ho appena aggiornato Fireboard dalla 1.0.4 alla 1.0.5 RC2 usando le istruzioni che si trovano sulla home page del componente; l'aggiormento e' andato a buon fine ed il forum funzionava correttamente.
Quando, pero', ho provato ad inserire un topic di prova e successivamente cancellarlo, il forum e' rimasto in loop per qualche minuto ed una volta fatto un refresh tutte le categorie mostravano "No Posts" ed il conteggio di topics e replies a 0.
Ho googlato un po' ed ho visto che sembra essere un problema abbastanza condiviso e che si puo' risolvere usando il bottone "Recount Categories Stats" presente nel backend di amministrazione.
Il problema e' che facendo partire questo riconteggio, il sito rimane in loop per qualche minuto e successivamente se ne esce con un error 500, senza risolvere nulla.
Avete qualche consiglio a riguardo?
E' mai successo anche a voi?
Come posso sistemare il Recount Categories Stats?
Non ho veramente nessuna voglia di fare il downgrade e magari successivamente rifare l'upgrade...devo reimportare le vecchie tabelle del database (ed ho gia' visto che mi danno degli errori) e rifare parecchio lavoro...inoltre ho paura che una cosa simile possa succedere anche in futuro.
Spero sappiate aiutarmi
Grazie!
spero veramente che questa volta sappiate aiutarmi.
Ho appena aggiornato Fireboard dalla 1.0.4 alla 1.0.5 RC2 usando le istruzioni che si trovano sulla home page del componente; l'aggiormento e' andato a buon fine ed il forum funzionava correttamente.
Quando, pero', ho provato ad inserire un topic di prova e successivamente cancellarlo, il forum e' rimasto in loop per qualche minuto ed una volta fatto un refresh tutte le categorie mostravano "No Posts" ed il conteggio di topics e replies a 0.
Ho googlato un po' ed ho visto che sembra essere un problema abbastanza condiviso e che si puo' risolvere usando il bottone "Recount Categories Stats" presente nel backend di amministrazione.
Il problema e' che facendo partire questo riconteggio, il sito rimane in loop per qualche minuto e successivamente se ne esce con un error 500, senza risolvere nulla.
Avete qualche consiglio a riguardo?
E' mai successo anche a voi?
Come posso sistemare il Recount Categories Stats?
Non ho veramente nessuna voglia di fare il downgrade e magari successivamente rifare l'upgrade...devo reimportare le vecchie tabelle del database (ed ho gia' visto che mi danno degli errori) e rifare parecchio lavoro...inoltre ho paura che una cosa simile possa succedere anche in futuro.
Spero sappiate aiutarmi
Grazie!
12
Joomla! 1.5 / Re: Bug Remository: Invalid argument supplied for foreach()
« il: 08 Dic 2008, 06:07:33 »
Ok, provero' li
Speravo in una risposta qui, per evitare di dover tradurre tutto in inglese
Ad ogni modo, ora come ora, quando posso sto risolvendo il problema ri-salvando le impostazioni ogni pochi giorni, ma si tratta ovviamente di un "hack" abbastanza fastidioso da dover continuare ad applicare...
Speravo in una risposta qui, per evitare di dover tradurre tutto in inglese
Ad ogni modo, ora come ora, quando posso sto risolvendo il problema ri-salvando le impostazioni ogni pochi giorni, ma si tratta ovviamente di un "hack" abbastanza fastidioso da dover continuare ad applicare...
13
Joomla! 1.5 / Bug Remository: Invalid argument supplied for foreach()
« il: 22 Nov 2008, 21:40:34 »
Ciao ragazzi.
E' un po' che sto combattendo con questo bug di Remository, che e' spuntato dal nulla in una vecchia versione del componente ma continua anche dopo che l'ho aggiornato all'ultima versione disponibile, la 3.46.
In pratica, dopo qualche giorno di normale funzionamento, Remository si dimentica delle impostazioni di configurazione che gli ho dato (per fortuna solo di quelle) e ritorna alle impostazioni di default; contemporaneamente a questo, inizia a visualizzare un errore sotto ad ogni file, nella schermata che lista un container:
Warning: Invalid argument supplied for foreach() in /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/components/com_remository/remository.html.php on line 274
Risistemando la configurazione questo errore sparisce.
Nella configurazione io vado ad impostare che sia il filesystem il luogo di salvataggio predefinito dei files (e non il database, che mi pare una scelta assurda), che gli utenti non possano mandare files (ne' sovrascrivere ne' altro), che non sia permesso votare ne' commentare. Inoltre modifico il download text inserendo una pubblicita' adsense di quelle in mio possesso, piuttosto che quella di default.
Cambio anche le cartelle di default di download ed upload...
Quando il componente e' malfunzionante, nella sua schermata principale si legge questo:
Memorizzazione di default per i nuovi contenitori: Database
Magazzino di default per il file system: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/remos_downloads Cartella non scrivibile
Area di attesa per gli invii: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/remos_downloads/uploads Cartella non scrivibile
(le cartelle ora non esistono piu' perche' le ho cancellate, ma dava lo stesso errore anche quando erano presenti).
Sistemando tutto ho questo:
Memorizzazione di default per i nuovi contenitori: File System
Magazzino di default per il file system: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/download/ Cartella scrivibile
Area di attesa per gli invii: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/download/upload/ Cartella scrivibile
Detto questo, forse puo' tornarvi utile sapere che praticamente tutti i container hanno la cartella di default sbagliata, poiche' e' impostata ancora sulla cartella locale del mio web server (/var/www etc etc); questo cmq non condiziona il funzionamento vero e proprio del componente perche' solo noi dello staff facciamo l'upload dei files e li linkiamo con percorso assoluto.
Ho detto tutto
Spero che sappiate aiutarmi perche' e' un problema decisamente fastidioso (simile a quelli che aveva phpnuke e che mi hanno convinto ad abbandonarlo per Joomla), che tra le altre cose mi fa perdere dei guadagni di adsense, in quanto toglie le mie pubblicita' per quelle di default.
Grazie in anticipo!
E' un po' che sto combattendo con questo bug di Remository, che e' spuntato dal nulla in una vecchia versione del componente ma continua anche dopo che l'ho aggiornato all'ultima versione disponibile, la 3.46.
In pratica, dopo qualche giorno di normale funzionamento, Remository si dimentica delle impostazioni di configurazione che gli ho dato (per fortuna solo di quelle) e ritorna alle impostazioni di default; contemporaneamente a questo, inizia a visualizzare un errore sotto ad ogni file, nella schermata che lista un container:
Warning: Invalid argument supplied for foreach() in /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/components/com_remository/remository.html.php on line 274
Risistemando la configurazione questo errore sparisce.
Nella configurazione io vado ad impostare che sia il filesystem il luogo di salvataggio predefinito dei files (e non il database, che mi pare una scelta assurda), che gli utenti non possano mandare files (ne' sovrascrivere ne' altro), che non sia permesso votare ne' commentare. Inoltre modifico il download text inserendo una pubblicita' adsense di quelle in mio possesso, piuttosto che quella di default.
Cambio anche le cartelle di default di download ed upload...
Quando il componente e' malfunzionante, nella sua schermata principale si legge questo:
Memorizzazione di default per i nuovi contenitori: Database
Magazzino di default per il file system: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/remos_downloads Cartella non scrivibile
Area di attesa per gli invii: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/remos_downloads/uploads Cartella non scrivibile
(le cartelle ora non esistono piu' perche' le ho cancellate, ma dava lo stesso errore anche quando erano presenti).
Sistemando tutto ho questo:
Memorizzazione di default per i nuovi contenitori: File System
Magazzino di default per il file system: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/download/ Cartella scrivibile
Area di attesa per gli invii: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/download/upload/ Cartella scrivibile
Detto questo, forse puo' tornarvi utile sapere che praticamente tutti i container hanno la cartella di default sbagliata, poiche' e' impostata ancora sulla cartella locale del mio web server (/var/www etc etc); questo cmq non condiziona il funzionamento vero e proprio del componente perche' solo noi dello staff facciamo l'upload dei files e li linkiamo con percorso assoluto.
Ho detto tutto
Spero che sappiate aiutarmi perche' e' un problema decisamente fastidioso (simile a quelli che aveva phpnuke e che mi hanno convinto ad abbandonarlo per Joomla), che tra le altre cose mi fa perdere dei guadagni di adsense, in quanto toglie le mie pubblicita' per quelle di default.
Grazie in anticipo!
14
Joomla! 1.5 / Re: Remository, containers e permessi manager
« il: 17 Nov 2008, 00:07:26 »
Scusate se uppo questo vecchio topic, purtroppo non ho avuto modo di risolvere....nessuno di voi ha qualche consiglio a riguardo?
15
Joomla! 1.5 / Remository, containers e permessi manager
« il: 01 Set 2008, 14:45:37 »
Ciao ragazzi
Ho finalmente finito il sito a cui sto lavorando ormai da qualche mese ma mi rimangono alcuni piccoli dubbi su un paio di ritocchi che vorrei fare.
Dunque, ho un piccolo dubbio sul comportamento di Rempository (uso la versione 3.44.3) con i "containers" (le cartelle che contengono i vari download nel frontend e nel backend del sito) e gli amministratori, soprattutto quelli con privilegi di "manager" o inferiore.
Vi spiego: io ho una cartella con varie sottocartelle e per essere sicuro che assolutamente nessuno potesse modificare o uploadare files dal frontend pubblico del sito, ho impostato ogni cartella con questi permessi:
Download Roles: Visitor
Upload Roles: Nobody
Edit Roles: Nobody
Mi sembravano le scelte piu' ovvie.
Ora, io ho 2 o 3 collaboratori ai quali avevo dato il rango di "Manager", perche' non devono fare altro che inserire contenuti, inserire dati nei vari componenti ed anche creare containers in Remository, nonche' nuovi files.
Il problema e' questo: con il rango di Manager, i miei collaboratori possono creare dei nuovi container e sottocontainer ma se gli impostano quei permessi dopo non possono piu' vedere i container creati nella lista e quindi non possono aggiungere files al loro interno.
Per risolvere, temporaneamente, ho dato loro il grado di "Administrator" ma vorrei riportarli a Manager, per evitare che abbiano accesso alla gestione dei componenti e dei moduli.
Quindi vi chiedo:
1) Quali sono i settaggi dei container necessari per far si che nessuno possa uploadare o editare dei files dal frontend pubblico del sito? (magari i miei sono eccessivi)
2) Come posso fare per permettere a degli amministratori Manager di avere pieno accesso in modifica ai container di Remository, pur bloccandone la modifica da frontend? Devo, forse aggiungere una regola che riguardi i "Manager"?
(ovviamente la risposta di una domanda copre anche quella dell'altra )
Grazie
Gia' che ci sono, se posso, mi permetto di esporvi un paio di altri miei dubbi.
1) Accanto ad ogni container, sotto la voce "Storage Status", vedo "Non-existent directory". Che significa? I files sono correttamente linkati e si scaricano senza problemi...
2) Ogni volta che vado a modificare un container mi da questo errore, a volte anche ripetuto per decine di volte: "You attempted to upload a file with a disallowed extension! (/var/www/htdocs/download/)". Che significa? Mi sembra tanto un bug.....anche perche' sto solo modificando un files o un container...e solitamente si tratta di un file aggiunto con "add remote"....non sto cercando di riuplodare proprio niente. E' abbastanza fastidioso
Grazie mille
Ho finalmente finito il sito a cui sto lavorando ormai da qualche mese ma mi rimangono alcuni piccoli dubbi su un paio di ritocchi che vorrei fare.
Dunque, ho un piccolo dubbio sul comportamento di Rempository (uso la versione 3.44.3) con i "containers" (le cartelle che contengono i vari download nel frontend e nel backend del sito) e gli amministratori, soprattutto quelli con privilegi di "manager" o inferiore.
Vi spiego: io ho una cartella con varie sottocartelle e per essere sicuro che assolutamente nessuno potesse modificare o uploadare files dal frontend pubblico del sito, ho impostato ogni cartella con questi permessi:
Download Roles: Visitor
Upload Roles: Nobody
Edit Roles: Nobody
Mi sembravano le scelte piu' ovvie.
Ora, io ho 2 o 3 collaboratori ai quali avevo dato il rango di "Manager", perche' non devono fare altro che inserire contenuti, inserire dati nei vari componenti ed anche creare containers in Remository, nonche' nuovi files.
Il problema e' questo: con il rango di Manager, i miei collaboratori possono creare dei nuovi container e sottocontainer ma se gli impostano quei permessi dopo non possono piu' vedere i container creati nella lista e quindi non possono aggiungere files al loro interno.
Per risolvere, temporaneamente, ho dato loro il grado di "Administrator" ma vorrei riportarli a Manager, per evitare che abbiano accesso alla gestione dei componenti e dei moduli.
Quindi vi chiedo:
1) Quali sono i settaggi dei container necessari per far si che nessuno possa uploadare o editare dei files dal frontend pubblico del sito? (magari i miei sono eccessivi)
2) Come posso fare per permettere a degli amministratori Manager di avere pieno accesso in modifica ai container di Remository, pur bloccandone la modifica da frontend? Devo, forse aggiungere una regola che riguardi i "Manager"?
(ovviamente la risposta di una domanda copre anche quella dell'altra
)Grazie
Gia' che ci sono, se posso, mi permetto di esporvi un paio di altri miei dubbi.
1) Accanto ad ogni container, sotto la voce "Storage Status", vedo "Non-existent directory". Che significa? I files sono correttamente linkati e si scaricano senza problemi...
2) Ogni volta che vado a modificare un container mi da questo errore, a volte anche ripetuto per decine di volte: "You attempted to upload a file with a disallowed extension! (/var/www/htdocs/download/)". Che significa? Mi sembra tanto un bug.....anche perche' sto solo modificando un files o un container...e solitamente si tratta di un file aggiunto con "add remote"....non sto cercando di riuplodare proprio niente. E' abbastanza fastidioso
Grazie mille
16
Joomla! 1.5 / Re: Impossibile installare componenti in remoto, strano errore
« il: 20 Ago 2008, 18:54:06 »
Ho risolto!
Vi scrivo come, in caso capiti a qualcuno.
Ho seguito quanto descritto da questa guida: http://forum.joomla.org/viewtopic.php?f=431&t=271303&start=60&st=0&sk=t&sd=a#p1297581
Sembra che il problema sia proprio tipico dell'hosting Media Temple.
In pratica, il problema e' relativo al "Percorso della cartella temporanea" ed al "Percorso della cartella Log", presenti nella configurazione di sistema.
Configurare i parametri FTP non cambia nulla.
Come cartella log avevo: /var/www/htdocs/logs
Come cartella temp: /var/www/htdocs/tmp
Sono andato in media manager ed ho guardato il path in cui cerca di uppare i file.
Era questo: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/images
A questo punto ho cambiato la prima parte delle cartelle log e temp, sostituendolo con quello che ho trovato nel media manager (gestore media):
/nfs/c02/h04/mnt/46870/domains/punk4free.org/html/logs
/nfs/c02/h04/mnt/46870/domains/punk4free.org/html/tmp
In questo modo tutto funziona
La guida suggerisce anche, per evitare che il path venga di nuovo cambiato in futuro dall'hosting (credo capiti solo su Media Temple), di sostituire "/home/" al posto di "/nfs/c02/h04/mnt/".
Non ho ancora provato ma provero'
Alla prossima!
Vi scrivo come, in caso capiti a qualcuno.
Ho seguito quanto descritto da questa guida: http://forum.joomla.org/viewtopic.php?f=431&t=271303&start=60&st=0&sk=t&sd=a#p1297581
Sembra che il problema sia proprio tipico dell'hosting Media Temple.
In pratica, il problema e' relativo al "Percorso della cartella temporanea" ed al "Percorso della cartella Log", presenti nella configurazione di sistema.
Configurare i parametri FTP non cambia nulla.
Come cartella log avevo: /var/www/htdocs/logs
Come cartella temp: /var/www/htdocs/tmp
Sono andato in media manager ed ho guardato il path in cui cerca di uppare i file.
Era questo: /nfs/c02/h04/mnt/46870/domains/punk4free.org/html/images
A questo punto ho cambiato la prima parte delle cartelle log e temp, sostituendolo con quello che ho trovato nel media manager (gestore media):
/nfs/c02/h04/mnt/46870/domains/punk4free.org/html/logs
/nfs/c02/h04/mnt/46870/domains/punk4free.org/html/tmp
In questo modo tutto funziona
La guida suggerisce anche, per evitare che il path venga di nuovo cambiato in futuro dall'hosting (credo capiti solo su Media Temple), di sostituire "/home/" al posto di "/nfs/c02/h04/mnt/".
Non ho ancora provato ma provero'
Alla prossima!
17
SEO / Re: Attivare Sh404sef solo per un componente? Problemi componenti terze parti
« il: 08 Ago 2008, 14:59:14 »Citazione
Secondo me costruire tutto attorno a sectionex così come è adesso, non è comunque una buona scelta, visto che l'autore ha già annunciato che non lo supporterà più, nè rilascerà nuove versioni. Qui l'annuncio.Azz.
Sono tutti contro di me
Grazie del link!
Citazione
Sostiene, nel frattempo, che il proggetto viene "rilevato" da Azrul, quello di Jom Comment, MyBlog e NiceTalk.Effettivamente e' proprio un bel componente, sarebbe un peccato ed anche un'assurdita' lasciarlo morire nel nulla.
Inoltre, nella mia ignoranza, non credo che abbia bisogno di chissa' quali revisioni in futuro...solo eventuali aggiornamenti per seguire i piccoli cambiamenti di Joomla nella gestione dei contenuti.
In fin dei conti non fa altro che prendere le liste degli articoli e mostrarle
Citazione
Comunque, a giudicare dal forum presente nelle sue pagine, mi pare molto attivo in termini di supporto e, molto supporto viene dato alla compatibilità delle sue estensioni con sh404.A questo punto, forse, in futuro iniziero' ad usare sh404sef e mi prendero' la brigha di ri-modificare tutti questi benedetti link relativi che dalle news puntano ai download di Remository.
In fondo sono poco piu' di un centinaio...roba da qualche pomeriggio...
Ora come ora pero', continua a sembrarmi piu' sensata l'accopiata SEO di sistema + SEF patch (che ho appena riapplicato).
Non so, direi che non so piu' che altro chiedervi.
A meno che non abbiate altri consigli da darvi, vi ringrazio per la pazienza e per il supporto e mi metto al lavoro sui link
18
SEO / Re: Attivare Sh404sef solo per un componente? Problemi componenti terze parti
« il: 07 Ago 2008, 12:18:33 »Citazione
No. La config dipende dal tipo e dalla sua struttura del sito oltre che dai componenti istallati. Cmq, il sito del produttore ha un ottimo forum.Provero' a chiedere anche li..
Citazione
questo non significa che non possano ugualmente funzionare bene.Eh si, questo l'ho capito...pero' anche googlando un po' non ho trovato nessuno che dicesse di essere riuscito a fare funzionare AlphaContent e SectionEX
Inoltre ho provato un po' di combinazioni, come mi avete consigliato, ma sembra che l'unico parametro importante sia "salta" e "gestione normale"...
Citazione
Se ho ben capito direi di No. sh404sef creerà dei 301 a quei downloadMi sa che non ci stiamo piu' capendo
Io pensavo questo:
- abbandono sh404sef, dato che fa funzionare 1 componente (Remository) e ne uccide altri 3 (AlphaContent, SectionEx e Easybook).
- inizio d'ora in avanti ad affidarmi solo al sef di sistema di Joomla, con SEF patch (in questo modo solo Remository ha dei brutti URL, ma almeno funziona, cosi' come funzionano Alpha e Section)
Poste queste condizioni, avevo paura che in futuro, gli sviluppatori di Remository aggiungessero delle funzioni di SEF al loro componente, che venissero sfruttate dal SEF interno di Joomla; in tal caso, tutti gli url interni che da un articolo puntano a un file di Remository, mi darebbero un 404 e potrei rischiare di doverli reinserire tutti un'altra volta.
Ha senso vero?
Perche' non mi pare che il SEF di sistema abbia opzioni che permettano di escluderlo da questo o quel componente...
Citazione
Ma non fai prima a creare delle url personalizzate in sh404 relative a remository?Oddio, come soluzione non l'avevo presa in considerazione, perche' non ho ben chiara la questione delle URL personalizzate in sh404.
Disattivi sh404, disattivi il seo nativo, vedi (e appunti) le url di remository dalla barra degli indirizzi, piazzi quelle url (partendo da "index.php?" ) nei campi "vecchia url non sef di sh404 e attribuisci la nuova url come vuoi tu.
Pero' la soluzione che mi hai proposto e' girata al contrario
Con sh404sef, come dicevo, Remository e' l'unico componente a funzionare correttamente, assieme ai Content; dovrei, piuttosto, quindi fare questa stessa cosa che mi proponi con AlphaContent e SectionEX...cercando di farli funzionare a mano a suon di URL personalizzati.
Non saprei come fare pero', perche' non e' chiaro il problema che li rovina...sopratutto per SectionEX.
In AlphaContent direi che c'e' un semplice errore di segno/simbolo negli url...quel "letter,A" invece di "letter=A"...e potrei facilmente sistemarlo.
Invece SectionEX (con sh404sef attivo) da errore 500 ogni qual volta che si va a cliccare su un articolo da lui listato...il che diventa complicato da sistemare...dovrei inserire un URL personalizzato per ognuno degli articoli, mi viene da pensare, e questa cosa la dovrei fare anche in futuro....non e' una soluzione granche' affrontabile.
Mi sono spiegato?
Io, purtroppo, dovrei stringere i tempi perche' avrei in progetto di finire il sito entro il 15 ed ho un bel po' di URL interni da sostituire.
Stavo pensando di abbandonare sh404sef, con rammarico, e utilizzare solo il SEF di sistema: secondo voi e' una buona scelta, a lungo termine?
O rischio di andare incontro a qualche problema?
Grazie a tutti per il supporto!
19
SEO / Re: Attivare Sh404sef solo per un componente? Problemi componenti terze parti
« il: 06 Ago 2008, 14:37:31 »
Ah, quindi anche i parametri avanzati?
Avevo provato a mettere mano anche li ma, sinceramente, l'ho fatto totalmente alla cieca.
Non e' che avreste una guida alla configurazione di sh404sef?
Cosi' me la studio e almeno so cosa sto facendo.
Pero' sinceramente, googlando un po' e leggendo le pagine dell'estensione, sembra proprio che io abbia scelto dei componenti per i quali c'e' poco da fare.
Non sono mai citati nella lista delle estensioni compatibili.
UPDATE:
Mi attanaglia un dubbio: se io ora uso il system sef, elimino sh404sef e inserisco i link interni relativi a remository nei vari articoli e poi in futuro remository inizia ad essere supportata dal system sef ed ad avere sef urls?
Mi ritrovo tutte le news con i link interni che puntano ai download che magicamente sono morti?
Avevo provato a mettere mano anche li ma, sinceramente, l'ho fatto totalmente alla cieca.
Non e' che avreste una guida alla configurazione di sh404sef?
Cosi' me la studio e almeno so cosa sto facendo.
Pero' sinceramente, googlando un po' e leggendo le pagine dell'estensione, sembra proprio che io abbia scelto dei componenti per i quali c'e' poco da fare.
Non sono mai citati nella lista delle estensioni compatibili.
UPDATE:
Mi attanaglia un dubbio: se io ora uso il system sef, elimino sh404sef e inserisco i link interni relativi a remository nei vari articoli e poi in futuro remository inizia ad essere supportata dal system sef ed ad avere sef urls?
Mi ritrovo tutte le news con i link interni che puntano ai download che magicamente sono morti?
20
Joomla! 1.5 / Re: [RISOLTO] Easybook 2.0.0 Rc3: i visitatori non possono firmare il guestbook
« il: 05 Ago 2008, 20:01:00 »
Non e' che ti s'installa lo stesso?
Perche' capita che dia errori di quel tipo relativi alla lingua dell'amministrazione...ma spesso sono solo dei warning totalmente ignorabili...
Io ho installato il tuo stesso componente.
Perche' capita che dia errori di quel tipo relativi alla lingua dell'amministrazione...ma spesso sono solo dei warning totalmente ignorabili...
Io ho installato il tuo stesso componente.
|
|