Jump to content

Lutz

Members
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

19 Good

About Lutz

  • Rank
    Jr. Member

Profile Information

  • Gender
    Male

Recent Profile Visitors

957 profile views
  1. It was closed on 10 Jun 2016, but it's still (or again) an issue (PW 3.0.132).
  2. @kongondo Yes, thank you, this is what I had expected and hoped for. My question was in terms of scalability, regarding file system limits. In PW, files are stored in subdirectories under /site/assets/files, therefore we normally have to deal with max directory limits (e.g. 32k). We have $config->pagefileExtendedPaths, but it's marked as beta. So as you mentioned +500k, I hoped for an info regarding the stability of pagefileExtendedPaths (or another way to avoid collisions with max directory limits). When they manage +500k, did they enable pagefileExtendedPaths?
  3. @kongondo To prevent a misunderstanding: each media is stored in the database, not in the file system?
  4. @kongondo Good to know (+500k), do they use $config->pagefileExtendedPaths, an unlimited file system or are there special features of the Media Manager for storing the images?
  5. @adrian I think we were wrong. $pages->get() should return a NullPage, but with $categories->get() you are using WireArray::get()!?
  6. You are right: $categories returns a PageArray, so I thought that get() should return a NullPage in both cases.
  7. get() should return a NullPage in both cases, if $categories returns a PageArray. Since find() could return a PageArray or an array: what does $categories return?
  8. @teppo Thank you very much. Yes, I plan to go with ProCache and to avoid template caching for most of the templates. I think I misunderstood the comment of Soma regarding the template cache problem, thanks for the hint.
  9. Ok, I read the issue 432 thread again, so yes, the need to "revisit" (Ryan) could refer to the implementation of the template cache only. However, it would be good to know if pagefileExtendedPaths is a reliable option and I'm glad that you suspect that this is true.
  10. @teppo Maybe I'm wrong, but no, the config option pagefileExtendedPaths is a result of that discussion and the comments of @Soma and @ryan refer to the concept of extended paths.
  11. @teppo I hope so. There's an open ticket "Feature-Request: More options how to store files under site/assets/files" from 2014, where @Soma warned regarding problems with pagefileExtendedPaths when using template cache and @ryan answered in his last comment: "That's a good point, as the structure is flat. Will have to revisit that with a similar solution to the files at some point in the future." https://github.com/ryancramerdesign/ProcessWire/issues/432
  12. We still have this warning in wire/config.php: "The extended file mapping feature is not yet widely tested, so consider it beta." Does anyone have $config->pagefileExtendedPaths in use on a production server?
  13. @horst Great, thanks for the explanation. Despite such rare errors I personally prefer those loose connections between Dev (local), Staging and Production, compared to the stricter ones you usually need with Craft.
  14. @horst There's another thread, SVG files do not seem to be involved there.
  15. @dragan Many thanks. I think the timings strongly depend on the conditions. Sometimes a large number of pages could be uncached, and I know from experience that peaks (e.g. 60+ page views per second) can change the meaning of overhead enormously. Maybe it's interesting to have a closer look on all those queries, thanks for the example. I too see queries that I don't understand so far. For example 37 SELECT id, templates_id, parent_id FROM pages WHERE (name=:name) LIMIT 2 38 SELECT id, templates_id, parent_id FROM pages WHERE (name=:name) LIMIT 2 39 SELECT id, templates_id, parent_id FROM pages WHERE (name=:name) LIMIT 2 40 SELECT id, templates_id, parent_id FROM pages WHERE (name=:name) LIMIT 2 or SELECT false AS isLoaded, pages.templates_id AS templates_id, pages.*, pages_sortfields.sortfield, (SELECT COUNT(*) FROM pages AS children WHERE children.parent_id=pages.id) AS numChildren,field_title.data AS `title__data` FROM `pages` LEFT JOIN pages_sortfields ON pages_sortfields.pages_id=pages.id LEFT JOIN field_title ON field_title.pages_id=pages.id WHERE pages.parent_id=1018 AND pages.templates_id=54 AND pages.id IN(1061) GROUP BY pages.id I will have a look at ProfilerPro, maybe it could help to get a better understanding of the boot process.
×
×
  • Create New...