Leaderboard

Hey @Stefanowitsch thx for the question. I tried, but it's not so easy. The feature has been developed for RockCommerce where I ship a fully working checkout that is both easy to integrate and to customise. All files are in /site/modules/RockCommerce/frontend/... and can be overwritten by placing the same file in /site/templates/RockCommerce I don't think that this will be very helpful to anybody else, so I thought it's better not to bloat the docs with that feature at the moment. But I've added docs for the static rendering feature, which can be very helpful for many projects I think: Static Rendering Static Rendering is a convenient feature offered by RockFrontend that simplifies the process of developing new websites or features. It provides an alternative approach to generating markup by allowing developers to write static markup for specific pages or components, rather than utilizing multiple includes and delving into the intricacies of the entire project's architecture. How it Works If your project is already using RockFrontend's renderLayout() method to generate page layouts, integrating the Static Rendering feature is straightforward. All you need to do is create static markup files and place them within the designated folder: /site/templates/static. When a user requests a particular page, RockFrontend's Static Rendering functionality kicks in. It examines the requested page's URL and checks whether there is a corresponding static file in the /site/templates/static directory that matches the URL's structure. For example: If a user requests your.site/foo/bar, RockFrontend will search for a static file located at /site/templates/static/foo/bar.[php|latte]. Benefits Static Rendering offers several benefits for developers, including: Simplified Development: Writing static markup can be more straightforward than dealing with complex includes and understanding the project's full architecture. Quick Prototyping: Static Rendering enables developers to quickly prototype ideas without the need to set up dynamic functionality. Unique Custom Layouts: With Static Rendering, you can craft highly distinctive layouts for individual pages, allowing you to create designs that stand out from the rest of the website and cater to specific visual and functional requirements. Isolation: Developers can work on specific pages or components in isolation without affecting the rest of the application. Implementation Steps Create Static Files: Write the static markup for the desired pages or components and save them with filenames that match the URL structure. Place these files in the /site/templates/static directory. Access Static Rendered Pages: Once the static files are in place, RockFrontend will automatically use them for rendering when a user accesses the corresponding URLs.

Hi all, Hi @vincent you know, i download and translate every dev release the very day they appear on the website, i'm completely up to date up to the 3.0.224, i think that as soon as the next master release is on air, i won't be long to complete the translation and upload it to github,, of course i'll let you know with a little post here to be honest, i'm even already building a website for a french music school with the last dev release, it will be easy to upgrade with the coming master release ? have a nice day

Hi everyone, Hi @virtualgadjo, Thank you for your translation of the last master release. I also did some translations for it so I merged our works into a release. As a new master release will soon be released, don't forget to check the dev branch of the french repo : https://github.com/v-maillard/pw-lang-fr/compare/master...v-maillard:pw-lang-fr:dev?diff=split. I already translated for the 3.0.217's version of ProcessWire. So, if you start translating, you'll need to download this dev .zip ( https://github.com/v-maillard/pw-lang-fr/archive/refs/heads/dev.zip) first in order to have an up-to-date translation. Have a nice day, Vincent

Since classes/HomePage.php is part of the default site profile (blank profile) for recent ProcessWire versions, this makes it sound like the site might've been updated and possibly reinstalled. Would be interesting to know what those new files in wire were, e.g. if they were also files added by an update. Same goes for those new files in root dir as well. The site shouldn't update on its own, of course, so that still doesn't explain what might've happened in the first place. Your site didn't have install.php available, by any chance? That, combined with write permission for the web server user, could be one potential gotcha. This sounds like something that @ryan might want to look into, just in case. With the information we currently have available it is not possible to figure out much more.

Give us a screenshot and list those files, please, so we can check AND please download the whole directory and archive it in case someone wants to look into it further.

I sometimes end up with orphaned files as a result of doing mass imports during development. My code won't be quite right the first time around and I'll end up with extra and/or duplicated files. At least that was the case this last week. It was on a pretty large scale, so not something I wanted to clean up manually. Here's how I cleaned them out. Place this in a file in your site root called clean-files.php and then load it in your browser. /clean-files.php <pre><?php ini_set('max_execution_time', 60*5); // 5 minutes, increase as needed include("./index.php"); $dir = new DirectoryIterator(wire('config')->paths->files); foreach($dir as $file) { if($file->isDot() || !$file->isDir()) continue; $id = $file->getFilename(); if(!ctype_digit("$id")) continue; $page = wire('pages')->get((int) $id); if(!$page->id) { echo "Orphaned directory: " . wire('config')->urls->files . "$id/" . $file->getBasename() . "\n"; continue; } // determine which files are valid for the page $valid = array(); foreach($page->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFile) { foreach($page->get($field->name) as $file) { $valid[] = $file->basename; if($field->type instanceof FieldtypeImage) { foreach($file->getVariations() as $f) { $valid[] = $f->basename; } } } } } // now find all the files present on the page // identify those that are not part of our $valid array $d = new DirectoryIterator($page->filesManager->path); foreach($d as $f) { if($f->isDot() || !$f->isFile()) continue; if(!in_array($f->getFilename(), $valid)) { echo "Orphaned file: " . wire('config')->urls->files . "$id/" . $f->getBasename() . "\n"; // unlink($f->getPathname()); } } wire('pages')->uncache($page); // just in case we need the memory } When you can confirm that it has found the right files (and no false positives) uncomment the "unlink" line above to have it remove the files on the next run.