Hallo allemaal,
gisteren hebben we via de ModuleManager o.a. de Uploads-module ge-updated. Helaas breekt de site nu wanneer we de op de 'Detail'-link klikken. We hebben dit bij verschillende van onze sites bij verschillende providers ondervonden.
Hebben meerdere mensen dit ondervonden en heeft iemand een idee hoe we dit kunnen oplossen?
met vriendelijk groet,
Ron Hoenson
HGPDESiGN
Site breekt na update Uploads module
Moderator: velden
Re: Site breekt na update Uploads module
Zonder technische informatie kunnen we je niet helpen
- + - + - + - + - + - + -
LATEST TUTORIAL AT CMS CAN BE SIMPLE:
Migrating Company Directory module to LISE
Migrating Company Directory module to LISE
- + - + - + - + - + - + -
Re: Site breekt na update Uploads module
Rolf,
ik ging er vanuit dat veel meer mensen deze problemen ondervonden en dat het een soort 'algemeen' probleem was/is.
Bij deze onze info - we hopen dat het helpt. I.i.g. alvast bedankt voor de moeite.
Gr. Ron Hoenson
----------------------------------------------
Cms Version: 1.11.4
Installed Modules:
CMSMailer: 5.2.1
FileManager: 1.4.3
MenuManager: 1.8.5
ModuleManager: 1.5.5
News: 2.12.10
Printing: 1.1.2
Search: 1.7.7
ThemeManager: 1.1.7
Statistics: 1.1.3
FrontEndUsers: 1.21.2
CustomContent: 1.8.3
CGSmartImage: 1.9.5
CGExtensions: 1.31.3
Uploads: 1.14.4
FormBuilder: 0.7.3
JQueryTools: 1.2
CMSPrinting: 1.0.3
MicroTiny: 1.2.5
Config Information:
php_memory_limit:
process_whole_template:
output_compression: false
max_upload_size: 10000000
url_rewriting: none
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale: nl_NL.utf8
default_encoding: utf-8
admin_encoding: utf-8
set_names: true
Php Information:
phpversion: 5.3.3
md5_function: Aan (Waar)
gd_version: 2
tempnam_function: Aan (Waar)
magic_quotes_runtime: Uit (Onwaar)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 90
output_buffering: 4096
safe_mode: Uit (Onwaar)
file_uploads: Aan (Waar)
post_max_size: 10M
upload_max_filesize: 10M
session_save_path: Geen controle omdat 'open_basedir' actief is
session_use_cookies: Aan (Waar)
xml_function: Aan (Waar)
xmlreader_class: Aan (Waar)
Server Information:
Server Api: apache2handler
Server Db Type: MySQL (mysql)
Server Db Version: 5.0.77
Server Db Grants: Er is een "GRAND ALL" permissie gevonden, alles lijkt in orde.
----------------------------------------------
ik ging er vanuit dat veel meer mensen deze problemen ondervonden en dat het een soort 'algemeen' probleem was/is.
Bij deze onze info - we hopen dat het helpt. I.i.g. alvast bedankt voor de moeite.
Gr. Ron Hoenson
----------------------------------------------
Cms Version: 1.11.4
Installed Modules:
CMSMailer: 5.2.1
FileManager: 1.4.3
MenuManager: 1.8.5
ModuleManager: 1.5.5
News: 2.12.10
Printing: 1.1.2
Search: 1.7.7
ThemeManager: 1.1.7
Statistics: 1.1.3
FrontEndUsers: 1.21.2
CustomContent: 1.8.3
CGSmartImage: 1.9.5
CGExtensions: 1.31.3
Uploads: 1.14.4
FormBuilder: 0.7.3
JQueryTools: 1.2
CMSPrinting: 1.0.3
MicroTiny: 1.2.5
Config Information:
php_memory_limit:
process_whole_template:
output_compression: false
max_upload_size: 10000000
url_rewriting: none
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale: nl_NL.utf8
default_encoding: utf-8
admin_encoding: utf-8
set_names: true
Php Information:
phpversion: 5.3.3
md5_function: Aan (Waar)
gd_version: 2
tempnam_function: Aan (Waar)
magic_quotes_runtime: Uit (Onwaar)
E_STRICT: 0
E_DEPRECATED: 0
memory_limit: 128M
max_execution_time: 90
output_buffering: 4096
safe_mode: Uit (Onwaar)
file_uploads: Aan (Waar)
post_max_size: 10M
upload_max_filesize: 10M
session_save_path: Geen controle omdat 'open_basedir' actief is
session_use_cookies: Aan (Waar)
xml_function: Aan (Waar)
xmlreader_class: Aan (Waar)
Server Information:
Server Api: apache2handler
Server Db Type: MySQL (mysql)
Server Db Version: 5.0.77
Server Db Grants: Er is een "GRAND ALL" permissie gevonden, alles lijkt in orde.
----------------------------------------------
Re: Site breekt na update Uploads module
Intussen zijn we al wel wat verder gekomen.
In het beheerlogboek vonden we de volgende foutmelding:
ERROR DETECTED: Cannot access empty property at /customers/b/9/4/rh57.nl/httpd.www/modules/Uploads/action.detail.php:128
We hebben daarop het betreffende bestandje (action.detail.php) vervangen door de vorige versie en nu werkte alles weer naar behoren.
De betreffende regel 128 geeft het volgende verschil te zien:
Vorige versie (1,14.3) en werkend:
Regel 128:
$row->iconurl = $imgpath.$filetype['image'];
In de nieuwste versie (1.14.4) en problemen gevend:
Regel 128:
$row->iconurl = $imgpath.$row->$filetype['image'];
Deze aanpassing (in action.detail.php) bleek trouwens het ENIGE VERSCHIL te zijn met de vorige versie (1.14.3). De ontwikkelaar zal dit dus met reden gedaan maar welke kunnen we niet goed doorgronden (wij zijn geen ontwikkelaars). We voelen ons derhalve niet helemaal op ons gemak met deze handmatige aanpassing en vragen ons af welke gevolgen dit zal hebben op toekomstige upgrades.
Wellicht ligt e.e.a. aan onze basisinstellingen maar als eerder gezegd hadden we dit probleem met meerdere sites bij verschillende providers, zelfs bij een speciaal aangemaakte cleane CMSMS-installatie.
Kan iemand het bovenstaande doorgronden en wat zijn de consequenties voor onze toekomstige upgrades?
Vriendelijke groet,
Ron Hoenson
HGPDESiGN
In het beheerlogboek vonden we de volgende foutmelding:
ERROR DETECTED: Cannot access empty property at /customers/b/9/4/rh57.nl/httpd.www/modules/Uploads/action.detail.php:128
We hebben daarop het betreffende bestandje (action.detail.php) vervangen door de vorige versie en nu werkte alles weer naar behoren.
De betreffende regel 128 geeft het volgende verschil te zien:
Vorige versie (1,14.3) en werkend:
Regel 128:
$row->iconurl = $imgpath.$filetype['image'];
In de nieuwste versie (1.14.4) en problemen gevend:
Regel 128:
$row->iconurl = $imgpath.$row->$filetype['image'];
Deze aanpassing (in action.detail.php) bleek trouwens het ENIGE VERSCHIL te zijn met de vorige versie (1.14.3). De ontwikkelaar zal dit dus met reden gedaan maar welke kunnen we niet goed doorgronden (wij zijn geen ontwikkelaars). We voelen ons derhalve niet helemaal op ons gemak met deze handmatige aanpassing en vragen ons af welke gevolgen dit zal hebben op toekomstige upgrades.
Wellicht ligt e.e.a. aan onze basisinstellingen maar als eerder gezegd hadden we dit probleem met meerdere sites bij verschillende providers, zelfs bij een speciaal aangemaakte cleane CMSMS-installatie.
Kan iemand het bovenstaande doorgronden en wat zijn de consequenties voor onze toekomstige upgrades?
Vriendelijke groet,
Ron Hoenson
HGPDESiGN