znalazłem błąd w mlboxie, w czasie zmieniania zdjęć jak się za szybko kliknie - jak jeszcze nastepne zdjecie sie nie otworzy to znika cień, zdjęcia sie przewijają ale nie da się ich zamknąć, błąd jest w wersji 4 rc, u mnie też to występuje, można szybciej wykryć bo fotki są wieksze http://www.obrazygaleria.pl/?obrazy-olejne-architektura-miasta-i-budynki,44 - wystarczy troche szybciej poklikać na fotki, jutro pewnie powróce na starego liteboxa, chyba że da się to jakoś naprawić
oryginalny plik ze strony producenta mlbox.js się różni i o dziwo tam smiga ok, myślę że cos jest źle ustwione, jak rozwiązecie ten problem to dajcie znać ze juz wszystko jest ok
Faktycznie ten blad wystepuje gdy szybko sie przewija zdjecia i klika za duzo. Nie da sie pozniej zamknac okna. Zaprzeczam jednak, ze dzieje sie to tylko w Quick.Cms. Wersja oryginalna tez ma ten blad bo sprawdzilismy to. Wyslalismy informacje do producenta mlbox'a o tym.
w tym mlbox by sie przydało dorobić zliczanie zdjęć np. "Zdjęcie 1 z 15" jest to bardzo przydatne, w wersji final by się takie cos przydało. Narazie nie widze innych błędów wszystko pieknie śmiga. Ciekawi mnie jak przenieść <div id="navipath">$sPagesTree</div> żeby było tak jak w ver4, coś mi nie wychodzi, można by było to wrzucić do art z poprawkami, bo jak ktoś nieumiejętnie zmienia wielkość headera, slogana czy logo to ten tekst ucieka gdzieś pod spód, w sumie jest to mały błędzik że to sie tam znajduje w 4 jest to pięknie załatwione.
treewood - zostałem "zaklikany" ale tak łatwo się nie poddam :)
Tak przy okazji naprawy "klikacza" może warto pomyśleć o piątkowej sugestii w mailu (Rap1/p1, w sprawie zdjęć). Celowo nie podaje tutaj tego punktu bo ciekawy jestem czy ktoś to zauważy przy testowaniu zdjęć.
euphoria-art - z calym szacunkiem dla Ciebie ale malo czego nie podpinasz pod kategorie blad ...
openzibi - zwrocimy sie z tym do autora jako sugestie. w wersji finalnej watpie, ze to sie znajdzie bo nie bedziemy czekali na autora by to zrobil a sami od siebie tez nie chcemy przerabiac tego skryptu za bardzo bo pozniejsze autora aktualizacje beda znacznie utrudnione w takim przypadku.
Wy piszecie o tym by bylo widac informacje 3 na 20 zdjec a dla mnie osobiscie ta opcja jest malo przydatna i nie istotna. Jednak bardziej brakuje mi wgrywania/cache'owanie do pamieci kolejnego zdjecia z litebox'a tak, ze przegladanie bylo o wiele szybsze i wygodniejsze. I suma sumarum sie okaze, ze zrobimy drugi taki sam litebox, ktory zajmuje podobna wielkosc. Idealnie by bylo gdyby w prosty sposob mozna bylo usuwac dane niepotrzebne indywidualnemu uzytkownikowi opcje i funkcje z kodu JavaScript ale tak niestety nie jest.
Wiec albo rybki albo akwarium. Zobaczymy co ludzie beda pisac. Jesli beda duzo narzekali to wrocimy do liteboxa, jesli beda srednio narzekali to zrobimy tutorial jak wgrac liteboxa.
why are the "header" names inside the db file?? in EACH LINE???? do you know how this will fcuk up the large files?
It's important to keep filesizes down, because large sizes in conjunction with php/server bugs tend to get corrupted (you remember problems in 1.x and 2.x?)
I have developed a streamlined format for you guys which is much better programmatically than this in v. 4.0. I am willing to share and offer free code and will work for you for free, if you abolish this abomination.
Yeah, one more note, my new format is successfully tested and is working pretty much fluently with 18000 products, 2000 users, more than 40000 images and more than 150000 product features. Yes, this is flat files on a normal server. Currently in production on that server.
beholder - serialize is: - in many times faster then standard Quick.Cart v3.x-v4.x flat files. for example the same data with 2008 products in old database is sized 395 KB and in new one 776 KB but ... in new method data are get faster over 23-25%!!! - the same memory usage ... scripts use the same memory usage. in this example to get data from file with old structure it use 2.37MB and in new method 2.37 MB of memory - easier to add new fields
Our scripts are for small sites then size of site is not so important then flexible and time generating.
If you will have problems with size then you can use base64_encode( gzcompress( serialize( $aData ) ) ) http://pl.php.net/manual/en/function.serialize.php#103761
Using base64_encode and gzcompress file size is down from 776 KB to 26KB!!! (yes it is not mistake: 26 KB) And time to generates code (with uncompress and base64_decode) is 10-15% longer then standard version QC v3.x-v4.x. And memory usage in this situation is still 2.37 MB
Then please tell me ... where is problem? With new method using gzcompress You can create database much much bigger then in QC v3.x-v4.x ... but for what and why? Script is not designed to this big architecture. It is designed to max 1000 products to have still good time generating.
Of course you can compress only data that are big for example orders, products but pages, payments, files to get better performance you can save without gzcompress.
And finaly ... remember that flat files are not problem in this situation. Script dont have problem to get data from 1 MB or 50 MB file. Yes it is true. I can get specific data from file() function moving to while( fgetcsv() ) and there is no limit of file size to open file.
Problem is caching idexes by generateCache in Products, Orders, Pages and Files classes. Because this indexes takes much memory because they cache WHOLE file to memory. But this indexes in small database are much faster to get data of product/page etc. then open file many times in one page/product view. Script open file once and cache everything. No need to reopen file 10 times in one view.
Now you know what lacks. Not files but indexes. Architecture of our script are designed to small size sites with max performance. You want simple and max speed script to small site without caching scripts etc to big traffic then QCMS will be ok. Try to generate simple page in small wordpress ... check its time generating ... and compare with old or new QCMS for example ...
I've tried. Wordpress without any modifications with 3-4 sites, homepage generates: 0.27 sec. QCMS v4.0 with 10 pages (demo version) homepage generates: 0.026 sec. 10 times faster ... then if you install cache plugin to wordpress then you will get time like QCMS v4.0 without any changes.
for that matter, if you wanted to keep filesize small and the format readable, you would have use json_encode and json_decode. Furthermore you would have only stored a json encoded format of a sequential array: $aProduct_data_to_encode = array(0=>'1', 1=>'Argent High', 2=>'20.00',etc... )
json_encode() result would be: ["1","Argent High","20.00",...]
.. and you would store 'header data' of a db file in a separate file, like it was until now.
That way you would get much better results like now although perhaps adding fields would be a bit more difficult to make programmatically (it would be however the same for the adminstrator as it is currently done in QCMS 4).
But I was talking about much deeper changes. Storing for example product_features was horribly inefficient in previous QCs. I have solved 2 problems: I stored features for any given product on one line. That line was ALSO the same line as the product ID. So features of a product with ID 222 would all be stored on line 222 of file features_products.php. This allowed for a blitz-reading from product features file, remember, previously I had 150000 features entries. Plus other advantages.
Products features was a tough nut, btw, this format was especially good for products_pages.php file. You would have just a single line for each product, each line with page numbers delimited by a comma. You need pages of a certain product? You go $aPP= file(PRODUCTS_PAGES); return explode(',', trim($aPP[$iProduct])); It was blazingly fast. (and this is also just a simplified example of what can be done, not really efficient)
And not just that. I have also developped a system of writing changed and new data of products/features into intermediate small cache files, which would be added to the main files later, when time is good and a real admin is doing the work. This completely prevents many write accesses to a large file (which subsequently fucked up the file) or page reloads during long writes (which can also fuck up the file). Works perfectly. I had large files fucked up 3x daily before. Now there is not a single problem.
What I have here is gold. What you have with serialize is a step back into stone age where everything was 'simple'. We can transmute my gold into platinum, if you want. Or at least take my suggestions about json and simpler format to save into data files. This will keep files low on size. You just CAN'T save headers with every single product data!! Damn, how can I explain this better!!!??
beholder - i've edited and added some text. read again my last post. json - longer generates data then serialize. we've checked it ... but ... you have your opinion, we have our opinion. our priority is not less size of file but performance. we choose this way ... life, implementations and profits will show us that we have mistaken or not.
now it is too late to change direction especially that we are confident that this way is good.
in older version each field was separated with $. now it looks very messy...
------------------------- problem. when i change whatever word or letter directly in db, for example a word HI with HEY, I get "The data could not be found" and I can't see any pages in admin side too. What the hell is that?
