MrSnoozles

I was struggling with that recently too. It doesn't seem to be too well documented. If I remember correctly you could do the following <?php .... $form->add($f); if($this->input->requestMethod('POST')) { // validate and upload the file to /site/assets/files $form->processInput($this->input->post); // access file $uploadedFile = $form->get('prop_pix_1')->value; }

Please no. ? I've been working with JsViews on a project and as the project became considerably large it became a nightmare to maintain. It's not necessarily JsViews fault though, it does a splendid job at what it does. But attaching event listeners to things based on their ID somewhere in the DOM and then reacting to it isn't really maintainable in a larger scale. In my opinion VueJS (https://vuejs.org) would be a great addition to the ProcessWire backend as they also somewhat follow the same philosophy and are a joy to work with.

Hey Eduardo. Thank you a lot for the honest status update. It's nice to read something about the module again and get some insights why there wasn't an update in a while. I (and probably many others in this community) would love to get my hands on the module. The teaser videos looked just too awesome. For me it definitely looks polished and powerful enough to be a sold as a Pro module.? But if you lack the time and resources to support it at the moment, I'm sure the community would be infinitely grateful if you just released it as is.

@elabx@joshuag Are you still planning on releasing the module? It would be a pity and a huge loss if such an awesome module would never see the light of the day. If you currently lack the time to continue on the module maybe you could publish it along with a list of things that still need to be done? I would gladly work on completing it.

Hey everyone, this week I found the time to write some modules and came up with something that I think could be greatly improved in ProcessWire. In my opinion when developing PHP applications today there should barely be the need to manually require files that contain classes anymore. Instead this should be handled by an autoloading function and probably by more strictly following a fixed PSR naming guideline. In ProcessWire as developers we unfortunately still have to manually require files which, besides from feeling somewhat dirty, has two major drawbacks: 1) files get loaded even when not needed to process the current request 2) file includes are all over the place and also have to be considered when refactoring

Super cool, congratulations on the upgraded infrastructure. I definitely would like to read more details about how you two setup ProcessWire in that environment. That would make for a good, enterprise-y tutorial here on the page too.

Hey Mike, is there anything the community could do to support you with v2? The new version is highly anticipated ?

If I want to show tens of thousands of rows, but just 100 per page, the only options I have at the moment are: Load all rows and let agGrid handle the pagination (fast navigation, slow initial load) Just show 100 results (fast initial load, but data is incomplete) implement my own server side ajax implementation for pagination (fast, but higher development effort) Is that right? Or does RockFinder already provide a solution for pagination without having to load all the data? If it doesn't: Is that something that falls in the scope of RockFinder and you @bernhard would like it to be implemented?

This is awesome Ryan, keep it up! I can imagine going through the issue reports is not as exciting as developing new features but it's definitely more important in terms of maintainability and long-term user happiness. Happy that these issues are being tackled. I wish you and everyone in the community a great weekend too.

Late to the party, but this looks really good at first sight. I recommended Ag-Grid to @bernhard back in the day, because imho it is much more powerful and at the same time easier to customize than the jQuery Datatables plugin he was using at the time (https://datatables.net/). Now (again at first sight, I didn't deep-dive into Tabulator) this looks on a par with Ag Grid, feature-wise and easy-of-use-wise. A big plus I see is that it's completely MIT-licensed and there aren't any features hidden behind an enterprise licensing model. Have you come across any downsides when working with Tabular or any essential features that it lacks?

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.