MrSnoozles

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

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)

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.

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.

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.

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.

Great post, definitely makes much more sense to organize it like this.

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 http://pwadmin.youbility.de/processwire/ 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.

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.

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

Same here. I posted that in the blog comments already. I would like to see two things: 1. Be able to use this as a seperate tab (e.g. it's convenient to have all SEO related fields in a separate tab instead of mixed with the content) 2. Deprecation of fieldset (open). As far as I can see it the new fieldset types offer pretty much the same functionality but are much easier and faster to use

Hello, this feature wish came up while I was working on my first bigger project with ProcessWire. While almost all of the CMS is very well thought out there was one thing that always kept me thinking "where should I put this?": simple page actions. What I mean is code snippets that belong to a page and should be run when a certain action is taken. E.g. when a user submits the form on my contact page (that has the contact template) I somewhere have to validate the form and then send it somewhere. So far I see two options to do that. Write a module that hooks into some methods and checks if the post data is set and if the page is my contact page This aproach is clean but it's usually a lot of overhead to write a module just for that Write the code in my contact.php template This aproach is fast but feels really dirty. It does not help to separate the logic from the design which I fear in a long term could lead to some Wordpressish code structure Now since I don't have so much experience with ProcessWire there might be a chance I missed something, but then it's probably not documented obvious enough. So I thought how you improve on this problem and came to a solution, that's again really close to the syntax that jQuery provides. If we had some kind of routing system we could register those actions in any file, for example the templates _func.php <?php // execute this action when a post request is sent to /contact // the parameters given to the callback function probably should be different wire('request')->on('post', '/contact', function($request, $input) { // do an action } // do the action for any post request wire('request')->on('post', function($request, $input) { // do an action } // do the action for get requests on contact pages wire('request')->on('get', 'template=contact', function($request, $input) { // do an action } // do the action on ajax-GET requests wire('request')->on('get.ajax', '/contact', function($request, $input) { // do an action } Is that something that could improve the work with ProcessWire? What's your honest opinion about it? If that's a useful suggestion I would like to help with the implementation. Regards Alex