Leaderboard

And another thing to mention / take care of. Just because ProcessWire seems to be running fine that doesn't mean that you are all done. For example what if one of the installed modules had a custom .htaccess in it's module folder that has some custom rules that are necessary to protect some files from direct access? As far as I understand nginx will not be able to read these instructions and you might be open to attacks, no? I think it should at least be clearly mentioned in this thread that anybody trying to use non-apache webservers for running ProcessWire has to take care of this risk on his own and check every single module and every single update or is otherwise really highjacking one of ProcessWires main strengths: Security. For me this seems like a very high risk to take and I'd really be interested in numbers of how much faster nginx is compared to apache so that one can decide whether it's really worth the risk and additional effort.

I had similar issed with localPath. After some testing I found out that localPath seems to be not a "real" method of Page, but is registered via a hook. Is it possible that the issue "Page::localPath does not exist or is not callable in this context" is a side effect of that? # /wire/modules/LanguageSupport/LanguageSupportPageNames.module public function ready() { $this->addHook('Page::localPath', $this, 'hookPageLocalPath'); } /** * Add a Page::localPath function with optional $language as argument * * event param Language|string|int Optional language * event return string Localized language path * * @param HookEvent $event * */ public function hookPageLocalPath(HookEvent $event) { /** @var Page $page */ $page = $event->object; $language = $this->getLanguage($event->arguments(0)); $event->return = $this->getPagePath($page, $language); } In my case I could simply replace localPath with path, because localPath returns the page path of the default language and not the page path of the current language. This seems to be an inaccuracy in the docs. See this post:

You said that loud and clear, yet my point here is this: Installing a site profile is a very basic task. Well, it's actually just installing ProcessWire with one additional step. But you made it look very complicated. I'm fine with it, even though I had to watch it a few times to know what happening, because I know the "real" steps. A RockShell or DDEV video with that first 2.5 minutes as a demo - perfect! Another thing I noticed but didn't mention the last time was the sound. In some parts your voice shifts as if you have sped the video up. Not sure if this was intended or not.

Hey @wbmnfktr thank you very much for your honest feedback! I had to think about what you said, because I had good reasons (at least I thought they where good) for using my advanced techniques. I didn't think that showing a very basic, old-school installation via unzipping the module files would be interesting at all, so I wanted to pack more into the video. Not that old-school installations are bad in any way, I just didn't think that this is interesting or helpful for anybody. Also I thought I made it clear that this is nothing anyone has to use, but I think that got lost during editing. So I think you have a very good point and I'll try to not mix different topics in one single video. These alias commands would have been more helpful in a dedicated RockShell video, I guess, where I also show how these can be setup. Thank you!

@wbmnfktr I have also noticed the same over the years, but I thought nevermind, I have this module.

Hey @FireWire sorry to hear that you are having troubles. It seems that you are doing some quite complex stuff. I've never experienced any of these problems - maybe because I keep things very simple! What is "better" is a very subjective thing, but there are two things I want to mention upfront: Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there: // if you passed the wire variable you can do this: {$wire->pages->find(...)} {$wire->modules->get(...)} {$wire->...} // if you passed "page: $page" do this {$page->wire->pages->find(...)} // or this {var $wire = $page->wire} {$wire->pages->find(...)} I guess I don't have these problems because I'm always working with custom page classes, so I most of the time add those things to the pageclass and then I can just use $page->myMethod(). That has the benefit that template files stay very simple and I have all the logic in PHP and not in Latte, which has a ton of benefits. For example you can do this for debugging: // in site/ready.php bd(wire()->pages->get(123)->myMethod()); Or you could access ->myMethod from anywhere else, like in a cronjob etc. If you have your business logic in latte then you have to refactor at some point or you are violating the DRY concept if you are lazy and just copy that part of your logic from the latte file to the cronjob. I'm not sure I can follow... I put this in whatever.latte: {block foo} <h1>Hello World</h1> {/block} {define bar} <h1>Hello World</h1> {/define} {include foo} {include bar} And I get 3 times "Hello World" as expected. {block} does immediately render while {define} waits for the final include Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file. I'm usually always either in /site/templates/sections or in /site/templates/partials. That's it. Sections are full width elements, like hero, slider, breadcrumbs, main, footer, etc. and partials are things like buttons, cards, etc. Having said that I see that there might be potential to improve the experience though. For example we might make the functions api available to all latte layout files or we might make API variables always available. But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup. Also I'm hesitant as I didn't experience any of these "problems" for maybe two years or so. So we have to identify the real problem first. Maybe the problem is only lack of documentation for example.

@mel47, my fault, there are two bundled modules and I forgot to update the version number of one of them. Plus there was a problem where GitHub didn't pick up the casing change of a subdirectory. If you upgrade to the newly released v0.3.2 it should be fixed.

Hi @Robin S I have a problem with your module. It detected links but the table is completely empty. Checking console, I got those errors : JQMIGRATE: Migrate is installed, version 1.4.1 jquery-migrate-quiet-1.4.1.min.js:2:552 La mise en page a été forcée avant le chargement complet de la page. Si les feuilles de style ne sont pas encore chargées, cela peut provoquer un flash de contenu non stylisé. JqueryCore.js:1:91295 Échec du chargement pour l’élément <script> dont la source est « https://XXX/site/modules/VerifyLinks/datatables/datatables.min.js?v=0.2.2 ». verify-links:93:102 Uncaught TypeError: $(...).DataTable is not a function <anonymous> https://XXX/site/modules/VerifyLinks/ProcessVerifyLinks.js?v=0.2.2-1727405204:7 jQuery 4 ProcessVerifyLinks.js:7:21 <anonyme> https://XXX/site/modules/VerifyLinks/ProcessVerifyLinks.js?v=0.2.2-1727405204:7 jQuery 4 Do I miss something to install? PW 3.0.241, VerifyLinks 0.2.2. Didn't work both on my computer (localhost) and online server. Mel

Using those aliases for DDEV, Git, RockShell makes the first 2.5 minutes kind of... blurry or a blackbox or something. Even though I know how to install ProcessWire with a custom site profile I had to watch it a few times to understand whats happening. While I use DDEV, I use way different aliases, i don't use RockShell, and so on. It felt a bit like installing Laravel or CraftCMS to me - so many different moving bits and I don't know or can't really follow as I don't have or use the tools and can't see what really happens. As mentioned elsewhere: I love the fact ProcessWire has still ZIP files and don't relies on composer to install something. It would have been nice to see a slide with the full DDEV command, a screen with the Github page and URL to see where I can get the profile as ZIP. After that I would have preferred to see a full clean install with unzipping a site profile, dragging it into the docroot, and go from there. If I were new to ProcessWire this would have freaked me out in terms of: that's a lot of hoops I have to jump through.

Does anybody of you guys have some numbers in how much faster PW gets when using nginx instead of apache?

Hi. Description in the docs for these methods says 'Return the page path in the current user's language, or specify $language argument (Language object, name, or ID).'. But from what I see in the code it returns the page path in default user's language or in specified language.... /** * Add a Page::localPath function with optional $language as argument * * event param Language|string|int Optional language * event return string Localized language path * * @param HookEvent $event * */ public function hookPageLocalPath(HookEvent $event) { /** @var Page $page */ $page = $event->object; $language = $this->getLanguage($event->arguments(0)); $event->return = $this->getPagePath($page, $language); } /** * Add a Page::localUrl function with optional $language as argument * * event param Language|string|int Optional language * event return string Localized language URL * * @param HookEvent $event * */ public function hookPageLocalUrl(HookEvent $event) { /** @var Page $page */ $page = $event->object; $language = $this->getLanguage($event->arguments(0)); $event->return = $this->wire('config')->urls->root . ltrim($this->getPagePath($page, $language), '/'); } /** * Given an object, integer or string, return the Language object instance * * @param int|string|Language * @return Language * */ protected function getLanguage($language) { if(is_object($language)) { if($language instanceof Language) return $language; $language = ''; } if($language && (is_string($language) || is_int($language))) { if(ctype_digit("$language")) $language = (int) $language; else $language = $this->wire('sanitizer')->pageNameUTF8($language); $language = $this->wire("languages")->get($language); } if(!$language || !$language->id || !$language instanceof Language) { $language = $this->wire('languages')->get('default'); } return $language; } Am I right? Should I reise an issue to aks Ryan to correct it?