7Studio

😆😂

Another big update of my polish translation - Version 1.0.8 ( June 22, 2022 ) - fully compatibile with the latest ProcessWire master version - 3.0.200 In this update: deleted abondend translations deleted files where translations were moved to a different paths added all missing files and translations for new master 3.0.200 fixed typos, small changes in current translations If you need translations for older versions please check older releases at github https://github.com/sevenstudio/polish-wire/releases I'm having problems with login to the modules directory, so please use github, and I will try to update files in the modules directory asap. Thanks!

Good point.

@AndZyk Thanks! 😉 but as I've mentioned above I would like to avoid those if/else and updating code everytime when I add/change something 😉 After some more testing it looks that the problem lies in my code. I'm using wrong method, childTemplates gives me ID of child template, while I should use childTemplates() - that returns array of templates objects, and it works with LazyLoading enabled. Working example: if ($item->hasChildren()) { $template = $item->template->childTemplates(); foreach($template as $child) { if (!empty($child->noChildren)) { $no_children = true; } } } @bernhard basically I couldn't access template object and it values, but this looks more like an edge case, and I couldn't find more generic example. You would need to have a similar setup (let say blog as parent template + child blog-post template that doesn't allow childrens) + code needs to lands in the _init.php and you have to be logged in. $parent = wire('pages')->get('template=blog'); $child = $parent->template->childTemplates; $template = wire('templates')->get($child); var_dump($template); With lazyLoading enabled this returns NULL instead of a template object (it ruturns object if you are on a child page). As I've mentioned it looks that I was using wrong method, but I think that question still remains if lazyLoading should be enabled by defalut, especially if it can bring some code breaking changes - also like @szabesz mentioned above.

Hi @AndZyk, Thanks for your reply! Maybe I wasn't clear enough, to explain this further - I would like to avoid including childrens as menu items even if they exist in some scenarios, for example hierarchy of my blog looks like this: blog page (blog template) article (blog-post template) article (blog-post template) ... In my case blog-post is a template that can't have children, but Your example will display every single blog article title as a child in menu, which of course I want to avoid. By checking a blog-post template settings (noChildren allowed value), I can skip articles from beeing rendered in a menu and for example adding "parent" CSS class to blog page menu item. I can do the same for other pages that follow same site structure, like portfolio -> portfolio item etc. while using template settings only. For menus I prefer to have a single function that is used to render all kind of menus, that simple helps me to limit code and usage of if/else checks for a specific templates while building menu. Anyway, since 3.0.194 I can't access these values any longer, (as long as I'm not on a blog post page). Lazy loading in this case limits my access to needed values, so I'm wondering what else can't be accessed and if that is not much to have it enabled by default, when PW in most cases is blazing fast (Just loud thinking) 😉

Great site @heldercervantes ! One small thing, looks like there is a small logo displaying issue, on homepage path to logo image is: /site/templates/static/brand/logo.svg on subpages: /site/templates//static/brand/logo.svg Otherwise amazing work, Congrats! 👏

Hello @ryan, first of all huge thanks for a great addition to the core, but I'm a bit concerned if lazyLoading should be enabled in the core by default as it is since 3.0.194. To give an example where I'm having problems - I have a small function that renders site main menu, where I do check if page templates allows to have a children pages (template noChildren value), if not - they are not rendered in main menu (this is my basic setup for pages like blog posts, portfolio items etc. - these are treated as final pages with no children allowed). The part of the code that renders site menu looks like: if ($item->hasChildren()) { $id = $item->template->childTemplates; $fields = wire('templates')->get($id); foreach($fields as $field) { if (!empty($field->noChildren)) { $no_children = true; } } } Unfortunately since this update, I can't access page templates settings fields values as long as I'm not on that exact page, so in this example all my blog posts are rendered in menu while I'm not on a blog post page. Disabling LazyLoading: $config->useLazyLoading = false; in my config fixes this and brings previous behaviour. Not sure if this is a bug or it was intended, or something is wrong with my code 😉 but for me one of the most powerfull option of PW is a fact, that I can access anything -page/field/template from anywhere. If that was intended I guess that that other people could have similar problems. While this is a great improvement in overall loading speed, I think that this option should be disabled by default (if it may cause that kind of side effects), and to be left to the final user to decide, if it is needed and should be enabled - same as we don't use cache by default. I would love to hear yours and others opinion in this matter. Thanks!

@bernhard I didn't noticed your edit, most likely the modal does not exist in dom yet or this event wasn't defined when your script fires up - scripts order in the back, thus you may need dom ready. Small off topic, I just started to build my first process module so I would like to thank you a lot for your tutorial about adding pages in the backend 😉 it helps me a lot! Back on topic, I'm using modals in the module as well, and I've noticed that this event is always fired three times, so you may think about using debounce to limit it. Anyway once again huge thanks for your tutorial about process modules! 🙂

@bernhard in your example you are listening to the modal close event - "pw-modal-closed", also you have linked a modal.js, if you are using panels then "pw-panel-closed" should do the trick I guess 😉

I've created a new "pull request" that adds configurable option to define custom "from" email address directly in the module settings. https://github.com/ryancramerdesign/LoginRegister/pull/28 I hope that Ryan will review this "pull request" and include this small change in future versions.

@Pip You don't have to hack the core module file, as suggested by abdus above, you can define admin email address in your config.php file, so it won't be overwritten by any updates:

Right, this could help if your default language will be in one of spanish languages. Sorry, I was a bit to fast with my reply. I guess that in this case you will have to provide a complete translations for both spanish languages even if most of strings would be same/similar. Maybe someone else will suggest solution here 😉

Hi Fuzzy, maybe this could help: https://processwire.com/blog/posts/pw-3.0.151/#language-translation-function-improvements

Hi Chris, sure I don't mind. Please just share your thoughts and findings, so we can improve this language pack where needed. Have a great week! Pozdrowienia! 🙂

Hello, I've updated my polish language pacakge for ProcessWire 3.x to be fully compatibile with the latest master version - 3.0.148 In this update: - added all missing translations for a new features, - removed translation strings marked as abandoned - few small corrections for typos download at: http://modules.processwire.com/modules/polski/ or: https://github.com/sevenstudio/polish-wire/archive/1.0.7.zip