kongondo

@Dazzyweb.. <h1> versus <h2>: I'll see whether to include this in the renderPosts() $options. Of course <h1> should not be the case if outputting more than one post on a single page! Your other questions should be answered in the following (I hope). Social Media Icons I did a lot of thinking regarding how to implement social media icons in both $small and full posts (whether single or a list). I bounced a few ideas around: 1. Create a Social Media Icons Widget Seemed OK on paper, maybe with repeaters. But, there's several social networking services/sites out there as well as many approaches to include them (buttons) in one's website. OK, it mainly involves using javascript but Twitter's and G+ are different. So are FBs, etc. We don't want to be messing with that in the GUI. So, I shelved this idea. It would be impossible to cater for all the different Social sites and the approaches to implement their icons/buttons. Twitter alone has 'share', 'follow' blah blah... 2. Include SMI using Hanna Code. Great! Great I thought. One could include the buttons anywhere in their blog_body. However, this wouldn't work for $small posts. This is because these are rendered after passing through strip_tags() which was stripping out everything so would strip out Hanna Codes output markup as well. It reminded me about this post. Of course strip_tags() has a second parameter for $allowable_tags! So at the API level, I have now made this configurable in renderPosts() $options. The dev can specify which tags they want not to be stripped out - e.g. place an image at the top of your post that you want to be rendered with the $small post (currently it would be stripped out). Use the feature with caution of course! In addition it would be very tedious adding Hanna Code tags in each and every post! OK, maybe one could automate this using Hanna Code API but don't know if that would work. Ideally, we want to add our icons at the template file level...I think... 3. Developer to include SMI in their template files! At first I thought this would only work great for single posts. Render the single post and include the SMI beneath the post. This would not work well for a list of posts, whether full or $small. But aah, ProcessWire is OOP! We can manipulate objects on the fly! So, we can 'inject' some extra input into our objects properties or even create new ones and output those. Now, I would really love to hear what the other seasoned devs think about this (see code below). Any issues using this approach? Is there a better way? If posts fetched and manipulated this way were limited to some small number, would there still be issues? So, this is what I came up with so far in my limited tests, seems to work well (especially in conjunction with $allowable_tags). Here, we add a Twitter Share Button. I am not sure $post->url is working fine though (relative url?). A count of tweets should be showing next to the button (see screenshot below). I haven't read up properly on how to implement the Twitter buttons. Have a read here (twitter dev). <?php $posts = $pages->find('template=blog-post, limit=10'); foreach($posts as $post) { $socialMedia = ' <a href="https://twitter.com/share" class="twitter-share-button" data-size="large" data-url="' . $post->url . '"> Tweet </a>'; //we manipulate each $post object's blog_body property. we add twitter 'share' button $post->blog_body = $socialMedia . $post->blog_body;//prepend social media code to $post->blog_body } //CALL THE MODULE - MarkupBlog $blog = $modules->get("MarkupBlog"); //main content $content = $blog->renderPosts($posts, true);//$posts is a PageArray; true means truncate post ?> <!-- in our HTML in appropriate places --> <script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs'); </script> <div> <h1 id="headline">Testing Social Media Icons</h1> <?php echo $content;?> </div> Notice here we've allowed <img><a> in the summarised post. Other than this, I have almost finished making renderPosts() highly configurable using $options - e.g. ability to change 'View More' to whatever you want, e.g. 'Continue Reading'; List a post's tags/categories (separately) or not and whether to list them at the top of the post or at the bottom; change 'Posted by' to whatever you want or not include this info, etc.

You mean to manually remove the module? You can use the API: $modules->uninstall("ProcessPageDelete"); Or delete the module's row in 'modules' table in the db using phpMyAdmin or similar...

@Suntrop, Just to echo what Joss has said and I realise my post above was probably ambiguous.... CKEditor the module is a core module and lives in /wire/modules/Inputfield/InputfieldCKEditor/ - Don't touch this However, custom settings should be done/placed in /site/modules/InputfieldCKEditor/. Here you will find the following files + folder README.txt mystyles.js config-body.js config.js plugins contents-inline.css contents.css Read the contents of those files + see these guides for how to customise your CKEditor https://processwire.com/blog/posts/august-2014-core-updates-2/#upgrades-to-ckeditor https://github.com/ryancramerdesign/ProcessWire/tree/dev/site-default/modules/InputfieldCKEditor http://www.flamingruby.com/blog/processwire-weekly-13/#1-1 http://www.flamingruby.com/blog/processwire-weekly-13/#1-2

@dazzyweb, thanks for the ideas. I am hesitant to approach the issue in this fashion. I feel it will produce some layer of complexity (text output formatting) to achieve something that can already be achieved out of the box with the current Blog. If there is to be any 'complexity', that should be left to the dev (e.g. the $options in renderPosts()) rather than to everyday editors using the GUI to post articles. Like I stated earlier, the featured image, post-headline visibility, etc features are easily achievable via using the $options in renderPosts(). Maybe once I have posted the working code you'll see how much easier it is to achieve the layout you want. Alternatively, there is also the option of using HannaCode to output code where you want. I will also make it possible to toggle the visibility of post-by-line, post-categories and post-tags in the code I am working on. The unresolved issue is the social media buttons but we'll get to that eventually. Cheers

@Chris, thanks for reporting back and @Adrian for resolving this. Although I was sure this anomaly was not coming from Blog, it is good to get a confirmation

The problem with a module like this is that it is unlike WP with its many themes which have different layouts .. For #1: I think you can easily pull that off with CSS. What I will need to add however, is the option to also output a featured image for a full single post [blog-post.php] (currently I have implemented this for $small posts only). Same as the current implementation, one will have the choice for that to be output either above the post-headline or below the post-body. In your case you'd probably go for 'above' post-headline and using CSS you can place your headline on top of the featured image. I'll try show you example CSS on how to do it... For #2: I will need to think about how those can be implemented (forum any/all ideas welcome, thanks!). I think it is an important feature. This will probably have to be implemented on the GUI side. It will have to be configurable, i.e. what social media sites to show, their icons, etc...This feature may have to wait for a while though...I want to get it right... Thanks for the ideas.

@dazzyweb, I don't follow: Are you talking about a full post as output e.g. in blog-post.php or are you talking about summary of posts, e.g. on blog-posts.php? If the latter, I have already implemented that as per your request yesterday. What is a featured banner photo in this case? Where is it coming from? Can you show me some examples/illustrations please? Without jQuery or similar you can't at the moment. Again, are you talking truncated ($small) posts or full posts or full listed posts (e.g. on blog.php)? I'd like to see some illustrations/examples though...

@toothpaste, Yes, it is technically possible to call items twice but wholly unnecessary . Btw, if you did that, there is no need to call $modules->get('MarkupBlog') twice. Calling it once is enough on the same template file. Anyway, back to the issue. You can easily achieve what you asked - having two posts (or 3 or 10 or whatever) side by side by just using CSS. All blog posts are wrapped in divs as follows: <div class="posts"> <div class="post">Post number 1</div> <div class="post">Post number 2</div> <div class="post">Post number 3</div><!-- etc, etc. --> </div><!-- end parent div.posts--> What you want to do is to target the div.post with CSS to make them float side by side. Now, directly targeting div.post in your CSS may obviously affect other instances of div.post elsewhere (e.g. in blog-post). So, what you want to do is probably to wrap div.posts in your custom div like so: <div id="wrapper"> <div class="posts"> <div class="post">Post number 1</div> <div class="post">Post number 2</div> </div><!-- end parent div.posts--> </div><!-- end parent div#wrapper--> You can then easily target each div.post with your CSS.

I always use this 'trick'

There is the Schedule Pages module....for auto-expiring...but not moving... ...but you can achieve that with a simple module/hook. But Date Archiver looks like it will do what you want...

OK, I have had a rethink in respect of the second request here (post-by line below post body) and the first issue here... . Similar to renderComments() where you can customise comments' visibility status texts, I am working on making the currently hard-coded 'posted by', 'posts 1 to 1 of 20', 'view more', etc (including their visibility and position where applicable) customisable. The 3rd argument of renderPosts() will now be Array $options and will cater for various aspects of the rendered post. If you have any requests please post them here and I will consider them, thanks.

Upcoming Update: Blog version 2.1.1 (dev) Update as per request to allow user to control position of featured image - either above post-headline or below post-body. Default is, if present, output featured image below post-body. To output a featured image above the post-headline, include the 'key'=>'value' pair 'position'=>'above' in the $featuredImage options array, .e.g. $featured = array('tag'=>'thumb', 'width'=>550, 'position'=>'above'); echo $blog->renderPosts("limit=5", true, $featured); For new readers, also refer to the original Blog 2.1.0 post above. Feature available in the dev branch for testing, thanks. Screenshot

Yes ; isn't that what this module is already doing? No ......Here's why... {also see the G thing...}

@Chris, Sorry about your troubles. This is very strange. It has not been reported before nor have I experienced it. Blog does not touch your PW 'user' credentials at all. Please clarify a few things: Can you confirm what version of Blog you are running? It may sound silly, but confirm when you are trying to log back in, are you using your username or Blog's display name? Do you get any error messages when you try to log back in? What are those messages? Are you logging back in as an Admin?

What happened to the screens in the first post?

Featured image above post-headline I'll mull over this one but can probably add a position=>above//below in $featuredImage options. Just to be sure, you mean something like this or this or this yes? post-byline below the post-body This one I am not sure about whether I want to change the current behaviour..

Cool insight @sforsman...

Ye...just finished grepping it...

I'd be interested to benchmark that as well. But, behind the scenes, also wondering if PW runs a foreach for removeAll();

The automation could start right from here...detecting when a user edits an advert: But I don't know what sort of traffic you will on the site, whether these users are editors, etc...

@Gebeer, Thanks for elaborating. Just wondering, step #6, is not possible to automate the manual deletion of previously saved timestamps? Or maybe it's not a big deal for you?

Yes, exactly...PagePath History does help; Antti sings about it all the time IIRC

Er, Google indexing, SEO and all that....

Upcoming update: Blog version 2.1.0. (dev) Summary of Changes: Added 'Small' Posts Featured Image setting EDIT: Note that the implementation of this feature has slightly changed. See this update: --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- As requested, Blog version 2.1.0 now includes a 'featured image' setting that can optionally be used when displaying a summary of posts (i.e. small/summarised/truncated posts). I haved added this to the dev branch for testing and comments, thanks. It is implemented by including a third argument/parameter to renderPosts(),i.e. renderPosts($posts, $small = false, Array $featuredImage = null) Only if $small = true and $featuredImage is also specified, does the setting kick in. $featuredImage must be an array of options to apply to the featured image as described below: First, renderPosts() will look for the first image with the default or specified tag (see below) in the post's blog_images field If no image found, it will then look for the first image embedded in blog_body (i.e. the body of the post). Here it uses PHP's DOMDocument class. if we find an image, we output it in ,<div class=post-body> just before the truncated post text (see screens below). The image is given the class <img class='post-small-featured-image'> If no image found, nothing is output and we move to the next post...etc... The above means that you can mix and match where your featured image will come from... The default image options are: //default featured image options $defaultOptions = array( 'width' => '',//no width manipulation if this blank 'height' => '',//no height manipulation if this blank. Note, if size is true and both width and height > 0, use size() instead 'alt' => 'description',//defaults to $image->description. Otherwise other stated field on the page, e.g. = 'title' 'tag' => $this->_('featured'),//string: image tag to look for in blog_images //size: image will be resized to exact dimensions -> $img = $image->size($x, $y) //where $x = 'width' and $y = 'height' 'size' => false,//if 'size' = true AND both width and height > 0, this kicks in ); Above are self-explanatory but let me clarify a few things regarding the order of implementation. You don't have to specify any/all options if you are happy with the defaults, so you can do... //render a limited number of summarised posts + show featured image $featured = array('tag'=>'thumb', 'width'=>350, 'alt'=>'title'); $content = $blog->renderPosts("limit=5", true, $featured); echo $content; For featured blog_images In descending order, the order of image dimension manipulations for a featured image coming from blog_images as set in your $featuredImage options will be processed as follows (note: only one manipulation takes place! i.e., if, elseif, else...) (see what these mean in the Images docs) size = true AND width > 0 AND height > 0: $thumb = $image->size($x, $y);//where $x=stated width and $y=stated height width > 0: $thumb = $image->width($x);//where $x=stated width height > 0: $thumb = $image->height($y);//where $y=stated height No height AND no width stated: $thumb = $image;/i.e. original image output at original dimensions Also: alt: defaults to '$image->description'. If anything else is specified, then alt = $page->field where field is the given value in alt. e.g. if 'alt'=>'title', alt=$post->title tag: defaults to 'featured' but will take any string you specify in 'tag'=>'mytag'. For embedded images These are not subject to ProcessWire image methods. So there are no width, height manipulations If height and/or width > 0 is specified in $featuredImage options, these will be output in the img tag. In both cases, of course, you can still use CSS to control image dimensions and position. Some examples If you pass the following options to $featured in renderPosts("limit=5", true, $featured); /*will get first blog_images with tag='thumb'. Image width will be resized to 350, height proportionately calculated and post->title will be alt (i.e., post page's title). No size() applied since not specified so also height ignored. So no need to specify it here!*/ $featured = array('tag'=>'thumb', 'height' => 300, 'width'=>350, 'alt'=>'title'); /*same as above except image height resized to 300 and width auto calculated*/ $featured = array('tag'=>'thumb', 'height' => 300, 'alt'=>'title'); /*$image->size($x, $y) applied*/ $featured = array('tag'=>'thumb', size=>true, 'height' => 300, 'width'=>350, 'alt'=>'title'); /*no manipulations; original image output since no height and width specified with size. alt=$post->caption. So no need to specify size here!*/ $featured = array('tag'=>'thumb', size=>true, 'alt'=>'caption'); /*output first embedded image giving it height and width dimensions - In this case will only work if blog_images does not contain an image tagged 'featured'*/ $featured = array('height' => 300, 'width'=>350, 'alt'=>'title'); /*output first embedded image. In this case, doesn't matter if you tagged your blog_images or not*/ $featured = array('tag' => ''); Note: If you will be using blog_images to hold your featured image, you will have to enable use 'tags' in the field's settings (Detail's tab). I have decided not to enable this setting by default when Blog is installed since 'featured image' is an optional thing. This will not work with images embedded using Hanna Code since such will be output when page is rendered. To make things as light as possible, DOMDocument above looks in the blog_body html string retrieved from the database. If anybody has other thoughts please let me know, thanks. I will update Blog docs when this is committed to master. Thanks for testing. Screens (with custom CSS styles applied to img.post-small-featured-image) Float left Float right Top, no float

@Dazzyweb, Thanks for reminding me about this. Actually the feature had previously been requested by Adrian but I never got round to it . I was not sure how best to implement it but taking up your renderPosts() suggestion and coupled with Adrian's ideas, I have now come up with a workable solution. I will post an updated Blog version in its GitHub dev branch in the next couple of hours for testing, suggestions, etc.