Jump to content

LostKobrakai

PW-Moderators
  • Content Count

    4,797
  • Joined

  • Last visited

  • Days Won

    98

LostKobrakai last won the day on February 19

LostKobrakai had the most liked content!

Community Reputation

4,929 Excellent

5 Followers

About LostKobrakai

  • Rank
    Hero Member
  • Birthday 11/29/1991

Contact Methods

  • Website URL
    http://www.kobrakai.de

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

16,718 profile views
  1. $page->images->slice(0, 5)->implode(function($image) { return "<li><img src='$image->url' alt='$image->description'></li>"; }, array('prepend' => '<ul>', 'append' => '</ul>')); This would be the processwire api equivalent. From looking at the perch example I'm wondering if they use it for creating templates based on the markup. Otherwise I'm not sure why a lable would be given here.
  2. I mean the cmd in windows by now is missing a lot of basic stuff
  3. @buster808 Can you please use the code blocks provided by the forum instead of copy pasting directly from your editor into the post. It's really hard to read the way they're right now.
  4. The export/import feature of pages does only transfer pages not fields. There's a similar feature for fields though.
  5. To me site profiles are startpoints. I see it as bundle of dummy/base content + the necessary modules for letting the site work in its installed form. For keeping the profile itself up to date for future installs I‘d probably use git submodules, but distribute it as plain zip with everything in it (iirc github does that for the zip download). When things in a site should be managed after the initial installation as well I think it should be done by a module (can be installed by the profile as well). The module can handle all the necessary changes to content on update and has ways to setup dependencies to other modules. Sadly we‘re currently in a weird middle state of having kinda integrated composer, but also really just using is as a parallel universe, which means you either use composers dependency resolution or processwire‘s, which to me means skipping conposer is currently the better way if broad adoption is the goal.
  6. I'd much rather have this in the modules directory, but it still has potential: maybe some config, an option to add custom domains, fresh/stale status detection or a manual way to trigger list retrieval (also retrieve it on install). I mostly wanted to get the basics across and show that often times it's not too hard to implement stuff on your own. This became a 100 line file with maybe ~30 lines of actual business logic. I'd be happy if someone else would pick it up from here and properly support it as a module in the directory. I simply don't want to add more to the few stale modules I already have with no longer doing much work in processwire.
  7. I just wrote that before posting it here. It didn‘t exist a few hours ago
  8. I'm not really sure, why this would need to be bundled with FormBuilder. The attached module is a totally self contained module, which downloads the list from the given github url. It automatically tries to update once a day and uses the etag/if-none-match headers to determine if the list itself changed, to prevent sending of the list if there wasn't a change. The list and the etag are stored using WireCache in the db. There's public api to fetch the list and check if a domain is in the list. To use it in FormBuilder hooks should be the answer. EmailSchreck.module
  9. Just like you‘ve used gif/png/jpeg when appropriate in the past you‘ll likely use different upcoming formats in the future. It‘s unlikely we‘ll get a single general format anytime, which would trump more specialized formats across the board. Also the performance is actually less of an factor besides the bigger hurdle of widespread support. I‘ve at least seen a handful of demos, which trump webp, but those formats seem to never have made it past the initial research/implementation phase.
  10. Yeah. Communication is certainly the most important part. Depending on how you service your clients I this might even be entirely out of line. The second step would be having a proper licensing and contracts between yourself and the customers. This is the only thing, which will help you if there's someone not playing by the rules. Only after that you can look into making it harder to not play by the rules e.g. using license keys or tools with can encode php code like ioncube. Stuff like that can easily backfire though. For me code using ioncube would be a big reason to look for alternatives. Code which talks to your servers (e.g. license code validation) or even more invasive things like analytic tracking can cause problems in tightly locked down server environments, where code is not allowed to connect to arbitrary external services. So it might also depend on your potential customers what of the methods makes sense.
  11. Imho the much more compelling reasoning against using jQuery is going up the abstraction ladder and using some library, which handles e.g. DOM manipulation for you and not going down the ladder to do everything in vanilla js. jQuery for one part is a great library if you really want to manually handle changing the DOM, but I much rather deal with templates and data then with the low level "making the DOM behave". What I never really liked is how ajax was bundled with jquery, as it really has nothing to do with the DOM at all. At the time it might have been about "we make things simply work cross-browser", but it could've been packaged more separately.
  12. https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/ProcessWire.php#L182-L217 This will point you to anything happening at startup. Most of the important stuff is part of ProcessWire::load, which triggers the initialization of most common api variables.
  13. I'm not really sure why we would actually need a new permission here at all. We already have a permission to view a page and one to edit a page. It's just that ProcessWire is build with custom frontends in mind and "viewing" a page is generally considered to be done by viewing the page on the frontend. That's why we have ProcessPageEdit and not ProcessPage. I can see that repurposing ProcessPageEdit one could make it basically behave as though any field would be set to "not editable" when a user only has permission to view a page, but not edit it. I just expect that the implicit notion of "you look at a page on the frontend" is build into many places. Like everywhere you currently have a link to edit a page the permission checks need to be changed, it probably cannot be named "edit" anymore or at least must dynamically be switched between "edit" and "show". The latter might still cause some confusion.
  14. It's pricy sure, but I don't think it's more pricy than other mac hardware given what you actually get. If you really need that kind of hardware it'll cost you a few thousand bucks elsewhere as well.
  15. Can you please share why this should be part of the core in your opinion? To which problem(s) processwire users have would this be the solution?
×
×
  • Create New...