• Content Count

  • Joined

  • Last visited

Community Reputation

35 Excellent

About MrSnoozles

  • Rank
    Jr. Member

Recent Profile Visitors

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

  1. MrSnoozles

    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.
  2. MrSnoozles

    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.
  3. MrSnoozles

    Congratulations on the new iMac, I'm happy to hear you love it. And as always: thanks for the update
  4. MrSnoozles

    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?
  5. MrSnoozles

    @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?
  6. MrSnoozles

    Do you think it's a too rare use case to include some simplifications in the core?
  7. MrSnoozles

    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)
  8. MrSnoozles

    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.
  9. MrSnoozles

    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
  10. MrSnoozles

    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.
  11. MrSnoozles

    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.
  12. Great post, definitely makes much more sense to organize it like this.
  13. Hello everyone, I spend my sunday hacking a playground for the new admin theme together. Unfortunately it took almost the whole sunday, Fortunately it was raining anyway. If you find bugs or annoyances, please feel free to tell me about them. What is it? It is a backend with an integrated skin editor. In this weeks blog post @ryan showed how easily skinnable the new admin theme is. Now that can be done online without having to set up ProcessWire and LESS compilation (I did that for you). Show me username: admin password: admin123 Why did you do that? I really think the new backend is one of the three key factors for ProcessWires future success (as well as the new website and the documentation; basically the things a user sees first when he's deciding for a CMS). Many many weeks ago, when Ryan introduced the new theme, he said he will need help from the designers in the community to create the best experience possible. As far as I've seen, since then there was not that much input from the community. I hope a ready-to-run theme editor can improve that a bit. How does it work? Right of the search field there's a new icon which opens the editor. Simply create a new skin and start playing with it. The skin will be available throughout all the session, even if you refresh or change to another skin. When you log out or lose your session the skin will be gone, so save your final result somewhere else too!! What other features will come? Probably none, unless there's something heavily requested. I could probably add something to store the skins permanently through LocalStorage. Or I could add more possibilities for customization than just the LESS file. But first I'd like to see if this is used and there's even the need for those features. Can I show my created skin to others? Of course. Right now just "default" and "pw-theme-reno" are public. I would love to show more skins there. Just post the content of your skin in this thread and I will add them to the public skins. I hope you find it useful and it helps making the most efficient and polished CMS backend out there.
  14. Thank you for yet another interesting friday night (for me) blog post. This definitely looks hot Is this going to be the default skin in the future or is that still open to discuss? From the UI side I have a couple points. I know this is not supposed to be a final version, but the input probably won't hurt either. 1. the tabs on top (content, settings, etc.) in the screenshot "page editor with language tabs active" might be a bit confusing for some. Since the borders all have the same weight it seems that they might just change the title field. 2. The top navigation bar still looks quite big/high, unnecessarily wasting space. Would still have to see that in action though. 3. In the search suggestion field the section labels might fit better on the left. It probably depends on the available screen width, but labels on the left can make the field look sleeker.
  15. MrSnoozles

    @Peter Knight I absolutely love the modifications you did. Looks super clean and unique. Thank you for that demo