update probleem 3.2.0 site

Ja, ik heb niet de echte url/sitenaam genoemd. Als je die echt moet hebben:

Even bij een andere 3.X.X site gekeken (draait bij een andere providor): daar is wel een README.txt aanwezig

Edit Jelle. Ik heb de code tussen codetags geplaatst, volgende keer graag zelf doen.

Misschien is er in het verleden bij een update iets misgegaan.
Wat gebeurt er als je met FTP handmatig dat bestand toevoegt aan deze site.

De site draait van nov/dec2013, 3.2.0. is volgens mij de status waarin de site is aangemaakt
Toevoegen van een README.txt maakt geen verschil: de update.zip blijft een 3.2.4 aangeven, en een zelfde: , met extensie: .md

Al met al kom ik niet verder; zijn er nog meer opties?

Vermoedelijk een probleem met serverconfiguratie. Site naar lokaal halen, updaten en dan terugzetten of overstappen naar een andere hoster.

Ik heb contact opgenomen met de providor (ik zal de naam maar niet noemen), en tegelijk nog wat testjes gedaan. Het komt er op neer dat er een server-probleem is, en daarom bieden ze nu aan om voor de site waarin het probleem nu speelt + een tweede soortgelijke site waarin in feite dezelfde problematiek (!) een paar maanden terug zich ook voordeed, een andere server beschikbaar te stellen. Ik moet de boel dan zelf overzetten!
Men komt met een redelijk technisch verhaal, het klinkt me als relatieve leek aannemenlijk in de oren; is het dat ook? En ben ik dan van mijn update-probleem af?

De server waar uw pakket op staat is een Linux-server waarvan de PHP-omgeving als ApacheModule werkt en niet op basis van FastCGI of SuPHP.
Daarom zouden (tbv de update) alle files en mappen op 777 gezet moeten worden zodat Apache (de PHP-updater van Joomla) alle bestanden en mappen kan beschrijven.
Na het updaten moeten alle mappen weer op 755 en alle bestanden op 644 worden gezet worden anders kan Iedereen in alle files schrijven en dat is gevaarlijk.
Dit is op deze server helaas niet op te lossen.
Het makkelijkste is om de files met de hand te uploaden en alles te vervangen wanneer daar om wordt gevraagd.

Als u dit probleem permanent op wilt lossen dan kan er een pakketswitch gedaan worden naar een andere server met het Plesk Control Panel waar wel gebruik wordt gemaakt van SuPHP (FastCGI).
De inhoud van de website moet dan volledig worden overgezet (bestanden, database en mailboxen).

Edit Astrid: Ik heb de quote tussen tags geplaatst, volgende keer graag zelf doen.

Tja, wat zal ik er van zeggen? Ik zou direct afscheid nemen van een hoster die blijkbaar zijn zaakjes niet voor elkaar heeft en zowel zijn klanten als de vrijwilligers van dit forum veel tijd kost.
En voor zover ik heb begrepen (maar is echt horen zeggen) is suphp alweer achterhaald door mod_ruid2.
Maar het principe van zijn verhaal klopt wel.

Oeff... 777 dat is zooo, niet netjes!!!

Pinpas met pincode opsturen is veiliger, kan maar 1 x misbruikt worden...

Oke, en dank je wel voor jullie antwoorden!

Vrgr, Wietze