SamC

Ok, so I tried to give the title a descriptive name to attempt to describe what I'm talking about. I've read quite a few posts, like this: Some call them snippets, or blocks, or chunks. This is the final piece I need really in order to get my site up and running in a way where fields/groups of fields are generic as possible in order to re-use them in different places. I'll try an example. As it stands, I have a template 'about.php': So I have: 1) $title - used for the page title in the admin section 2) $menuLinkTitle - if this is populated, used for main menu, otherwise use $title field 3) $windowTitle - I like to manually create the actual page <title></title> (also, this is displayed in the browser window tabs) 4) $showInMenu - if checked, puts in main menu. Legacy field, not actually using this atm 5) $mainImage - big header image, adds class 'full-width-image' to div, if empty, a class of 'no-image' is used 6) $headerStyle - choose between full width and 70%/30% split header 7) $mainHeading - text overlayed onto $mainImage, ckeditor so I can use <h2>, <p> and <a> tags and output directly 8) $body - body text Ok, so this is where things start to fall apart. The code for the template is something like this (added a bunch of comments and an extra row for clarity): //about.php <?php include('./includes/header.inc'); ?> <div class='body-row'> <div class='container'> <div class='wrapper'> //outputs $body field from page, $content is defined in _init.php <?php if ($content) { echo $content; } ?> </div> </div> </div> <!-- css color on colour-bg, generic-row is full width --> <div class='colour-bg generic-row'> <!-- container, clears after in case floats used inside this - site wont stretch past $max-width in bourbon/neat settings --> <div class='container'> <!-- wrapper contains content within the max boundaries --> <div class='wrapper'> <!-- THIS SECTION SHOULD COME FROM A BLOCK OR SOMETHING --> <h3>Why choose me?</h3> <p>This is the part that needs to come from a block</p> <!-- END BLOCK --> <div class='button-wrapper'> <ul> <li> <a href='<?php echo $pages->get(1069)->url;?>'>Read about my services</a> </li> </ul> </div> </div> </div> </div> <div class='generic-row'> <div class='container'> <div class='wrapper'> <!-- THIS SECTION SHOULD COME FROM A BLOCK OR SOMETHING --> <h3>My skills</h3> <img src='' alt='meme showing a funny animal photo or something with I got dat skills caption'> <p>This is the part that needs to come from a block</p> <!-- END BLOCK --> </div> </div> </div> I think this shows what I'm talking about. Pages aren't made up of header > middle bit (just output ckeditor) > footer. If they were, they'd be exceptionally boring! The main bulk of the text comes from the $body field which is fine. However, after that I wanted to be able to add rows. I guess one way would be to use extra fields on the 'about.php' template: 9) $whyChooseMeTitle 10) $whyChooseMeBody 11) $mySkillsTitle 12) $mySkillsBody However, they're way too specific can literally only be used for one thing, and IMO is quite a bad way to handle this. What about fields for each row: 9) $sectionTitle 10) $sectionTitleBody ...but then I can only have each of these only once on a template. So what about a repeater? 9) $sectionRepeater with fields '$sectionTitle' & '$sectionTitleBody' ...but I don't think it's really a good use case for a repeater either, not every row will have exactly the same fields. So what about child pages for sections? About (about.php template) - Why choose me (alternative template 1) - My skills (alternative template 2) ...and then pull the content into the about page via $page->children(). So I can define different fields for each page, but it doesn't seem very intuitive to me although it would work. These sub-pages would not need to have their own url though (I presume if they don't have an associated file, you get a 404 if going to these pages directly in the address bar). Bearing in mind, I'll know how to do it because it's my site, however, I'm thinking of the future, it must be as easy as possible for a client for similar situations. Or a new page in the admin like: Content blocks (where I can create sub-pages of every small piece of content for various pages) - Why choose me - My skills ...but this will be somewhere else in the tree hierarchy. An editor will be editing the 'about' page and saying to themselves "how do I edit the 'my skills' section? I just saw it on the page, went to 'about > edit', but it's not here?" I'm after some insight from the members here on how they handle what I refer to as 'blocks of content' and how an inexperienced user will be able to edit them easily. Thanks in advance. Apologies for the huge essay but I think this may be a useful thread for newer members too. -- EDIT- just read this --- This touches on what I'm talking about. Although I don't have $130 right now for profields.

Also, I just got another message from support about the default .htaccess (located in public_html in a fresh kualo hosting account) which cleared something up for me. When your hosting is first set up, there is an .htaccess file already in there (with a few rules, one of which is to do with comodo certificate - the default one installed on your kualo domain). Regarding the rules inside there, they need to also be copied into the .htaccess you use for processwire. i.e. you may have problems if you simply replace the (already in there) .htaccess in publc_html with the processwire one.

Your site worked with https before you uncommented in the .htaccess? Did pages all redirect to https after manually typing out http address instead? What was your setup before you did anything? I'm using PW v3.0.41 on a subdomain until the site is ready. All I did was uncomment: # ----------------------------------------------------------------------------------------------- # 9. If you only want to allow HTTPS, uncomment the RewriteCond and RewriteRule lines below. # ----------------------------------------------------------------------------------------------- RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ...and everything works fine. See screenshot of my cpanel php version, might help. I remember on one host, even after changing the PHP version, I still had to write: AddType x-httpd-php7 .php ...at the top of .htaccess or the namespace wouldn't work. Threw an error as soon as: //index.php <?php namespace ProcessWire; ...was run. Probably unrelated but I thought I'd throw it out there. *EDIT* I'm NOT using letsencrypt. The domain already has a already certificate. This is a quote from Kualo when I asked how my site works as https when I haven't installed anything: "The server is configured with cpanel provided ssl. Its free and when a hosting account is created, it gets installed automatically. The other one I mentioned i.e. Let's Encrypt SSL is optional. You can use any of the two but the one that get installed automatically as is on your account now should help."

I like simple sites, but I would be hesitant using 'dancing bear' in the title

I use a Kualo reseller account & they have been fantastic so far. All accounts I create have their own hosting account/cpanel login, the whole domain is https and good to go, with the option of using letsencrypt (free) if you prefer to the already built in one. Literally couldn't be easier. You also have to make minimal changes in PW to get this working, I was quite surprised how effortless it was to migrate a site from http to https. Kualo support has been top notch too, with live chat on the site exceptionally fast and helpful.

Nice! You're totally right though, I'm going back to the drawing board on this and using an inline image with absolutely positioned overlay text. My PHP is basic but came up with this which outputs the correct HTML: //main.php <?php getAvailableImages($page, 'fullWidthImage'); ?> //_func.php function getAvailableImages($page, $fieldName) { if ($page->$fieldName) { $str = ''; $mobileWidth = 400; $tabletWidth = 750; $desktopWidth = 1500; $xlDesktopWidth = 2400; $mobile = $page->$fieldName->size($mobileWidth, 200, 'center'); $tablet = $page->$fieldName->size($tabletWidth, 375, 'center'); $desktop = $page->$fieldName->size($desktopWidth, 750, 'center'); $xlDesktop = $page->$fieldName->size($xlDesktopWidth, 1200, 'center'); $str = "<img src='$mobile->url' srcset='$tablet->url {$tabletWidth}w, $desktop->url {$desktopWidth}w, $xlDesktop->url {$xlDesktopWidth}w' alt='adaptive image'>"; echo $str; } } //OUTPUTS <img src='/site/assets/files/1069/desk-duotone-1.400x200.jpg' srcset='/site/assets/files/1069/desk-duotone-1.750x375.jpg 750w, /site/assets/files/1069/desk-duotone-1.1500x750.jpg 1500w, /site/assets/files/1069/desk-duotone-1.2400x1200.jpg 2400w' alt='adaptive image'> Actually works quite well, never used srcset before.

That's what I did the first time round. The problem I encountered was when there was more than one large/full width image on the same page. I ended up having similar inline CSS multiple times with different classnames. Like on this one page site, I used the page ID to get unique classnames or every image would be the same, regardless of having different images on the child pages: <!-- start main content --> <?php $childPages = $page->children; ?> <?php foreach($childPages as $item): ?> <?php if ($item->mainImage): ?> <style type="text/css"> @media screen and (max-width: 849px) { .image-<?php echo "$item->id"; ?> { background-image: url('<?php echo getImage($item, 'medium'); ?>'); } @media screen and (min-width: 850px) and (max-width: 1499px) { .image-<?php echo "$item->id"; ?> { background-image: url('<?php echo getImage($item, 'large'); ?>'); } } @media screen and (min-width: 1500px) { .image-<?php echo "$item->id"; ?> { background-image: url('<?php echo getImage($item, 'xLarge'); ?>'); } } </style> <?php endif; ?> <?php echo $item->render(); ?> <?php endforeach; ?> <!-- end main content --> Saying that, it worked ok so I guess it wasn't a 'problem' as such.

Ok, you sound confident, I'll look into how to implement this on background images.

So I've been searching around the forum and read a number of posts for some kind of better way of serving up different images when on different width screens (not too bothered about height). I have some code like this: //main.php <div class='<?php if ($page->fullWidthImage) { echo "full-width-image";} else {echo "no-full-width-image";} ?> mobile-top' style='background-image:url("<?php if ($page->fullWidthImage) { getImage($page, 'fullWidthImage', 'desktop'); } ?>");'> I put a few breaks in so it makes more sense. Probably a bit clunky, but anyway, it works when I pass the fieldname and the size I want as strings. It calls a function getImage() in _func.php: //func.php /** * * @param object Page * @param string $fieldName (fullWidthImage, mainImage etc.) * @param string $img (mobile, tablet, desktop, xlDesktop) * @return string $imgUrl * */ function getImage($page, $fieldName, $img) { if ($page->$fieldName) { switch ($img) { case 'mobile': $img = $page->$fieldName->size(400, 200, 'center'); break; case 'tablet': $img = $page->$fieldName->size(750, 375, 'center'); break; case 'desktop': $img = $page->$fieldName->size(1500, 750, 'center'); break; case 'xlDesktop': $img = $page->$fieldName->size(2400, 1200, 'center'); break; } $imgUrl = $img->url; echo $imgUrl; } } So, my images get created when the page loads in the browser. I'm ok with this because I usually view a page once it's published on the big screen so the largest image is created already for subsequent loads. I used some CSS media queries in the past to show different images on different screens, but I think there must be a better way. I read about adaptive images and saw that the obvious problem is PHP can't work out the screen width, and even if you do work this out via JS, you can't pass the value to PHP BEFORE running this function because the page has already been sent back to the browser before the JS runs (is this right?). My initial thoughts were that I could pass a screen width (integer) into the function, then just return the correct image depending on this number, instead of passing 'desktop', 'tablet' etc.. something like this: getImage($page, 'fullWidthImage', $screenWidth); So I set a cookie in the head section: <script>(document.cookie='screenWidth='+Math.round(screen.width))</script> ...which I can see in the developer tools, an integer with value 1440. Getting somewhere! Then I realise I don't know how to get this number into my function. I noticed adaptive images ( http://adaptive-images.com/ ) creates images etc... at a certain path and uses an additional php script before the image is loaded. However, PW already has a way of easily creating different sized images on the fly, they're right there, I only need to serve up the right one. Seems unnecessary creating the images into a different folder for this, the PW structure is fine as it is. The 'srcset' attribute ( https://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/ ) is something that interests me, but the lack of support worries me. I'm not really after a copy/paste solution so any additional ideas are more than welcome. Thanks.

Interesting, I didn't know this existed. Good explanation too @kongondo thanks.

So I've not had a great deal of luck in fixing this. How do I move this issue forward? This needs to work for future projects and installing a module to handle this seems unnecessary.

Ok thanks, I'll give it a go this week.

I'm thinking of extending my news section which I've posted here previously which includes the following (put over a few lines to make it easier to read): // news-index.inc //LOOP <?php $publish_date = date('d/m/y', $entry->created); $created_by = $entry->createdUser->displayName; // I added displayName field so to not show the actual login usernames on the site ?> <div class='entry-info'> <span class='fa fa-calendar' aria-hidden='true'></span> Posted by <span class='entry-highlight'><?php echo $created_by; ?></span> on <span class='entry-highlight'><?php echo $publish_date; ?></span> </div> //END LOOP Now I was thinking to link the '$created_by' output to a page which lists the news items written by that user. For example, say 'Sam' is the author, how does this work in PW? site.com/news site.com/news/sam/ << something like this? Not sure how to go about this. Could I use the same news-index.inc template to output this because the markup will be the same? Any hints are appreciated, thanks.

I'lll give it a go next time I need to start a new site. In fact, that might be soon as I want to test this https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/

Can you share the code of the template where the pagination is? I always find an extra pair of eyes is helpful as it's easy to miss something when you're staring at it over and over.

Thanks everyone. I wont worry about for now then, it's only a demo site. Does this work on PW 3.0 though? One part says: Compatibility 2.5, 2.6, 2.7 but further down says: This version of the profile exporter requires ProcessWire 2.5 or newer. Could do with understanding the modules information pages a bit better, has stopped me so far from trying anything so far. After Drupal though, it's so nice to be able to achieve so much already with no added modules at all, it's fair to say PW has really re-ignited my dwindling passion for web design again.

Great thread, thanks everyone. Came in very useful today.

Totally just needed this, thanks

Hi @Ivan Gretsky do you have the code? I have working pagination on a site and may be able to help. My (stripped down version) of news-index is like this: // news-index.php <?php $entries = $pages->find("template=news-entry, limit=9, sort=sort"); //9 articles per page $pagination = $entries->renderPager(); ?> <div class="page-tabs-wrapper"> <div class='page-tabs'> <div class='upper'> <?php echo $pagination; ?> </div> </div> </div> <div id='news-row'> <?php foreach ($entries as $entry): ?> <div class='news-column'> A NEWS ENTRY </div> <?php endforeach; ?> </div> I had to also set 'Admin > Setup > Templates > Edit Template: news-index'. Go to URLs tab and check 'Allow page numbers'.

@helmut2509 I was involved in a thread about this. I was confused at first so this may be of use to you. This will get you up and running and being able to use the 'Add new' bookmarks shortcut. When you 'Add new', the system needs to know exactly where to place this new page with no ambiguity. So, you need to tell it 'for template X, it goes under parent X, and parent X is allowed template X as a child'. If that makes any sense! Just take a look at the thread, it's got pictures.

I need to propose a site next week so instead of going through the new install, I just copied my own site files + DB to a new subdomain and changed a few images and text etc. so I can crudely (and more importantly, quickly) show how it 'could' look. The thing is, the install generates a userAuthSalt number, which is now identical on both these sites, as is the installed timestamp. I changed the httpHosts because the red warning was driving me nuts. //config.php $config->userAuthSalt = 'NUMBER_HERE'; $config->installed = NUMBER_HERE; $config->httpHosts = array('MY_NEW_LAZY_SITE_URL'); The comments say: /** * Installer: User Authentication Salt * * Must be retained if you migrate your site from one server to another * */ If I get the go ahead, I will install and start from scratch, but does it matter about the userAuthSalt being the same on two sites? How do you generate a new one? Wordpress, for example, has a URL you can go to in order to get this information. Thanks for any additional info.

Sounds pretty awesome. Yet to try media manager but I think it will be useful in the future. Thanks for the info

So this fits in where an individual/company just wants to sell a few things? Instead of going for a full ecommerce solution? I have a friend that may sell a few 2nd hand laptops but the current problem is that a decision has to be made early, is it a website with some shopping added on, or a shopping site from the start (read: pre-made solution). I also need to be able to say with confidence to clients that they will be able to add shopping functionality later (whilst building the initial site with PW). So this interests me quite a bit. Thanks for mentioning this project.

Ok, some further delving. After removing the line: $(".hide_when_crop").hide(); Then going to page where the image is, click 'Crop', click the crop icon button... The original values for me were like the above. See this second screenshot below, the dimensions have changed. They are the actual size of the image as shown on the screen in the modal window. I wondered why these numbers were so random until I did it a few times resizing the window. The dimensions on the right are correct (and the overlay size with the draggable handles), this image should be cropped at 2400 x 630. Could the script use these values instead? This is where I think the script poos the bed. It sees 644 and says "wait, it's supposed to be at least 2400px!". However, the source code for the field that says 644 above shows different: <input title="Width:" name="width" id="input_width" class="input_pixels" type="number" size="6" step="1" min="2400" max="2400" value="2400"> ...so, I clicked on this field and try to modify the width setting which would usually be hidden by the above javascript (causing the 'not focusable' error because it's hidden). In my case, the value automagically changed to my desired width setting of 2400 and could not be further changed (because less than that violates my min-width, more than that violates my max-width). When this window first popped up, the value of width for me was ...click 'Apply'. Bingo. The height above of 1800 clearly isn't the real height of the resulting cropped image but this didn't cause me an issues because I haven't set a min or max height. So, I conclude that it's still not working as intended, but I guess we're moving in the right direction!

Quick update. Removing the line: $(".hide_when_crop").hide(); from ProcessPageEditImageSelect.min.js reveals a possible problem. When clicking apply, a popup shows [! Value must be greater than or equal to 2400px] pointing straight at the 831. Not sure if this is related to the original error, haven't got enough time right now to look into it further.