horst

AC is the city code of my hometown, the relevant part is following.

I add it to the ToDo, but may take some time to get done.

What is the intention of the question? Lesser to write? Or something other?

alternatively this could be interesting: https://processwire.com/talk/topic/14511-e-commerce-tutorial-with-processwire-snipcart-your-thoughts/

@tpr: Hah, - you are more than welcome to contribute in this regard, Mr. AOS!

Yep, with FormBuilder this should be much easier. Also there were some threads / posts I remember, that handled about formbuilder and email attachements. I would go into the dedicated formbuilder pro forum and check the posts there, or ask there for help, if you do not find examples. If you do not see the Pro Forum for FormBuilder, you should send a mail or PM to Ryan, so that he can add your account to the whitelist of that forum.

content of our cron.php: and the PwCron.module file: Everything is working fine from 20161107-10:15:06 until now, without errors, in a 5 minute intervall. EDIT: Did you refreshed the modules cache after changing the class-, file- and directorynames?

Hi @Junaid Farooqui, welcome to the PW an the Forums. I use a similar approach like you described. But I don't have to use templatefiles for all of my blocks. I only use a few main template files (mostly 2-5, and max around 10 for really large sites). For the blocks I use the Profield RepeaterMatrix, what is explained here: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/#repeater-matrix-is-released-alpha https://processwire.com/api/modules/profields/repeater-matrix/ With repeater-matrix you are able to level down the block / field files to different extends. My prefered usage is one matrix field with different blocktypes but one rendering file under site/template/fields. But one also can use one separate rendering/view file per blocktype under site/templates/fields/... Also it is possible to mix those usecases how you like. Repeater-Matrix was alpha in January 2016, but is stable now. Do cost a bit money, but is more than worth the saved time. You are able to build nearly an exact usage scenario with the free available Pagetable Field and additional template files for each blocktype. But it is more work and feels not that smooth like Repeater Matrix. Just another possibility here.

I have tried it, but added namespace to the files and also renamed the PWCron class-, file-, and directory-names to camelcase PwCron. Don't remember of any other changes. We have a cron setup to call cron.php every 5 minutes via CLI. All is working as expected after the changes described above, incl. the $wire API var.

There are two possible options to fit / contain images into a predefined rectangle / square: With the bare core options, you need to pass your width / height and an additonal setting for cropping = false. (the distribution default is true!) $containedImage = $page->original_uploaded_image->size(500, 500, array("cropping" => false)); If you find this to abstract or clumpsy, you may use the beautyful Pia, which reduces this to $containedImage = $page->original_uploaded_image->contain("square=500"); Optionally / additionally interesting in this regard maybe the weighten option of Pia here. ------ But both options only help in rendering images that fit into your defined boundaries. They will work with appropriate markup and css styles applied to them, but they do not apply a canvas to the image files. If you really want to increase the images filesizes for that, by adding pixels and not use css styles, you can use the ImageManipulators canvas method. It does exactly that. When using the Imagemanipulator with a recent PW version, please pay attention to use $image->pim2load()->...! the API examples all show the method for PW version prior to 2.6 ------ Examples with Pia and IM: $square = $page->original_uploaded_image->contain("square=500, quality=100")->pim2load("squarecanvas")->canvas(500, 500, array(255,255,255))->pimSave(); // or $bgColor = array(255,255,255); $suffix = "squarecanvas"; $innerSize = 480; $outersize = 500; $square = $page->original_uploaded_image->contain("square=$innerSize, quality=100")->pim2load($suffix)->canvas($outersize, $outersize, $bgColor)->pimSave(); // or $bgColor = array(255,255,255); $suffix = "squarecanvas"; $oneSizeFitsAll = 500; $square = $page->original_uploaded_image->contain("square=$oneSizeFitsAll, weighten=1, quality=100")->pim2load($suffix)->canvas($oneSizeFitsAll, $oneSizeFitsAll, $bgColor)->pimSave();

Yep, seems to be weird. Would be useful to see the code that is used to render the markup, and the info, where and how it is executed. And is there any sort of caching involved in the markup rendering chain?

hhm, Idon't know that template engine, and how it works. maybe you can debug the user / permissions for the calls? log into a file and compare, if there are any differences between superuser, normal call, ajax call, guest user normal call and ajax call?

which template is involved with the ajax call? does it have a file? which settings are bound to that template?

permission differences between guest and superuser check the settings for the template that you use for the ajax call.

I think you will need to modify your system / setup for this. One possible solution could be: add a hidden field to all templates / pages that may contain internal links hook into saveReady, check / collect all internal links from the current page save the current page id into the hidden field of each internal linked page Simplest solution to inform your client, is not to hide the "hidden field", but to show it readonly. If there are entries visible (that could be direct clickable links that open that page for editing into modals!), he has to change the content in that pages before. Additionally, you can hook into before page delete / page trash, and check the hidden field for entries programatically, to avoid accidental deletions before correcting the internal links. Another solution could be some sort of centralized maintained list / collection of all link relations. But your client seems to be enough tech savy so that the simple solution may fit already.

double-like!

I wouldn't consider it a bug of the croppable image module, as this seems to be only at your server (setup). Please provide the exact reproducable steps you have done, incl. installing and configuring the module. (You may try this by yourself in a test account, and if this behaves as you described, tell us the steps here, so that we will be able to reproduce it.) What does "Permisions ar OK" mean, exactly?

Isn't it, that you have an PageArray already in $result? Why not sorting this instead of the loop and double PageArray? Or do I get it wrong, what you are after?

I'm not aware of any issues with repeaters or repeater-matrix. (Repeater-Matrix would do no change, I believe, as it somehow extends repeater) Custom cropping is made for which user / role. Does he have the right permission added to his role?

all very useful snippets and hints! My current question was simply how the apache directives are that block access, and work in any Apache version (2.2, 2.4) I thought there were a need for different terms, depending on the apache version. But now, after reading @Martijn Geerts example (Thanks!), I saw that the Files-directive is also available in Apache 2.4. (unchanged as it was in 2.2 and also 2.0 and 1.3, and ...). So, thank you all for your help and tipps. This solved my question! @BitPoet: this one is very handy too. I bookmarked it for later, other use cases. Thanks!

it seems, that @arjen also knows Wikipedia:

Hi @Robin S, thanks for the hints. I search for a solution to secure pagedirectories from any http access (403 for everything). These pages are for internal use through a module. But I don't want to have the user to change $config settings for that. It should be done silently in the background for the module users. So, I believe I have to go the .htaccess way per directory. Only thing here is, I have to support apche 2.2 and 2.4 together. Does anybody know if this is working on every Apache 2.4 installation? <IfModule mod_authz_core.c> ## directives for Apache 2.4 Require all denied </IfModule> <IfModule !mod_authz_core.c> ## directives for Apache 2.2 Order deny,allow Deny from all </IfModule> Or if it is possible to find Apache 2.4 installations that do not have the mod_authz_core.c enabled / compiled in?

Hi, there is a need to create new pages via API, under site/assets/files/, that should be completly access blocked by PW (.htaccess) through a prefix dot. How can I achieve that through the API? $p = new Page(); ??

yes, it first checks if we have a grayscale image. If yes, we use grayscale as workspaceColorspace, otherwise \IMagick::COLORSPACE_SRGB. If you want to test it out, you also can change this in line 184 and use \IMagick::COLORSPACE_RGB (without the s! / sRGB and RGB) Also, if you feel adventures (==abenteuerlich?), you may test with disabled and enabled gamma conversion. Maybe you can experience some differences? To test without gamma correction, simply comment out the line 246. I'm interested in seeing / discussing anything you find. ----- The truth with Imagick is, at least with the PHP extension, that you cannot use any version check for detecting features. There are so many possibilities to compile it. If there is one thing not supported, the php extension simply seems to omitt that and silently return a 0. And with the CLI extension, (using convert), I tried to include all needed manipulations into one call. If we would call it multiple times, to determine some image attributes, it would to much slow down the process.