Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

38 Excellent

About MrSnoozles

  • Rank
    Jr. Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Mainly this. I didn't know it's not visible for non-superusers. That makes it better. Still, I think this could become something you add as a module when you are in need of it, nothing that almost all users at all times need.
  2. Hey, this is not a feature request, the feature is already there. But for me personally, it's more often cluttering the UI than being useful. I would like to know if I'm the only one that thinks so. I'm WOW'ed by ProcessWire because it really often offers just the right amount of functionality and keeps things clean and simple. The bookmarks feature is something I thought from the beginning should be an optional module rather than something that's tightly built into the core. Or is there a specific reason this has to be part of the ProcessWire core? Looking forward to hearing your opinions.
  3. Fully agree with @LostKobrakai. I guess a well documented ->sanitize() method would do, I'd say those magic methods are more confusing than helpful. Also I originally came here to comment that a "slug" sanitizer method that also handles Umlauts would be an awesome addition too. "I drink Jägerbombs" -> "i-drink-jagerbombs"
  4. Also I just noticed that "speed" could be mentioned a bit more on the start page. I would say back in the day the phrase "ProcessWire open source CMS is fast. ProcessWire with ProCache is insanely fast!" piqued my interest and made me try the system.
  5. Great website update. Even if it's not 100% finished, it's miles better than the current website. Plus you got a lot of helpful criticism from many talented people already, which will definitely help improve it further. I feel like 2019 is going to be a really interesting year for ProcessWire. Keep up the amazing work. Edit: It's been said in different topics already, but not really highlighted that much here. Like Bernhard, I think "headless" is a powerful marketing buzzword these days that could be used on the homepage.
  6. Congratulations on the new iMac, I'm happy to hear you love it. And as always: thanks for the update
  7. I really like translations in ProcessWire but agree, a way to provide centralised community translations for the system and modules would be great. If I remember the software correctly, it should not be too complicated to set something up using Weblate. Would this be something there's interest in?
  8. @Ralf Which PHP version are you using? "self::new" is a syntax that threw an error prior to PHP 7. Since PW minimum requirements is PHP 5.3 it is a bug introduced in version 3.0.117. Like @adrian said, reverting to 3.0.116 or upgrading to PHP >=7.0 should fix it. Anyway, I would also like to use this comment to continue a discussion that started in the comments sections of the blog post about the newly introduced WireArray::new() static method. I posted a pretty long comment about that which never got published. (As a side node, that is highly frustrating, taking into account I took quite some time researching background information to the comment I made. So here is going to be a shorter version of that post) The discussion started with @teppo and @bernhard asking, why a new concept of WireArray::new() was introduced to initialise a new WireArray with data. More intuitive would be if you could just initialise it using new WireArray() and pass your data to the constructor. That's how it works for most other objects in ProcessWire too. To that @ryan replied: Now, I do understand why this is necessary, but just like Teppo and Bernhard I'm not 100% happy with it. It seems like a small thing we shouldn't care too much about, but I came to love ProcessWire because I usually do things I learned them using plain PHP and most of the time they just work the way I expect it. This new WireArray::new syntax is something I would intuitevly do wrong, then wonder why it doesn't work, then search the documentation, and finally ask myself, why I can't just use new WireArray(). And that's a workflow that's slowing me as a developer down, a workflow I'm accustomed to from Wordpress, not from ProcessWire. So although it doesn't seem like a big thing, is there a chance we could make new WireArray() work for initialising WireArray objects with data? As far as I could see there are four classes derived from WireArray and implementing their own constructor. Would it be possible to refactor those?
  9. Do you think it's a too rare use case to include some simplifications in the core?
  10. Jupp, but I generally think PDO does not have a nice Api, and is cumbersome to work with. That's why I was suggesting to unify it and make it easier to work with. It definitely should stay conform with pdo. But I think concatenating strings to create a query is just not a great developer experience. If you could pass arrays and the library would do the query concatenation would be amazing. (i'm on the phone now so I can't post code, but I will try to add an example of how this feature could improve code cleanliness compared to pdo)
  11. Definitely, as long as you are working with the pages api. There are cases though where you have to query external tables. And in that case it could be a bit more developer friendly than standard PDO. @Zekathanks, will look into that. What I was suggesting is simply an abstraction to always use the same api, no matter if you are inserting, querying, using prepared statements etc.
  12. Better database abstraction is something I would like to see in ProcessWire in the future. Everytime I have to work with raw database queries, I always have to look up the documentation for PDO. exec, query, prepare, ... I never know how they are called and when to use which, since database abstraction libraries in frameworks make the developers life so much easier. This is something I could very well imagine in ProcessWire as well. Since most of the time you're working with the pages API anyway, I don't think it has to a full blown ORM. But having just the query method and there you can insert parameters would be a great help. I'm thinking of something like a light version of https://github.com/dg/dibi.
  13. From what you're describing I would go with creating those 3 fields. It's not really overkill (in which terms do you think it would be overkill?) and makes your life so much simpler. What you're thinking of doing sounds really hacky, and usually with hacky solutions you will have trouble in the end.
  14. Hey enschleunigung, one way to make this work would be the following: Instead of sending the Ajax request to your _func.php send it to any normal page. This way all the ProcessWire features will be initialized. Then in your _func.php you can do function doSomething($u, $p) { // ... } if($config->ajax && $input->post->userID && $input->post->pageID) { echo doSomething($input->post->userID, $input->post->pageID); die(); // just output the content, do not process the templates } There are better ways to structure the code, but it will get you started.
  15. Great post, definitely makes much more sense to organize it like this.
  • Create New...