rusjoan

Woohoo! Thank you guys, now it works! I simply copied those files of mentioned commit because I have no idea how to work with 2 repos in one git-project while all of your dirs except "wire" should contain only your data but not from PW-repo. Maybe anyone can tell me about the way to keep PW up-to-date? @WillyC there were most of pages with filled fields

Good solution, thank you. But my trouble is a bit different...

Hi! This topic is not about a real big data, but nonetheless PW can't hold it I created a template ("task") with couple of text fields and one repeater field. This repeater has 3 text fields and 2 textarea fields. There are 2374 pages using this template. When I've decided to restructure my DB I went in a real trouble. Restructuring is in that I make new template with all of mentioned repeater fields and I remove 2 "massive" textarea fields from repeater. Then task-template pages should become smaller in DB and I'll get ability to do stats analysing faster, and task page still can get 2 textarea fields values from another page if needed. I moved all of mentioned 2 fields data to new pages then tried to remove these fields from repeater. But here's what I've got: Then I launched script to clear values in these fields (set to ""). This was slow and boring but it's done. And after new attempt I've got the same error. My suggestion is: script, that removes fields, tries to do $pages->find() for all of pages that use given field. But data size from DB is too big to locate in allowed RAM — textarea uses MEDIUMTEXT innodb type what's about 16 Mib. This case is why I made my script to clear fields values by iterations of 10-50 pages to avoid memory overflow. How I can remove these fields? The only solution is to temporarily give PW more RAM by performing ini_set( )?

Thanks guys, so now I know a real reason of this issue. It's true that server and local PHPs has different versions Changing user password under other admin account helped me

I published my site to remote host and now I can't login to admin with old credentials. All config and DB same as on my local. Tried to switch off "session fingerprint" and other stuff and it doesn't help me. Any suggestions? Thanks.

What is more "expensive" — simple query to DB or simple check file existence on file system (let's suggest that we work with SSD)? This question was originated to me recently when I decided to make "Cancel" function in file downloading script. This script works as background for limited time. It compares current execution time with limitation and breaks download task if time has expired. Also breaking mean removing of all downloaded files, and then task status equals "Fail". "Cancel" function works the same — clear task dir when download has canceled. So execution time check function doesn't require access to hdd or db and we can check it on each file download iteration. Also script makes query to DB to update task download status (percents) no more than once a second (controlled by a separate function). When I decided to make "cancel download task" function I stuck on a question — what is more optimal to make script check his status for "cancel"? Check for file existence (e.g. "cancel-{taskID}.txt") or check the same in DB? This all goes from that I'm using PW engine and I can't combine SQL-queries (update task status, check task cancel status..) by engine's native tools. If you work only with engine selectors and don't write any "clear" SQL-queries in a whole project it's obvious to try continue the same UPD: I know that access DB is cheaper than access HDD. But what about SSD?

Now googled same topic: https://processwire.com/talk/topic/4655-find-pages-by-createduser/ So I decided to try created_users_id=.. and it works! OK, then now another question: where is official information about this behavior? I'm sure that PW-novices should know about these nuances from API doc but not from self-searches

It's so strange that I can't select pages like this: template=foo, createdUser=1018 It gives such error: Uncaught exception 'PDOException' with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column 'pages.createdUser' in 'where clause'' in ... My suggestion is in: error causes because of selector engine allows to select by createdUser, but this is a service field and it doesn't exist in DB.

Thank you so much! Trouble really was in it.

$config->debug = true really helpful. Now I see this: Also I tried to reinstall VKAPI module..

OK, I'm agree with you, moreover I used this technique all time. Otherwise if internet-shop provide using online-constructors there is a real trouble to store all of user constructed data in sessions or cookie variables. The trouble itself is on we should to choose format to store data from different types of constructors. And then when user makes order, this data would be transformed to pages-form in PW DB. Is there a way to convert pages into session-storable variables? Wish there a way to convert page into assoc array and then json_encode it.

What does this red banner in modules admin section mean? This is the trouble module: VKAPI.module But I'm sure all correct... I see no reason to display error banner. Help please. P.S. Also I tried to publish this module to PW modules library but there're a lot of fields, and I stopped at "Enter forum topic for ur module" and "Enter github repo url". Why I can't just upload module? Checking versions via git is so good, but not in any situation.

My situation is potential, so now I haven't so big DB size but this is achievable in the future. What about template with lots of fields — this is not in my case but you got me interested in it. What does allow to build one "big" field what contains a lots of rows? It isn't Fieldset?

Let's talk about possibility to archive pages from DB. I mean if your site collected a big amount of data and after some time you won't to store it in DB then you should have a tool to do archiving. Simply delete old pages is not best practice sometimes (e.g. in my situation). Archiving in my look is a process when old unused data compressing in DB (I don't know how, just my suggestion) with no ability to access it. And if you want this data again — you must decompress it. So we have 2 time-consuming processes — compressing and decompressing, but we save on DB size. But on other way we can do it more simply: you export a number of pages to one file to HDD and remove they from DB. How can this be organized (I mean first method)? What does PW provide in this instance?

I continue my monolog. I removed if ( empty(wire('user')->token) ) wire('session')->logout(); in the start of userProcess( ) because this method is calling before Pare::render by installed hook. But /login page calls process( ) method while page renders. So $user->token will be empty or wrong at this time. And, as I suggest, session->logout doesn't allow to run session->login on process( ) method.