BitPoet

You can't, without running into major headaches, change the root page (i.e. "Home"). What you can do is create a copy and move all children with the exception of the system fields (admin, trash, 404) under the new home. Then you can adapt the Home page to your liking (i.e. switch template, edit contents, whatever). Here's a small script that automates that task. This hasn't been tested extensively, so I don't advise to run this on a production system, only on a copy (or at the very least make a test run on a copy and then make sure you have a full, working database backup at hand). You can copy this code into a script (e.g. as "clonehome.php") in your PW installation root and run it from the command line. <?php namespace ProcessWire; if(PHP_SAPI != 'cli') exit; include('index.php'); error_reporting(E_ALL); ini_set("display_errors", true); /* ************************************************************** * CONFIGURATION FOR CLONING * *************************************************************/ $adminUser = "admin"; // PW Backend User $childrenToLeave = [ $config->adminRootPageID, $config->trashPageID, $config->http404PageID = 27 ]; /* ************************************************************** * END OF CONFIGURATION * *************************************************************/ $session->forceLogin($users->get($adminUser)); $home = $pages->get($config->rootPageID); echo "Cloning Home" . PHP_EOL; $newOldHome = clone $home; $newOldHome->setQuietly('_cloning', $home); $newOldHome->addStatus(Page::statusSystemOverride); $newOldHome->removeStatus(Page::statusSystem); $newOldHome->removeStatus(Page::statusSystemID); $newOldHome->id = 0; $newOldHome->setIsNew(true); $newOldHome->parent_id = $home->id; $newOldHome->of(false); $newOldHome->set('numChildren', 0); $newOldHome->removeStatus(Page::statusSystemOverride); $pages->save($newOldHome, ["quiet" => true]); echo "Home page cloned, new id is {$newOldHome->id}." . PHP_EOL; $childrenToLeave[] = $newOldHome->id; echo "Moving children:" . PHP_EOL; // Now move all children, with the exclusion of admin tree and special pages (404, Trash) // as configured in $childrenToLeave foreach($pages->find("parent=$home, include=all") as $child) { if(in_array($child->id, $childrenToLeave)) continue; echo "- {$child->name}..."; $child->of(true); $child->parent = $newOldHome; $child->save(); $child->of(true); echo "[X] Done" . PHP_EOL; } echo "FINISHED. All children moved." . PHP_EOL;

That shouldn't happen, but you should be able to see what went wrong either in the http server's error log or in the PHP log. My first guess would the standard template's PHP code, but it could be a lot of things.

"Internal Server Error" or "Page Not Found"? The latter is what you should be seeing for inaccessible files, and that's the correct thing for ProcessWire to do according to HTTP standards. If you see an internal server error (status code 5xx), something's wrong. For a "Page Not Found" error, PW renders the "404 Not Found" page under "Home" unless you have configured a different page as $config->http404PageID in site/config.php. You can create your own error page template and change to that in the page properties to adapt the output and make it more dynamic.

Have a look here:

Deleted, I somehow answered to an old post.

Since you have an array(ish) $clearPages, it looks like you want to recreate the cache for depending pages too (blog categories/tags pages etc.?) so I'd guess you'd have to make a request for each of those. It might become a runtime issue if you have multiple complex pages to render, but the worst that could happen is that rendering breaks at some point and the first request to an uncached page is slower.

You want to write that line: $mobile_menu = $homepage->children; in one of a few different ways, e.g.: $mobile_menu->add($homepage->children); // or, though no need to create a new PageArray beforehand in this case: $mobile_menu = $homepage->children->makeCopy(); to avoid any caching issues and avoid changing "builtin" PageArrays. If you directly assign $homepage->children, $mobile_menu points to the already loaded instance of the children PageArray of $homepage and your new, empty PageArray gets discarded. Repeated calls to $pages->get(1) are cached and return the page object already in memory. I can only guess since you didn't post that part of the code, but it looks like you may have inadvertently manipulated $homepage->children when you built your main navigation. Make sure to use add() or makeCopy() in that part too.

That's strange. The code works fine here (3.0.132). Can you take a look into the pages table and compare the entry for id 92871 with a working user (parent_id, templates_id, status)?

I was thinking of combining the two. Have a toplevel Media Library somewhere and let ImageReference pull its images from that. Though I'm not familiar enough with the latter to judge if that would be a working solution.

You should be able to replace the try/catch block with this if clause, but this is untested (I'm not using the module anywhere): $imgSmart = $page->get(implode('|', $configData['imageSmart'])); if($imgSmart instanceof WireArray) { $pageData['image'] = $imgSmart->first()->httpUrl; } else { $pageData['image'] = $imgSmart->httpUrl; }

Have a look at @apeisa's Redirects module. This lets you configure arbitrary paths and pages they should redirect to.

Looks to me (untested) like you shouldn't have images.description but rather description only in your selector, since you're already operating on the images themselves, and images themselves have no template (you have already limited the parent page in your $pages->find call to that). $match->images->find("description~=$keywords"); should be enough.

You could either use the fork by esl51 or incorporate the fix yourself (changing the "count" in line 245 to "!empty"). Maybe someone actively using the module could talk with @Nico Knoll about maintining the module on GitHub? There's already a pull request that fixes this waiting in the repo.

That might actually be something @ryan could implement in the standard with a module config setting for ProcessLogger. So how about a pull request for that? ?

Ah, that's the ugliness of Repeater magic once more. Inside the FieldsetPage, the field's name and id change from crondate to crondate_repeaterXXXX (where XXXX is the number of the fieldsetpage item) to prevent collisions. The hook probably should check against preg_match('^/crondate(_repeater\\d+)?$/', $field->name) instead of a straight comparison to work both inside and outside a repeater/fsp. Not exactly sure how the JS part is addressed best.

Have given Media Library a look?

You could adapt and try out the code in this post:

If you can live with the fact that a counter is inserted into the filename, I'd copy the file to a temp path, then add that to sender_logo_standard and remove the temporary copy after the page was saved. There's a possibility to intercept the hook method that performs the file system level deletion with your own prioritized hook, but doing so is not completely free of side issues since the original hook removes itself, with doesn't happen if intercepted. Another idea that comes to mind is wrapping your replacement fields inside a FieldtypeFieldsetPage. This will be editable just like a regular fieldset in the page, though for api access, you have one more level of indirection, i.e. $single->sender_log_standard_changes would become something like $single->changes->sender_logo_standard_changes (but you might re-use the sender_logo_standard there instead of having two different fields, so it could be $single->changes->sender_logo_standard). The advantage is that $single->changes would be a different page behind the scene. The moment you add the image from there to your regular image field, PW sees that this belongs to a different page and creates a copy.

Ah, now it makes sense (and no sense for templates), no idea how that slipped past me. Thanks a lot! I removed the warning in version 0.0.3.

That's a good question which I don't have an answer to. I copied that from ProcessField, which behaves the same - a warning if you use "manage tags", but none if you assign such a tag in the regular Field edit form. Good point, thanks. Already added in 0.0.2.

Here's a small new module that adds a "Manage tags" button to the template list, just like the field list already has. Easily add, remove and change tags for your templates. https://github.com/BitPoet/TemplateTagsEditList

The userauthsalt has to be the same as on the dev environment if you copy the DB over! If only the home page works, it's most likely a rewrite issue. If you installed in the root directory, RewriteBase is not needed. Otherwise, set it to the subdirectory your PW installation resides in.

...or you can use this small module that (with a lot of nicked code from ProcessField) adds the functionality to the Template list: https://github.com/BitPoet/TemplateTagsEditList Best try it out on a copy of the site though, I haven't tested it much yet. Anyway...have fun ? (I'm soon going to use this a lot myself to clean up a few really complex sites...)

I have found that depending on the theme and device, #pw-masthead might to cover everything. #masthead, #branding, #pw-masthead, #pw-masthead-mobile, body.AdminThemeReno a.main-nav-toggle { background-color: #666 !important; }

On the other hand, "flat", that is non-normalized tables, scale only somewhat. Where they don't scale well is in update performance, so if a site is highly dynamic, updates create massive locks and those locks impact the frontend too. Then, if a CMS uses non-normalized tables, multi-valued and complex field contents will have to be serialized and de-serialized to fit into their column. That's only fine until you want to search for it. In that case, things get ugly, and if that search can even be implemented, it will be a much worse performance hog than ten extra field tables in PW. The web server question "does it scale?" is usually not answered by database statistics. It's answered by a concise design that allows for good, hierarchical and atomic caching strategies. If a site is designed with that in mind (and even sometimes when it isn't), performance can easily be improved. I like to take our corporate intranet as an example, with 12000 active pages, now 125 templates, 28 repeaters, 35 site modules, 220 additional php scripts and everything a good book on website speed basics tells you not to do ? We have around 1000 users who use it daily, and a good number of them have a few auto refresh pages loading every 2 minutes. I'm running opcache, use processwire's $cache interface to populate recurring, user dependent patterns in some fields and have a small home-written module that uses memcache to store and refresh data that would otherwise be retrieved from external systems with each call. First time page load including fonts, styles and a healthy collection of scripts is about 5 seconds. Times to page view for consecutive visits to the site are almost always below 2.5 seconds. Everything runs on one single server, including the database, and there's no caching proxy in front of it. That's on PW 3.0.125. I'm currently in the process of upgrading to latest IIS, latest PW stable and latest PHP. My first impression is that I'll probably get the time-to-view reliably below 2 seconds with a bit of tuning.