Autofahrn

Did you check the additional logfile written into the backup directory? That should at least show "CLOSING ZIP" and "OPENING ZIP" along with the filename. You may check, if that file actually exists on your server. If it does exist and the re-open fails its probably best to modify the code to get the error, something like: $res = $zip->open($zipfile); if($res !== true) throw new WireException("Unable to re-open ZIP ({$zipfile}): {$res}"); https://www.php.net/manual/en/ziparchive.open.php#117339 Anyway, you may set the flush margin (DUP_ZIP_FLUSH_MBYTES in Duplicator.module) to a higher value to disable this close&re-open mechanism.

@jimmytricks, that post is in FormBuilder support section, as an owner of FormBuilder you should have access to it.

@jimmytricks, did you see this?

You are probably looking for the "collapsed" field and its constants. (collapsedNoLocked to be precise)

Did you also adjust the template's PHP code to generate markup for your image? Something like: echo "<img src='{$page->headimage->url}'/>";

Unless you consider creating the page tree like this, URL segments would be the solution. I'd probably sort the date fields in descending order, though ('site.com/2019/04/09/day-1' or simply 'site.com/2019/04/09').

That "/var/www" is the root path (within your filesystem) where your webserver places the content of your domains. This can only be changed when you point your server to some other folder. I guess you are currently working with the release version (1.2.9) of Duplicator, right? That one expands the site files into a directory level below which needs to be moved manually during the install. Please try the V1.3.10 above which should solve this. Btw, @flydev, do you plan to include the suggested domain name fix into ProcessDuplicator::getPackagesDetails to support dashes in domain names? If anyone else is using Duplicator on domains containing dashes, you may want to change these lines in aforementioned method (otherwise the package list stays empty): $parts = explode('-', $originalFilename); array_pop($parts); $tsstr = implode('-', $parts); with this dirty hack: $tsstr = substr($originalFilename, 0, 19); // 2019-03-20_01-15-41

In case someone else stumbles over similar demands like me, I put my modified AjaxSearch.js here: AjaxSearch.js It allows to use an existing #ajaxSearch element, so you may place the result anywhere in your markup (for example an overlay like I did here: https://pwflex.team-tofahrn.de/). Then I had a problem with excess GET requests which do not cancel server-side processing, so getting the result after typing many characters took seconds. That script uses a different scheduling. Its a direct replacement, so you may try and revert to the original safely. Edit: I've updated the script to send the value URI encoded like this: data: param_name+"="+encodeURIComponent(value), Allows to send queries containing special chars like &

Just want to announce that I've uploaded a first public beta to the ProFields board. So all owners of ProFields may give this module a try:

Sure, init.php runs before ready.php as well, but thanks for the link, which explains this more precisely:

I guess $pages is not "ready" in _init.php, since _init.php is loaded pretty early. When PW is up and running and before the template is executed, it runs site/ready.php. So placing hooks in ready.php is the recommended practice. sorry, no.

That $floors is just a variable set from the php file which actually includes the skyscraper-list-item.php. You'll have to modify the php file actually including this one (may be included multiple times). You may start looking in function renderSkyscraperListItem located in _func.php: // send to our view file in includes/skyscraper-list-item.php $out = files()->render('./includes/skyscraper-list-item.php', array( 'skyscraper' => $skyscraper, 'url' => $skyscraper->url, 'img' => $img, 'title' => $skyscraper->title, 'city' => $skyscraper->parent->get("title"), 'height' => $skyscraper->get('height|unknown'), 'floors' => $skyscraper->get('floors|unknown'), 'year' => $skyscraper->get('year|unknown'), 'summary' => summarizeText($skyscraper->get('body'), 500) )); ...and, of course, welcome to the forum!

Even if the compressed size does not differ much, don't forget that images need to be decompressed on client side in order to get displayed. Devices with ram limitations may fail to hold too much image data in memory and either fails to display the image completely or need to decompress whenever the viewport requires to render the image. Edit: The larger screenshot has a resolution of 1000x679 pixels, if images are decompressed into 32 Bits (RGBA), the footprint on client side is about 20MBytes, the smaller one with 628x426 only occupies 8MBytes. I wouldn't bother about client resizing for few of such images per page as well, but if your pages may contain more pictures (like a thumbnail gallery), I'd really consider to deliver smaller versions.

@RicknRoller, did you check the server response for these damaged images? Its always 42 bytes for exactly this string: This is intentionally invalid image data. Since the server replies with 200 I guess this is the content of the converted image file (you may want to check the folder /site/assets/files/2361/ for example). If the file on your server is correct, then I'd check nginx, if the file contains this string, there is an issue with image conversion for some reason. Sounds like some sort of shareware limitation...

Thought you're in a hurry... ?

So just edit site/config.php and add the new domain to the $config->httpHosts array. "migration" done.

Clear vote for Duplicator from my side, since its a no-brainer. You still may copy a very large (GBytes) /site/files folder manually, if required. Btw: Allowed domains are configured in your site/config.php ($config->httpHosts). If you go with the manual approach, you'll have to adjust this manually as already stated, otherwise Duplicator does this for you.

Since you probably implement the language switcher on your own, you are obviously free to only allow specific selections depending on the domain name (in $config->httpHost). You may even make this configurable in admin. You may either add some "allowed_domains" field to the language template, or create a new template named "httphost" (for example), which holds a multi page selector for supported languages. So there are multiple options to achieve that. That's exactly what I do in the described example. I'll check the domain name and set user's language accordingly. If you go with the httphost template, you may add another single page select for the default language, so everything stays configurable in admin (but you'll have to account for some additional database accesses, of course).

Something like this?

@Pete, @Erik, seems to work with a tiny modification in the foreach loop (loading an intermediate variable with $fM['type']): // Now use $data and $fieldsModel loop to create all checkboxes foreach ($fieldsModel as $f=>$fM){ $fmType = $fM['type']; $fields->add( self::$fmType($f, $fM['label'], $data[$f], $fM['desc']) ); }

never used PATCH before, so its only guessing... Could it be 'Content-Type' => 'application/json-patch+json', https://tools.ietf.org/html/rfc6902

If you create variations from an existing PageImage, they exist as files only, there is no need to save the page afterwards. For that reason you may create variations on the fly during output (i.e. thumbnail with reduced size).

As @bernhard said, the add returns the whole PageImages array including the new, unaltered image file. You may create variations afterwards but if you need to do some "editing" before, you'll probably have to go through PHP, download the file into a temporary folder, perform any kind of manipulation and then add the local file to the PageImages array.

According to this old post it basically seems ok: If the page already exists, you want to turn off output formatting first. Something like: $page->of(false); $page->images->add($imageUrl); $page->save();

If we are talking about content changes only (no template/field changes), then I'd also recommend ProDrafts. But it may depend on your use of repeaters, an images field within a RepeaterMatrix may be critical, for example, but in general repeaters are not a problem with ProDrafts. If "larger content changes" may require changes in fields and/or templates, than ProDrafts probably does not work. If it would be ok that any change goes through the staging process and all changes go live concurrently, then using two sites running on the same server may be the way to go. One directory serves the live site, another directory holds the draft site. Changes are only done on the draft site. Once finished, you simply switch document root to the draft path. Afterwards you'll clone the new live site (i.e. using Duplicator) and setup a fresh draft instance for next iteration. For intermediate content changes on the live site some hook on pagesave may be used to either log these into a file (for later import) or update the draft site automatically (sending some POST request).