MrSnoozles
Members-
Posts
81 -
Joined
-
Last visited
Recent Profile Visitors
3,036 profile views
MrSnoozles's Achievements
Full Member (4/6)
139
Reputation
-
Questions and syntax LATTE (Template Engine by Nette)
MrSnoozles replied to sebibu's topic in Dev Talk
Updated the post to be clear it's an example and varies depending on which modules are used. -
Questions and syntax LATTE (Template Engine by Nette)
MrSnoozles replied to sebibu's topic in Dev Talk
It looks like you need to make $map available in your Latte file first. Then, as Bernhad has said, you could write in your Latte file {$map->render($page, 'YOUR MARKER FIELD')} With https://processwire.com/modules/template-engine-latte/ you would write something like the following in your PHP template file (or ready.php): $view->set('map', $map); It might vary depending on which modules you use exactly in your project. -
New blog post: Introducing the Custom Fields Module
MrSnoozles replied to ryan's topic in News & Announcements
Okay cool. I thought with JSON functionality they were starting to diverge. -
New blog post: Introducing the Custom Fields Module
MrSnoozles replied to ryan's topic in News & Announcements
@ryan The module sounds very cool. Does it support MariaDB too or only MySQL? A storage_name option could be useful to be able to rename the field in the api, but keep the values in the database. -
Clickbait title aside, I recently found a cool new feature in PHP 8.1 and wanted to share it with you, in case you didn't know this either. Starting with PHP 8.1 you can write $this->method(...) (yes, that's the actual syntax, not a placeholder) to reference a method. I find this super convenient, especially for defining hooks. Plus the IDE can refactor this much better than the traditional [$this, 'method'] callback. <?php class MyModule { public function init() { $this->addHookAfter('ProcessPageView::finished', $this->doSomething(...)); } private function doSomething(HookEvent $event) { // TODO: something } }
-
This is super useful, as is Mystique. Will it support searching and more complex fields, like repeaters? Agree, this is very useful.
-
Again, regarding a more modern administration: I like how the Silverstripe backend works, both how the page tree is presented, as well how the page edit screen looks. I also like that expanding the tree works in a (imo) more standard way (meaning a click will edit the page, to expand it there's an arrow). I think we could get some inspiration from there. You can try the demo here, no need to sign up: https://demo.silverstripe.org/admin/
-
Agree with that. I really like the Craft 5 backend, from your screenshot at least. Would be nice to have a page tree in the sidebar though for quick navigation when it's used as a cms. When used as a custom app, what we usually want to do, is to hide everything that says "page" and provide custom views to the user. E.g. we want sections that show "events" or "skyscrapers" in a list/table, the way users know it from other apps. I think what was meant is to drop utf8 and myisam or at least do not offer those options in the installer. If somone knows what they are doing and they offer advantages it's possible to change it in the database. My guess would be that the majority of people do not know what's the difference and want utf8mb4+innodb. I didn't know back then and was wondering why emojis were not shown on my site. Took a while to find out that I need utf8mb4 instead of utf8. Any particular reason why you wouldn't like it?
-
I'm so happy it comes as a very good module instead of being integrated by default. We're using PW to build internal tools as well, where SEO settings do not make sense. Love this list, couldn't have formulated it better ♥ As for composer installation: This does not mean that an installation of ProcessWire has to get more technical. It could still be downloaded as a zip file and extracted. The only differences would be that instead of site&wire directories, you would have site&vendor directories. Also it would be possible to install a new ProcessWire instance directly from composer, as opposed to going to the website, finding the download page and downloading & extracting the zip archive. And it would appear a bit more professional, imo. I just see advantages here.
-
Excited to see thoughts about starting work on ProcessWire 4. PHP 8+ bring so many improvements, would be nice to utilize them. My personal pain points and wishlist for ProcessWire: - a global media manager - more official integration of multi site / multi domain capabilities (in my case especially for the one database, multiple roots option) - admin theme improvements: - a permanently visible page tree to quickly jump between pages - more ways to customize it, depending on the applications needs. Like having a predefined place to add a "website select" for multi domain websites. - quick mockup, based on www.clickup.com. Clickup also has a "task bar" where you can put pages that you want to come back to. That's quite handy as well. - from a tech point, some things that could be nice to have, but most likely not feasible and against the philosophy of ProcessWire because it would most likely make the project more bloated: - better utilization of composer, e.g. having the ProcessWire core and admin package as separate composer packages, so a ProcessWire installation would just have a "site" and a "vendor" directory - PSR standards / framework ineropability where it makes sense - some automated tests, at least for the core api @Jonathan Lahijani+1. We're using it for application development and it works very well if there is not too much data involved (with 10,000,000+ pages you'll start to having to search for workarounds to keep things fast, in my experience). Would be nice to hear what would be your ideas for improvement. A more web-application like and customizable backend would be nice for us as well. In some projects we were able to hack and hide everything that was not needed. In other projects we build a custom admin panel. Then a way to render a form for a full template in the frontend would have come in handy several times already.
- 127 replies
-
- 12
-
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