MrSnoozles

Yes, that's exactly what I had in mind too. Wordpress really drives me insane as a developer, but the fact that almost all the backend is in the clients language is one of the few things I envy when using ProcessWire. The advantage is that everyone can submit translations in a matter of seconds, when you're bored or just waiting for your train. No need to clone a repo, go through the source files and submit a PR. Core: https://translate.wordpress.org/locale/de/default/wp/ Plugins: https://translate.wordpress.org/locale/de/default/wp-plugins/

That was related to the media manager. Typo3 for example offers good media manager capabilities. https://demo.typo3.org/typo3 (just choose any username to start the demo)

You could be right on that. I'm thinking however that it would be beneficial for three (subjective) reasons: 1. It's easier to see the status of translations and contribute to them from a GUI. 2. I personally don't want to create a PR for just some of the translations. With that system you could add some suggestions here and there 3. It would be easier for non-tech people, although admittedly most of the ProcessWire users probably are Haven"t seen it, but it does seem a lot easier than the core way to add translations.

@ryan Good points. The slim core and the enormous flexibility is why so many love ProcessWire and trust you with your decisions. Still I want to comment on one point: I know it is simple, but the reality is that in client projects it often still ends up being a mix of <language> and English, because not all modules provide translations (the community seldom submits pull requests for languages) and there is no time to translate everything. I think that ProcessWire is lacking in this area has to do with you rarely needing it in another language but English. My idea how this could be improved would involve three relative simple steps: 1. Set up a community translation tool, like Weblate (https://weblate.org/), where people that want to contribute can easily see which translations are still missing. Weblate is really good feature-wise, but the interface for adding translations could be simpler, so another tool might fit better. 2. Write a crawler that goes through all the uploaded modules and core files, extract the translatable phrases and upload those packages to Weblate 3. Write a ProcessWire module that maps the languages defined in ProcessWire with country codes, then automatically downloads the matching translation files from Weblate whenever a module is added or updated In general: would that something you would consider useful? If so I could try implementing a POC when I find the time.

@David KarichVery good points. I'm very excited for this feature too. IMO the things we and our clients have been missing the most in ProcessWire, apart from versioning, are (in that order): - global asset management / media manager with directories to reuse assets in various places. The lack of this is is often the sole reason we can not recommend ProcessWire for some projects - automatic backend translations using ProcessWire in any language other than English is suboptimal, because usually the backends will end up being half in <target language>, half in English - a proper multisite solution to handle multiple domains / channels in a single instance. The Multisite module is a good start, but having more isolated channels and sharing/isolation options for each channel would make this a much better fit

I'm excited to see what you're coming up with and if this attempt will make it to a release. It's a really useful feature and I think letting Fieldtypes handle it themselves is a good decision.

Is pushing allowed? 😂 I do not necessarily seek a definite solution, but rather a discussion on how you would solve this with ProcessWire. Is that maybe a limitation of the current core?

@kongondo Is there more to see in the meantime? 🙂

Hey, so I have a website with three languages: - Swedish (default) - English - French I would now like to publish some research result in English only and not translate it into Swedish and French. I'd still like to link to it from the Swedish and French versions though. How would you do this with ProcessWire?

This looks so much cleaner and easier to use than the current version. The context menu looks very nice already. The other elements could need some more polishing - I know that's not been a priority yet, still you asked for feedback 😉 Some things I noticed on the video - a breadcrumb navigation should be visible to reflect the directory navigation (when you click on people it disappears, when you click on "men" it should show People > Men) - the selected category and parent categories should be visible (when you click the "men" category nothing is active) (it would probably look nicer to use bold text instead of green) - the spacings and alignments look a bit off. Some inspiration: https://demo.filerun.com/?username=admin&password=admin and the screenshots below

Freaking awesome!! I've been thinking about doing the same for bunny.net these last couple weeks and the approach I had outlined in my mind would have been very similar to yours. Very well done, I'm super excited for this 😃

@kongondo Just want to let you know I'm super happy development on the module continues. The functionality of the current version is great, it's just a bit unpolished compared to file managers from other CMS. As for new features: I agree with the others, folders and simplified search (+ advanced filtering) are definitely my top two wishes too. Also easier API access to render media in the frontend would be a nice to have. If I remember correctly it was a bit more complicated to use than the usual ProcessWire API. Super excited for the updates, thank you!

Fix (for me): I deleted all cookies and the sessions database table. Maybe deleting all cookies is sufficient, but as I tried both together I can't say for sure. Another solution I saw here is that it's been a permission error and site/config.php could not be read.

Nice to know. I never had anything to do with it. Just know it exists and it looks nice and powerful on the first sight.

My bet goes to the Atlaskit Editor. Should have all features that CKEditor 4 had plus a few new ones. And it's very customizable.

Neither am I. ? It was just a thought that came while watching your video. rockFrontendEditing for example wouldn't sound as catchy, but would be clearer for newcomers. I really like the new syntax. I wanted to suggest a Latte attribute first, but then decided to keep it simpler. Your approach looks nice. Imo it would b good to explain why and when this is needed instead of just using $page->edit('myfield') Perfect! So you get the best of both worlds. I'm sick at home this weekend, hopefully I will find time to give it a try already.

BOOOOOOM ???? Bernhard dropped the bomb. I'm halfway through the video and so far love everything about it. Nice video setup and editing there too. Going back to the video now ? ------------------- Edit: Okay, I'm through and this is definitely super cool. Looking forward to trying it out. There are two things though that I'm not sure about and wanted to mention: 1. The name Alfred. While you've found a sweet acronym it (in my opinion) has the huge drawback that new developers looking at the code and seeing alfred($page, ['fields' => 'gallery']) will have absolutely zero clue what's going on. Most of us love ProcessWire because it's intuitive. With this name you have to first learn that alfred is an inline editor to understand what the code is supposed to be doing. 2. I'm not sure about this one, but adding assets to the header through hooks reminds me of dark Wordpress times. I like that with ProcessWire you are able to to see where things are coming from and you have total control over what's happening.

Does that mean we will be able to attach images to comments? I've been looking for such a functionality for a while, that would be great. Could you share a code snippet on how to do it?

Article editor is nice and much more lightweight than CKEditor. @Marcjust posted an example of how an integration could look: And while CKEditor might have more features in general, for editing website content I think Article offers greater flexibility and is easier to use. ---- @ryanI once wanted to add images to FieldtypeComments, so each comment can optionally have one or multiple images attached to it. Is that something that could be supported too? If not, could you think of an easy way to integrate images into comments?

@Jonathan LahijaniI'm just planning a project that would benefit a lot from a page builder. Were you able to work more on yours?

@ryan Digging out a 9 year old topic: A common use case for me would be to sort users by `created`, so newest users are displayed first. Unfortunately the column `created` can not be selected in the module settings, as it's a system field. Neither can the default order be specified in the module configuration. Would that be something to consider for future updates?

Ah, good point. Thanks for the clarification. Looking forward to seeing what you're coming up with.

I've played with RockMigrations over the last week to get a better feeling of what it does. I didn't like the approach at first, because imo migrations should be run once to bring the system to the required state. Having them run on module refresh seems a bit too dangerous for production sites. I agree though, that for the sake of getting things done, your approach is very convenient. What you have planned for the next version could combine the best of both worlds: - a directory is added to the watchlist - migrations in that directory are executed in an alphabetical order - a hash-value for the file contents is stored somewhere when the migration is run - as long as the file contents does not change, the migration is not executed anymore That way the quick protoyping, as well a "proper" 1-file-per-update migrations could be achieved. Is this what you have in mind too?

@bernhardAny idea already what will be different in the new module? Also it feels like it's not encouraged to use the old version anymore, because the Readme has been stripped from the repository. Is that feeling correct?

Agree with @FireWire. This looks like the behaviour is wrong and an issue should be raised in the issues repository. The problem seems to lie in this line: https://github.com/processwire/processwire/blob/d78276e2c265f6b70384a13eb4febd4811a1db77/wire/core/WireHttp.php#L563 Every statuscode should be treated as a successful response, as long as the server was able to contact the remote server. EDIT: The comment on top of the line of code linked above says `no need to fallback to sockets`, but then the $result is set to false. I think this is meant to be a `$result = true;` instead of `$result = false;`. Then the rest of the logic would seem to be correct again.