Leaderboard

I've just bumped the dev branch version to 3.0.220. Relative to 3.0.219, this version is largely focused on issue resolutions, and there are 11 of them, among 14 commits. See the dev branch commit log for details. This is just a brief update so I don't have more to add other than that I hope you are having a great week, and have a great weekend!

So I've just updated my personal website after some 7 or 8 years. It's a small one pager, but with some quirks that I hope you'll enjoy. Have a look: https://heldercervantes.com/ First, the approach was to somehow reinterpret my CV into a web experience. My last CV, along with my Supertiny agency's website share this space exploration / alien contact theme, so the idea here was to incorporate a journey through space as the user scrolls through the website. In the end you'll find a mini-game, where you can attempt to reach the far depths of space and discover what's out there. Most content is static, but I'm using PW to manage the logos you'll fly by at some point and the projects, the game's highscores and SEO. I intend to improve it a bit in time. Sound is probably the next thing I'll add, and I have some ideas to make the game more interesting. Fun fact: Setting up PW for this one took about 2h.

Thanks @da²! Cookie expiration time issue has now been fixed and version 2.3.0 released.

ProcessWire 3.0.219 on the dev branch focuses primarily on a major overhaul to the core $modules system. The Modules class had grown into more than 5000 lines of code — all related to modules, but with lots of different areas of focus within that. It had become a little bit messy, fragile and hard to maintain at that size. I've had @todo notes in the class to "clean it up" for quite awhile, but this week I finally got to it. The approach is similar to that of our $pages API (Pages class), which is split into separate classes for page finding, loading, editing, caching, etc. The Modules class has been split into several much more focused classes for module information, installers, loaders, files, flags, duplicates, and configurations. This leaves the main Modules class as the gatekeeper, making it less fragile and easier to maintain. If this overhaul was perfect, you shouldn't notice any difference, and the public $modules API remains as before. But with such significant overhaul that took a full week to complete, there's also an increased potential for temporary errors, so please let me know if you encounter any. Thanks for reading and have a great weekend!

Yes! That was it. I somehow had a copy of the module in both wire/modules/ and also site/modules/. I also had a permissions issue (I couldn't delete the extra one until I changed its permissions), but I think that the issue was just that it was in there twice. Maybe the core should check for that when refreshing for new modules? It's kind of a dumb thing to do, and I shouldn't expect PW to keep me from doing dumb things. Can I say how awesome it is that two people investigated this issue for me just since I posted last night? I'm accustomed to forums where replies can take quite a while and may not be all that helpful. I appreciate the energy and solidarity! I'll look for some posts that I may be able to help with as soon as I get done with my day job today.

Posts and news are no different content types, just different names for the same thing. In this case. Close but not exactly: There is only one main blog which holds all posts (lives under /about/blog/). It is possible to assign multiple tags/keywords to each post (so the website visitor can narrow down the results). At project launch the client wanted to have another section (e.g. /campus/) on the website with content that has similar design requirements as the blog area mentioned above. But while some posts are relevant only for the campus section, some appear in both sections (blog + campus). The request then was to avoid establishing two independent blogs. Just to spare the need to maintain similar content in two different blogs. So i trained the client to assign dedicated tags/keywords for posts, which are relevant for the display in the campus section. On the campus page i collect all posts with those dedicated tags/keywords. Yes, right, i am aware of this. I find it a bit awkward to click on a post abstract while being on the /campus page and landing on the /about/blog/<name-of-post>. Confusing and a kind of one-way path for visitors. And that exactly is the reason for my post/question.

At first it did sound like a namespace issue but the module has a namespace so I threw it in a demo instance: No issues so far. Installed without errors, output is minified. ProcessWire 3.0.210, PHP: 7.4, 8.0, 8.1 @ZAP Can you please check that there is no other copy of that module in place. Maybe with a different folder name or something.

Important information on updating to 1.5.2 I have changed the storage folder for custom uploaded fonts, so it will be outside of the module folder. The reason is, that your custom fonts will be deleted during an update if they are stored inside the module folder. This should not be happen and was not the plan. The new version fixes this problem and your uploaded fonts will now be stored inside a newly created folder (site/assets/files/JkImagePlaceholder). This folder will be created automatically during the update to 1.5.2 or on a fresh install. Please note: During this update all previously uploaded custom files will be deleted. So before you update to the next version, save your custom font files somewhere on your system and upload them once more after you have finished the update. This is only necessary during the update to 1.5.2. All other upcoming updates will not be affected. To prevent problems, the best way would be to delete the module completely and make a new re-install. Sorry for this inconvenience!

@Juergen I'm updating this in wire/core/Modules.php: public function ___saveModuleConfigData($className, array $configData) { return $this->configs->saveConfig($className, $configData); } to this: public function ___saveModuleConfigData($className, array $configData) { return $this->saveConfig($className, $configData); } I think that'll fix it, though let me know if you find it still doesn't work. Thanks.

Does hook fire on Modules::saveModuleConfigData?

Just to follow up - found out this is fairly simple to do with a php script. There are 2 important methods in wire/core/PagesExportImport.php I haven't dug into options or error handling, but this approach achieved what I needed it to. Ran this on website 1 to export the content: <?php namespace ProcessWire; include "index.php"; // bootstrap ProcessWire $pages_to_export = $pages->find('template=my-template'); $exporter = new PagesExportImport(); $data = $exporter->exportJSON($pages_to_export, []); file_put_contents('resources-image.json', $data); and this on website 2 to import: <?php namespace ProcessWire; include "index.php"; // bootstrap ProcessWire $importer = new PagesExportImport(); $json = file_get_contents('resources-image.json'); $data = $importer->importJSON($json, []);

Also, if you are interested in great international mixes and DJs, this channel has some great guests with intriguing taste:

I have to say that in general, having PlexPass and using their sonic analysis has been the biggest boon to my background programming music setup - the sonic adventure and automated DJ features are phenomenal. When all that matters is consistency of tone and mood, the sonic analysis that the Plex server does on my collection makes it so I don't even have to think about what I want to listen to next - the mood just flows regardless of who it picks. The cool thing is it often pulls a bunch of b-sides or obscure artists songs that I never would think of linking together in a playlist, but the songs mesh like magic.

Hi @wbmnfktr PagePathHistory only works when a pagesURL changes to something new. In this instance, I was looking to redirect to a completely new page. I never noticed the options under the What other URLs redirect... section but they might be useful. Thanks

@olafgleba As I understand it, you've got pages that live at /members/blog/<name> and you want them to be accessible at /blog/<name>. First thing is to make it so that the blog post pages ->url property reflects the URL you want them to use. You can do this with a hook in /site/init.php: $wire->addHookAfter('Page::path', function($event) { $path = $event->return; if(strpos($path, '/members/blog/') !== 0) return; $event->return = str_replace('/members/', '/', $path); }); Next, you want to make it so that ProcessWire will deliver those blog post pages at the /blog/<name> URL. You can do this either by enabling and handling URL segments on a /blog/ page, or you can use a URL/path hook, again in /site/init.php. I'm going to assume there is no /blog/ page, so a URL/path hook may be the best bet: $wire->addHook('/blog/{name}', function($event) { $name = $event->arguments('name'); $blog = wire()->pages->get("/members/blog/$name"); return $blog->id && $blog->viewable() ? $blog : false; }); Are those /members/blog/ pages are access protected from public users? If so, the above hook is not going to let them through because of the $blog->viewable() condition at the end. You could remove that, or better yet, replace it with a different condition: if($blog->isUnpublished()) return false; return $blog->id && $blog->template->name === 'blog-post' ? $blog : false; I can't remember at the moment if ProcessWire does another access control check on the returned page ($blog). So if you find it doesn't work returning the $blog page, try having it return $blog->render() instead.

The PW backend is extremely customisable all over both from the design and from functionality. For the design you can simply modify /site/templates/admin.less (https://processwire.com/blog/posts/pw-3.0.179/) or use AdminStyleRock (https://processwire.com/talk/topic/25668-adminstylerock-easily-style-your-processwire-backend-with-two-simple-settings/). So you can very easily adopt spacings, fonts, font-sizes etc. For functionality you can use hooks or custom admin pages aka process modules (https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/).

Hi @charger, Good idea! I've pushed a new version with a defaultValue field, where you should be able to accomplish what you need. Please let me know if you bump into any issues?

Hi @Andy thanks for the kind words! Regarding to the multilingual version, this was taken in to account from the beginning and I think that most things are ready (usage of translation strings, backend config. ... ), site is quite simple, but we will see ? thanks for a tip!

I took @bcartier's code from this post and made a configurable module from it. EDIT: to make it work, you need to follow 2 steps (thanks to @PWaddict for pointing it out): Add a page name to the default language on the Home page On Languages Support - Page Names module at "Default language homepage URL is same as root URL?" select "No - Root URL performs a redirect to: /name/" You can find the module attached. I can confirm that the redirection to a non-default language works on PW 3.0.172 DefaultFrontendLanguage.zip