CONTENIDO Forum

hallo zusammen,

auf einer ansonsten fehlerfreien 4.4.5er installation erhalte ich folgende fehlermeldung beim aufruf der artikelübersicht einer kategorie:
zum verständnis:
die kategorie hat viele artikel (ca. 900 St. à 1 bis 2 DIN A4-Seiten), das problem, daß es ewig dauerte, bis die liste geladen war, hab ich später (nach eintragen von ca. 200 Art.) dadurch umgangen, daß ich in diverse kategorien unterteilt habe. diese hab ich offline geschaltet und nur die artikel per querveweis in die kategorie verlinkt, so daß sie im frontend angezeigt wurden.

jetzt müßte ich aber einen artikel löschen, den ich noch in der ursprungskategorie angelegt habe. beim aufrufen von:

content-> artikel-> besagte kategorie

erscheint jetzt aber die obige fehlermeldung , sprich ich komm übers backend nicht mehr dran...was muß ich beachten, wenn ich über phpmyadmin löschen will (falls DAS überhaupt generell noch geht...gleich mal testen)

danke

gruß
micha

Naja da sind einfach zuviele Artikel drin - ich würde den Provider fragen, ob er das memory limit heraufsetzen kann.

Über die DB würde ich nichts löschen, es sei denn, du weißt 100%ig, was genau du da löschst

provider hat´s limit mal auf 32 mb gesetzt. komme jetzt erstmal wieder übers backend ran. muß mir aber wohl ne alternativlösung überlegen, da noch 300 artikel eingestellt werden müssen und das limit dann wohl wieder erreicht werden würde....

aber danke erstmal!
gruß
micha

eine artikelliste mit über 900 einträgen? da verlangst du aber viel von deinen besuchern. die letzten einträge in der liste wird doch niemals jemand sehen. das dauert ja ewig, bis dorthin zu blättern...

aber was mir nicht einleuchten will ist die tatsache, dass die erstellung der artikelliste von der anzahl artikel abhängig sein soll. minimal dürfte das der fall sein. aber mysql wird mit läppischen ein paar tausend einträgen keine leistungseinbussen zeigen. da muss ein anderes problem vorliegen.

zur pflege im backend: ich finde es im prinzip problematisch, dass die anzahl artikel sich auf die pflege im backend (aufbau der seite) negativ auswirken kann. allerdings dürfte die pflege für den anwender in jedem fall kritisch werden, bei einer so grossen anzahl ungegliederter artikel.

hi,

der einwand wäre natürlich berechtigt, aber bei der anzahl der artikel habe ich natürlich keine artikelliste verwendet. stattdessen habe ich im startartikel eine variante des suchmoduls eingebaut, die nur in dieser kategorie sucht.

gruß
micha

noch ein nachtrag.

mit langsamen aufbau der artikelliste meinte ich die übersichtsliste im backend. im frontend funktioniert alles bestens und ohneverzögerung bei der suche.

zweiter nachtrag:
gepflegt werden die artikel in den zusätzlichen (offline gesetzen) kategorien. es wird nur der artikel zusätzlich auf die (dann für die pflege zu große) hauptkategorie verwiesen, damit er im frontend online ist (geht ja per "artikeleigenschaften" im backend).

dann ist dein problem gelöst, oder?

im prinzip ja.
der provider gab mir aber zu verstehen, daß er ein höheres memory-limit als 32mb nur ungern einstellen würde wg. dann potentieller server-probleme. da aber "noch 300 artikel to go" sind, kann ich diese somit nicht mehr auf die hauptkategorie verweisen lassen. aber die angepaßte suche auf eine weitere kat auszuweiten sollte nicht das problem sein.

von daher: ja, problem eigtl. gelöst.

danke

gruß
micha

kummer hat geschrieben:zur pflege im backend: ich finde es im prinzip problematisch, dass die anzahl artikel sich auf die pflege im backend (aufbau der seite) negativ auswirken kann. allerdings dürfte die pflege für den anwender in jedem fall kritisch werden, bei einer so grossen anzahl ungegliederter artikel.

ich bin mal ganz frech und bezeichne das als bug...
es sollte im backend bei der artikelübersicht eine blätter funktion geben...
zb max. 20 artikel auf einer seite und dann blättern... vielleicht auch noch ne option gehe zu seite bla bla und bei dieser menge ebentuell ebenso ne option um nach artikel suchen zu können... (fehlt leider komplett)

sehe ich ähnlich, wollte aber nicht ganz so frech sein
die aufgezählten features wären jedenfalls überaus wünschenswert und sinnvoll...