MrSnoozles

I was searching a lot too and settled on https://bitwarden.com/ Maybe it fits your needs as well.

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.

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.

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"

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.

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

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

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?

@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?

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