| # |
Jun 5th 2021, 18:23 |
 kevin.pfeifer |
`->count()` is the whole query without limit but `$douments->toArray()` is actually the array whicht gets passed to your view |
| # |
Jun 5th 2021, 18:23 |
etibor |
```LIMIT 30 OFFSET 30``` |
| # |
Jun 5th 2021, 18:23 |
etibor |
yes you are right @kevin.pfeifer it does got the : ```LIMIT 30 OFFSET 0``` on the first page, while on the second |
| # |
Jun 5th 2021, 18:22 |
kevin.pfeifer |
otherwise you result object only has one entry in there? |
| # |
Jun 5th 2021, 18:20 |
kevin.pfeifer |
after doing the `->paginate()` function on your query object it should have the limit inside the `->sql()` function |
| # |
Jun 5th 2021, 18:17 |
etibor |
thank you @kevin.pfeifer |
| # |
Jun 5th 2021, 18:16 |
etibor |
$documents->count() returns 1210 |
| # |
Jun 5th 2021, 18:15 |
etibor |
i checked $documents->sql() it does not contain any limit or offset |
| # |
Jun 5th 2021, 18:12 |
kevin.pfeifer |
when you check the sql query with debugkit does it say limit 30? |
| # |
Jun 5th 2021, 18:06 |
etibor |
and debug($this->paginate); shows limit 30 record / page |
| # |
Jun 5th 2021, 18:05 |
etibor |
i dont know whats the reason why pagination return only one record per page, because at the bottom of the page its shows 30 record/page |
| # |
Jun 5th 2021, 18:04 |
etibor |
Hello everyone |
| # |
Jun 5th 2021, 15:47 |
admad |
Regardless I approve of the tweet for Linkin Park reference :) |
| # |
Jun 5th 2021, 15:43 |
ndm |
Not really into crypto either, but yeah, it looks like the game is still on :) |
| # |
Jun 5th 2021, 15:42 |
admad |
Oh he did another tweet yesterday :,) |
| # |
Jun 5th 2021, 15:39 |
admad |
@ndm I would like to have BS based "official" skeleton but as we have seen that's not achievable with just template changes. |
| # |
Jun 5th 2021, 15:37 |
admad |
Not into the crypto scene, the blood bath post Elon shenagins continues? |
| # |
Jun 5th 2021, 15:36 |
ndm |
People contemplation with self-deletion after checking their bitcoin wallets? |
| # |
Jun 5th 2021, 15:35 |
admad |
I agree |
| # |
Jun 5th 2021, 15:28 |
kevin.pfeifer |
looking at https://packagist.org/packages/cakephp/cakephp/stats i wonder what happened last month :thinking_face: |
| # |
Jun 5th 2021, 15:03 |
ndm |
I know, but the shipped defaults are just for prototyping anyways... I'd personally would've rather seen the framework's userbase increase by giving the kinds the hip stuff. |
| # |
Jun 5th 2021, 15:02 |
kevin.pfeifer |
not only classes but some DOM changes too I guess |
| # |
Jun 5th 2021, 15:02 |
dereuromark |
Less easy to move away from again |
| # |
Jun 5th 2021, 15:02 |
dereuromark |
The idea Was minimal overhead on the default HTML. Bootstrap requires more class adding ootb |
| # |
Jun 5th 2021, 15:00 |
kevin.pfeifer |
I can imagine that this was definitely not an easy decision back then but as you said it wouldn’t matter that much any more I remember the “old” cake 3 default styling was even more “oldstyle” than the current milligram variant in my opinion :) |
| # |
Jun 5th 2021, 14:57 |
ndm |
Doesn't really matter anymore now though, that horse is already in a tube of glue. It would've mattered back then, but now, I don't think Bootstrap would attract many new users. |
| # |
Jun 5th 2021, 14:55 |
ndm |
and foundation, yeah... which is less esoteric, but still not even closely as popular as bootstrap, at least that was the case back then, not sure how it's nowadays. |
| # |
Jun 5th 2021, 14:53 |
kevin.pfeifer |
you mean miligram as esoteric? |
| # |
Jun 5th 2021, 14:52 |
ndm |
Still a pity IMHO that CakePHP chose the esoteric frameworks instead... going with Bootstrap would have been way more popular. But that's a different topic I guess. |
| # |
Jun 5th 2021, 14:50 |
ndm |
Understandable... I was never a fan of the "frontend" pages made with bootstrap to begin with, but for "backends" I don't mind it. |
| # |
Jun 5th 2021, 14:47 |
kevin.pfeifer |
but I worked with and looked at so many bootstrap pages that I just can’t stand them any more |
| # |
Jun 5th 2021, 14:47 |
kevin.pfeifer |
im sorry ,:) |
| # |
Jun 5th 2021, 14:43 |
ndm |
You're welcome... even after learning that you're a bootsrap-ophobe :P |
| # |
Jun 5th 2021, 14:38 |
kevin.pfeifer |
ok, then I will do that :) thx |
| # |
Jun 5th 2021, 14:36 |
ndm |
the browsers I mean |
| # |
Jun 5th 2021, 14:36 |
ndm |
Or maybe they wouldn't... sensitive data and what not. |
| # |
Jun 5th 2021, 14:35 |
ndm |
In a perfect world browsers would offer such functionality out of the box I guess... anyways, sure, why not, generally reasonable I guess :) I'd say it's a good fit for a component, it knows about the request object, you can inject the additional model dependency so that it can create entities with the data from the cookie, and you let it manually know (when your save succeeds) that you want the cookie to be set/updated. |
| # |
Jun 5th 2021, 14:31 |
slackebot |
(yea, i know) So I thought well, lets create a cookie with a 1 year lifespan or something stupid. |
| # |
Jun 5th 2021, 14:31 |
kevin.pfeifer |
OK, the full example is the following: I am in a choir and created a registration page for our choir members to “register” on each choir practice with name, email and phone because we need the info if one of our members has COVID. Since we have lazy ass members they now asked me if I can “save” their data without the need of them creating an account on my page so they don’t need to fill out those 3 input fields |
| # |
Jun 5th 2021, 14:27 |
ndm |
Well, it's definitely not something that should be in your model in any way shape or form, that's really not it's concern. Whether the concept makes sense... depends I'd say, on what kind of data it is, why it needs to seemingly survive across sessions, etc. |
| # |
Jun 5th 2021, 14:24 |
kevin.pfeifer |
or is this a horrible idea :) |