horst

I assume, the Samsong mic is for singing only.

@Roope: this is good news. I have only one suggestion: I would avoid the uncontrolled automated mode! (for every size() request!) Instead I would bind it to a defined suffix option (tinify). Or you do it the opposite, check for a suffix (notinify) and compress all others. This is the only way to be able to also produce intermediate images wich resulting pageimages will be passed to another image->size() request. Also, if the image is marked to get compressed, you need to check the setting for quality (if it can compress jpegs) and adjust it to 100%. If you compress images with quality settings lower than 100 and afterwards pass them to the compress service, you will get results with higher filesize! and with lower visual quality! If you have any questions to my suggestion, I'll be glad to give more info and / or point to some. https://processwire.com/talk/topic/6667-jpegoptimimage/#entry65531 (the first part) http://images.pw.nogajski.de/jpegoptim/ (compared different imagesizer quality filesizes)

Thanks! I will try this on a site where it behaves a bit same like you described.

What does this exactly do? Can you give a short example how the search phrase has to passed to PW?

Ah, here is a very valuable post from within the case studio of the National Geographic Site: https://processwire.com/talk/topic/7494-case-study-the-triumph-of-national-geographic-traveller-india-in-processwire/page-2#entry72498 And, also it is that mainly new users ask here the community, I want ask one question too: What are the alternatives to PW?

Hi @delueg, I'm short in time ATM, but can answer a little part. The first only in addition of what @kiennguyen1101 already said. The primary part is to figure out and define the best data structure in PW for that project, so that the app can run fast and you can map / import the old data. There were case studies here in the forums and published sites in the site directory (or in the forums too) that were sites / apps on very large scales. Maybe to read a bit of that may give you valuable impressions. (National Geographic Case Study, CMSCritic Development Case Study, Villas-Rental, ... maybe other users can add some more links, - I remember threads and posts talking about 1 million pages in one PW installation and others, but have no bookmarks at hand) The second You are coming to Processwire at a point where the first PW 3 stable version will released not that far away. Also, that upgrade is the first one in the last 5 years or longer, that bring in a major change from no namespace to use namespace(s) in PHP. That normally would break existing code of templates and third party modules, but Ryan has built a rocksolid FileCompiler to handle both, (upgrading from 2.x to 3.x and the use of third party modules (developed for PW 2.x) in PW 3.x), automatically behind the scenes, without any manually interaction. But I personally have changed to start with PW 3 on every new site now. Upgrade guarantee for all ProModules is in. For third party modules, PW cannot guarantee, (but see: FileCompiler!). Also, for all third party modules that are used by many people, there ever was found a new maintainer here in the community, if the original owner / creator could not do it anymore. "Upgrade to a core change not fast enough" is a very vague formulation. I think, if you have a project like yours once online and running, you never will change from a (then stable PW3) version to a first PW4-alpha version. So, as the development cycle of such an major upgrade will take six (?) month or more, there is enough time for modules developer to upgrade too. (But once more: it isn't really necessary, seeFileCompiler) Also, core upgrades in PW are not necessary if you do not need newly introduced features. This is different here than with W*rdPr*ss or others. I have running sites on PW 2.3, 2.4, 2.5, 2.6, 2.7, 3.0 and don't need or want to change them. I only have updated sites core when I want to use a new feature there.

hhm, yes, but may be also: no.!? - At least, then you will need the php user to have filesystem write access, or not?

If the filesystem is not writeable, no one and nothing can do anything. I suggest the same as @Kongondo. Grab you a ZIP of your desired branch (devns I assume), copy it to your server (local or online), make sure, at least your site/assets/{ALL_SUBFOLDERS} are writeable by the php-user. Then run the installer. If you later on want to install a newer devns version, you have nothing more to do then to change the complete wire folder. For example, if you have PW 3.0.15 now, rename your wire folder to wire.3015, copy/upload the wire folder of PW version 3.0.17 to your installation and login into the admin. That's it. Easy. And yes: - Welcome to the forums.

what Jan said, you can define sitewide $config options. Have a look into wire/config.php and copy the part of $config->imageSizerOptions into site/config.php if you want to change something. For example, if you want to have the "upscaling" disabled sitewide, just set it to false in your site/config.php. If you want to have a different value for an option then set in config.php, you can pass a options array with the image resize functions: $options = array("upscaling" => false, "sharpening" => "medium"); $image->width( $width, $options ); $image->height( $height, $options ); $image->size( $width, $height, $options );

Hi, welcome to the forums. I'm not sure what you have done with "git checkout -b devns" and afterwards with "git checkout -b dev", but dev and devns are two seaparate branches of Processwire. dev is the 2.7.3+ dev branch, and devns is the 3.0.15+ branch. I'm not comfortable with git, but why do you checkout two times?

what? please try: foreach(array(-5, -1, 0, 1, 5) as $id) { var_dump((bool)$id); }

What I exactly meant is: sanitizing with intUnsigned() and add some own logic (template or equal).

Soma is right here. It isn't enough to sanitize to an integer, you also need to add some own logic, that reflects what you are expecting.

$sanitizer->int() or php natives (int) or intval() will do. Looking up in tools like API-gen, maintained (with everytime the newest codebase) by Kongondo, is much more faster than asking (such simply code/method related things) in the forums. I highly suggest to use this. It will save you a lot of time, that you otherwise have to wait until someone other answers your questions. --- EDIT: Oh damn, - @arjen beats me, while I made the screenshot!

Hi @wsjmdavies, welcome to the forums. This seems to be not exactly determined what you've explained. But no problem, we can go together step by step to inspect what happens. Regarding uploaded (original) images and image variations: If you upload new images to an images field, the original uploaded files never get altered, with one exception. (I come to this later *) So, the original (uploaded) file regularly is unaltered, means has the exact filesize and contents as your local copy. Only the filename will get altered to match the criterias for asset filenames in PW. (all lowercase, 0-9, a-z, _-, no dots, etc) Image variations derives from the original uploaded source and are altered according to your request. (different dimensiones, optionally cropped, etc). A few part is reflected in a suffix that is appended to all image variations filename. (basename.jpg becomes basename.0x100.jpg or that like) --- How have you determined that the original file gots altered? What are your settings in the images field? Do you have any setting there in the fields for max-width or max-height? (* this would be the only exception where uploaded files can get altered!) You have uploaded an image that contains compressed image (bitmap) data. Photoshop is able to apply a (hopefully) lossless compression to the bitmap data before storing it into the image file. ImageRenderingEngines in webenvironments often have not included equal compression algorithm. SO they uncompress the bitmap data, alters it, and stores it uncompressed, or with much lower compression rate into a new file. (What explains why a new (variation) file has higher filesize) BTW: using compressed images as original sources for variations is a bad idea. It is not much relevant with PNGs, but highly with JPEGs: mostly you will not serve the originals, (or you shouldn't do), but generate and serve variations. to generate one, you need to open (and uncompress compressed bitmap data) of the original image (more CPU usage each time) with JPEGs, what do not have lossless compression, you multiply building of compression artefacts with each saving / compression of bitmap data Best practice is: upload (original) images with 100% quality, and / or without compression. Do not serve those originals directly! If you need to serve images with the full dimensions, create a variation with 100% width/height, but lesser quality (e.g. 80% - 90%) $original = $page->images->first(); $options = array('quality' => 80, 'forceNew' => true); // forceNew is recommended for testing purposes only!! $variation = $original->width($original->width, $options); // create an identical variation with lesser quality and filesize

php function isset() ?

Or do you mean Repeater? Here you can group (via Template) fields together and use them multiple times in one page.

PageimageSizerImagick isn't compatible with PW greater than 2.5.11 ! It doesn't support the then (2.5.11) introduced naming scheme for image variations in PW. It was more like a case study. But maybe you can switch to PW 3 devns, there you will find support for Imagick PHP-Extension, ImageMagick-CLI and NETPBM-CLI supported. If you can do, you need to read upon how to "convert" CroppableImage to work with PW 3. KentBrockman and noodles have posted this into its support thread: https://processwire.com/talk/topic/8709-croppableimage/page-7#entry113941

In addition to LostKobrakai, the function schema looks like: public function mySrcsetFunction($event) { $image = $event->object; $markup = "<img src='{$lqip}' data-src='{$image->url}' {$aspectratio} class='lazyload lazypreload' alt='{$image->description}' />"; $event->return = $markup; }

Not sure if I can understand what you have done, nor how you have done it, nor what you are after. ?? Looking into my glass ball, I would say: First, inspect the raw value of $input->post->note_page_id <?php echo "<pre>"; my_var_dump($input->post->note_page_id); die(); If you expect an numeric ID and it does contain more than that, you should change your html form field accordingly. And if you get a numeric value, you can sanitize with int, not text. Or you simply use PHPs typecasting via (int) or intval(). $note_page_id = (int)$input->post->note_page_id;

and if you want to retrieve an image by name $article->product_image->get("name=picture.jpg")->url

A pro would be, to have it into the TracyDebugger toolbox makes it independant from your own browsers and its extensions. Useful in the more rare cases, where you are using a foreign PC. So, it should be in, but disabled by default.

Have you tried the PagePathHistory module? It handles the redirections automagically under the hood whenever you change a pathname. (If I remember right, it is a core module(?) by default disabled)

Do you use any sort of markup caching? TemplateCache, ProCache?

I think you can use what you best like. If you are comfortable with repeaters, you can use this. If you are more comfortable with others, use others. But I cannot understand why you want to do it from scratch, if your questions already start at this early point? Is this a free project, that you want build just for learning, or is this a productional project for a client?