Leaderboard

I recently inherited a site built in Wix because the person who built it disappeared, and the site owners weren't provided with a login. Reverse engineering it proved a nightmare, including having to use Chrome Developer tools to individually download images since the way Wix served up the pages, you couldn't just save them and capture all the content. I probably could have built them a site from scratch for less, but they really wanted to keep the design, and they didn't have backup copies of their images. I've rebuilt it as a static site at this stage just using SSI for headers and footers, with Bootstrap 5.x to provide layout, and I've been able to discard 97% of the code on most pages and have something that looks pretty much the same. Pages that were up around 1MB of HTML from Wix came down to about 15KB with Bootstrap, with almost identical appearance. I'm not a great designer myself, but Bootstrap makes doing pretty much any kind of layout fairly easy, and it's easy enough to strip out unused CSS to slim it down once you're finished. Customising Boostrap via scss files is pretty easy, particularly if you use something like Visual Studio Code which has extensions that will automatically compile scss on save. There are other CSS frameworks like Bootstrap such as UIKit that ProcessWire itself uses as well, and using any of these is a great help if you want to ease into the intricacies of CSS with a framework with components that just work, but that you can customise as you need and as your skill develops. These front-end frameworks are much like ProcessWire itself, in that they don't set out to tell you how to build sites, but give you a useful set of components that you can put together like Lego bricks or perhaps Meccano is a better analogy, as you actually have to bolt things together by writing some code, whereas website builders hide all of that away from you (and create horrible code), but you do get parts that are already made to work together.

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, []);

https://processwire.com/talk/topic/27528-weekly-update-– 2-september-2022/

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!

@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?

Please don't ? We have a new way of doing that, because ->getUnformatted() also gets temporary items, which is likely not what you want. This is how to do it in recent versions: $page->get("images.first") --> I've searched hard but did not find the blog post about it ? Anyone?

Your answer enlighted me! Everything works smoothly if you go in pages submenu -> find But since i'm a lazy dude My action was hitting the search form on the top right.

Do you have the old site still running somewhere? If yes, this query should give you the schema and table with the offending column (if it's in fact a column with that name and not some other issue with SQL syntax): select * from INFORMATION_SCHEMA.columns WHERE column_name = 'index';

Thanks! I added my proposed solution to the issue.

@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.

@orchardheightsdental Netcarver is right that you need to get a look at the /site/assets/logs/errors.txt log and see what the last entries are in it. If you don't have SSH access you can also grab it through FTP. My best guess is that your web host upgraded to PHP 8.1 or 8.2 and that you are running a much older version of ProcessWire. PHP 8.1/8.2 upgrades can sometimes break old versions and old sites. I can tell that you are running a pretty old version because it is missing the JS files for AdminThemeUikit, which was added more than 6 years ago. The good news is that the front-end of your site seems to be working. A major PHP upgrade on an old site would be more likely to break both the front and back end. Most likely an upgrade to a more recent PW version (like 3.0.210) would resolve the issue. Though it's also possible that the issue is coming from a 3rd party module that's installed, or something else, and that's what the errors.txt log would tell us.

It's not really going to cause issues, more of a visual misbehavior. Starting with version 3.0.190, repeater labels can contain a hexadecimal color value preceded by a hash sign, e.g. #ff0000. Short notation for CSS colors like #ff1 is also supported, so PW interprets item numbers with more than two digits as colors. My guts say this is unintended and could be easily fixed by reordering the code in InputfieldRepeater so the color substitution happens before replacing the counter placeholder, but the change was inititally targeted at the Repeater Matrix Pro fields which I don't have here. Probably best to file a github issue and let Ryan take a look. These are the lines in question: // update index numbers? if($hasCnt) { // replace "#n" with index number of repeater item $repeaterTitle = str_replace("#n", "#$cnt", $repeaterTitle); } if(strpos($repeaterTitle, '#') !== false) { $repeaterTitle = preg_replace('/#([a-f\d]{3,})/i', "$colorPrefix$1", $repeaterTitle); if(strpos($repeaterTitle, $colorPrefix) !== false) $hasColorPrefix = true; }

Hi @fruid, Just to be clear, "media_manager_image" is an internal native ProcessWire field of type FieldtypeImage used by media manager to store media items that are of type image. Its value is a Pageimages object. Back to your issue, mmfield should be a Media Manager field of type FieldtypeMediaManager. Its value is a MediaManagerArray. A MediaManagerArray contains one or more MediaManager objects. This is analogous to a WireArray can contain several objects of type WireData. All these work for me. The value of $image here is a single object of type MediaManager. What do you get when you dump $image using Tracy? Screenshots test_1_media_manager is equivalent to your mmfield.

95% custom.

@LostKobrakai I took a look in the core sorting functions. Unfortunately it doesn't work as expected and the $pages API reference is faulty and should be updated: // set $page to have sort=5, moving any 5+ sort pages ahead $pages->sort($page, 5); // works as expected // same as above using alternate syntax $page->sort = 5; // WILL NOT moving any 5+ sort pages ahead it just changes the sort value. Duplicates possible $pages->sort($page); // WILL NOT set anything. This is a getter not a setter. Similar to $page->sort In the $page API reference, $page->sort is described as follow which is faulty too. Use $page->index instead to get expected/ described result. But you cannot use $page->index as a setter! Currently the only (nearly) working solution needs the following 2 steps $pages->sort($page->parent, true); // re-build sort values for children of $page, removing duplicates and gaps $pages->sort($page, 5); // sort +=1 for all pages above In this example you will get an unexpected result If the sort position related to the siblings was 4 before. There will be no change, because there is a gap at sort position 4 now. What I would expect using this function If I set sort I would expect a zero based position related to the page siblings. Example $pages->sort($page, 2); 3 page siblings having the sort values 4, 7, and 11. If I assign a sort value 2 to the page with the former sort value 7 I would expect the page moves to the end (last index number under 3 siblings), but currently it moves in the opposit direction and will be the first one related to its 2 siblings. Nice to have in the future (already available via PageMove module) // move page to the first or last position related to its siblings $page->moveFirst; $page->moveLast; $page->moveFirst($newParent = null); $page->moveLast($newParent = null); // move the page to an index position relative to its siblings, optionally change the parent too in one step $page->move($parent, $newIndex = null, $selector = 'all') // or simply $page->setIndex($newIndex, $selector = 'all'); Expecting a core update related to this I will not push the module to the modules directory. Feel free to pull it from github directly until this is available from core.