kongondo

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.

You can still use your rich text editor, weaving in and out of source code mode... https://processwire.com/talk/topic/4187-formatting-a-code-block/. See posts about pbckcode plugin.

Hermoso!

Nice! This was a learning experience for me too . Would love to see the final code/implementation (if possible). Or is it the one above?

Yes. That and Fancybox (I don't think it has been retired yet). Disregard my comment. I misread the question

Aren't you able to use PW's inbuilt modal?

Actually if you look at the code in Timestamp.php, lines 40-47, that is where the conversation from string to integer happens so you don't have to do this in your foreach; Providing a date string is enough . if($key == 'date') { // convert date string to unix timestamp if($value && !ctype_digit("$value")) $value = strtotime($value); // sanitized date value is always an integer $value = (int) $value; } See also the comment in FieldtypeTimestamps.module lines 140-1 Also never got the errors you were getting. But I suppose your implementation of the code is different so I may be way off here... Btw, about your earlier questions on how stuff was getting deleted in the backend? The module is using trackChanges. You can read more here about the method. Edit: Aaah, I think I now see why you were getting that PHP notice. As pointed out in the SO link you gave, date() expects the second parameter to be an integer. In the case of InputfieldTimestamps.module, it's getting its values from the database. Those values were already saved as integers so no need for strtotime at that point. In your case, your values are coming from your frontend form as strings so they needed to be parsed into timestamps. At least I think this is what was happening. Anyway, you sorted it out but just thought to clarify this. Or maybe, I am not getting what's going on....I am having one of those slow days...again...sigh...

Actually FieldtypeComments already has built in support for Gravatar. Never tried it though and don't know how to use it. I have looked at the code but can't figure this out. I also don't have a Gravatar account so can't test anyway. Anybody knows how to use this and willing to help us out with this? Hopefully Ryan will also see this. Thanks.

Not a direct response to your question but I have never liked the PHP short tags (just a matter of preference). Even on personal sites where I am sure short tags feature is enabled, I never use them. I don't think there is a general consensus about their use (or not) in modules but I would urge all module developers to stay clear of them just to ensure compatibility..

ProcessWire should have detected and given you a message about deleting the old one in your sites folder. Did you see those instructions on updating PW to 2.5? You are better off uninstalling your 'old' CKEditor (the one in your /site/modules/). The one in wire (the default that now ships with PW) will work just fine.

Looking at PocketGrid's styles, I see no code that is doing what you describe. Are you sure this is not coming from your other styles, directly or inherited? What is Chrome developer/Firebug telling you?

@Jordan, Some useful links: https://github.com/ryancramerdesign/ProcessHello http://wiki.processwire.com/index.php/Module_Creation http://processwire.com/api/modules/ https://processwire.com/talk/topic/741-a-guideline-for-module-naming/?p=6267 https://processwire.com/talk/topic/2394-how-to-present-your-module/ https://processwire.com/talk/topic/1313-modules-process-and-the-difference/

Jordan, I am not sure whether this would help: https://processwire.com/talk/topic/4647-best-hook-for-replacing-page-rendering/?p=45968 but I am failing to understand how a Process Module (modules that run in the backend/admin) has anything to do with something that will be rendered in the front-end (basically a page's template)...

Ah, I understood it in the English sense - low-level means basic and high-level means advanced. So 'deep inside the core system' means high . OK, I'll try get some time soon to expound on what I said in the post above yours

@RJay https://processwire.com/talk/topic/2387-the-structure-of-fields-and-templates/?p=22762

@LostKobrakai: I think you meant "the principle of having a table for each field is one of the ...."

Hi Charger, I thought you'd given up on this given your absence I'd started to work on something (it was actually working, i.e. dynamically adding rows and columns - except for saving to the DB) but then I hit a few snags and was wondering whether this wouldn't be best achieved by a dedicated ProcessModule or an extended PageTable....If you are about later, I could try and explain... ps: low-level or high-level??

@Gerhard, Note I am also new to Fieldtypes so, you may want to thoroughly test/validate, etc the attached. I have customised (mainly just commenting out stuff actually ) the FieldtypeEvents to only save timestamps (1 column table). As was native to FieldtypeEvents, each timestamp on a page is saved in its own row in the DB. Although I have also included the inputfield, you have several options: disable its page visibility in the template field visibility settings; disassociate it from the FieldtypeTimestamps Class and not install it or install it and use it to also have a visual view of the timestamps. You also get the nice jquery 'delete' or 'delete all' timestamps (events). If you don't want to install the Inputfield, you will also have to comment out/remove the method getInputfield() from FieldtypeTimestamps.module. Adding timestamps via API As shown here adding items to the Fieldtype via the API is quite easy (similar code exists in the the ___processInput() method in the InputfieldEvents (in the attached this is InputfieldTimestamps). $times = array('1521884800', '1721884800', '1571884800');//these can also be other valid PHP date/times, e.g. 20-10-2007 $page->of(false); foreach($times as $t) { $timestamp = new Timestamp();//this is the Class Timestamp found in Timestamp.php. Included via FieldtypeTimestamps. $timestamp->date = $t; // note stored in column 'data' in the db of the Field $page->timestamps->add($timestamp); } $page->save(); $page->of(true); To output timestamps using API foreach ($page->timestamps as $t) { echo "<p>Date: $t->date</p>"; } Finding items via API See Ryan's example here; I didn't check if it needs tweaking. Other things to note You can change the Inputfield to show timestamps rather than the date - InputfieldTimestamps.module lines #32-33 Currently the time format is hard coded as d-m-Y in Timestamp.php line #9 Left the commented out stuff in there...you can clean them out if all goes OK FieldTypeTimestamps.zip

Here's a couple of thoughts... https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/ https://processwire.com/talk/topic/5177-download-file-statistics/ https://processwire.com/talk/topic/1323-downloading-file-after-form-submission/ https://processwire.com/talk/topic/5292-proctecting-files-from-non-logged-in-users/