kongondo

File could not be removed or module could not be removed? If file, then just delete it manually. If module, then you can remove it via phpMyAdmin or similar. Find the table called 'modules' in your ProcessWire database, then find the row with this module's class name, i.e .AllInOneMinify (check in the column class) and delete that row. You might want to first backup your db just in case

Thanks for this. It's probably good to also point out that Flickity may require the purchase of a license depending on the project.

@congomonster, thanks for catching that. Fixed; in dev branch for now. @all Please note that if you want the method MarkupBlog::formatDate() to output your comments date according to the date field in blog_comments, you just need to pass it a second parameter 2 (integer 2). For instance, in the template file 'blog-recent-comments.php', line #30, we had this: $date = $blog->formatDate($comment->created); ...but we now have this: $date = $blog->formatDate($comment->created, 2); Since the second parameter is give a value of 1 by default, this change should be backward compatible. Unless you want the updated feature, you don't need to do anything in your template files.

This is what the PHP manual says:

#1: Not normal. PW version? If you ugraded using PW, it should have renamed the older folder as .ProcessBlog or similar #3: A PW date field has two parts. The output and input formats. Have a look at both (input is in the input tab). In the Details tab (Date/Time Output Format Code), you can use your strftime code: am %A, den %d.%m.%Y. You will see that date in the frontend (in your post) In the Input tab (Date/Time Input Formats -> Date Input Format Code) I think you can only use PHP date. So, something like l, d.m.Y in the date input format code will give you Thursday, 11.08.2016. You will see that when editing your post in the backend. You will not be able to uses 'den' with PHP date

Hi Zen Welcome to the forums. Since this is a public forum, it is probably not a good idea to share your phone number. Secondly, you are unlikely to get many replies as people typically respond better if you supplied an email address or requested them to PM you for further details. In addition, this is an international community and the phone number you've provided doesn't specify an international dialling code. In case you haven't seen it already, please have a look at this board's posting guidelines for some helpful hints.

Have a read here: https://processwire.com/api/modules/multi-site-support/ I am using option #1 (core) successfully both with domains and sub-domains. Same database is option #2

@justb3a is right. Double facepalm on my part! Even after asking whether your page field was single or multi, I forgot to check in my case that the setting @justb3a refers to was correctly set in my tests...OK, time for my evening tea

There was a typo in my code. I have corrected it. See my example again. Repeaters work just fine with page fields

No need for that get again. $s is already an object...just foreach it and output its properties...This works (in my tests) $page->banners here is the repeater field. And you have to foreach, if the page field is multi foreach ($page->banners as $banner){ foreach ($banner->page_field_name as $b) {// page field in repeater is 'page_field_name' echo "<div class='" . $b->title . "'>"; echo "<p>" . $b->keyword . "</p></div>"; } } $s->color is actually not an id ...That's just the toString() method kicking in. It is an object

Hmm, is this relevant? https://processwire.com/talk/topic/8962-selectable-pages-defined-dynamically-for-page-field-in-repeater/

Is the page field single or multi? If multi then you need to loop through the $s as well

He's addressed that in the (new) official release thread found here @horst, maybe we should now lock this topic and direct discussion to the new thread?

Hi @jannisl, Welcome to the forums. Glad you find the module useful. Currently, that can't be done. There has been a similar request recently and am currently thinking how best to implement this. My current thinking is to allow such functionality both in the backend (Menu Builder GUI) and within template files using the API. In the backend, all extra attributes for each menu item could be entered in one text box (each item having its own text box for this similar to CSS classes) in comma-separated key=value pairs, e.g. In the frontend (template file) such extra attributes would be added universally by passing them as options, e.g. $options = array ( 'wrapper_list_type' => 'ul',// ul, ol, nav, div, etc. 'wrapper_list_type_attributes' => 'role=menu',// comma-separated key=value pairs 'list_type' => 'li', 'list_type_attributes' => 'role=button, onclick=return false',// comma-separated key=value pairs 'submenu_attributes' => 'role=banner',// applied to submenu wrapper element; comma-separated key=value pairs ); As per my example, the extra attributes would be applied to all elements specified in *_type + submenu (usually inner <ul>). By default these will only be applied if specified by developer/designer. The differences between specifying attributes in the backend vs frontend (API) Finer-grained control in the backend; apply extra attributes selectively (only on required menu items) Universal attributes application only possible in the frontend Application of attributes to menu and submenu wrappers only possible in the frontend What do you guys think? Would this work for you?

http://processwire.com/api/selectors/#access_control

Welcome to the forums @magnusbonnevier Thanks for the tutorial

Just like I've shown you in the example above . No need to do merges and such. See below (including the comments in the code); hope this is now clearer. $paginationOptions = array( 'nextItemLabel' => "Forth", 'previousItemLabel' => "Back", 'listMarkup' => "<ul class='MarkupPagerNav Zurb pagination'>{out}</ul>", 'itemMarkup' => "<li class='{class} not necessary class'>{out}</li>", 'numPageLinks' => 5 ); $defaultOptions = array( // array of MarkupPagerNav options // you have to use the index 'post_pagination' and its value MUST be an array // here, we've passed it the array $paginationOptions that we created above 'post_pagination' => $paginationOptions,// the value here must be an array; the index must be named 'post_pagination' // other stuff you already had in your defaultOptions 'post_more_text' => 'mehr', 'post_whatever_option_1' => 'blah blah blah', 'post_whatever_option_2' => 'foo bar', ); $content .= $blog->renderPosts("limit=5", true, $defaultOptions);

@Tom...404 returned at the link you've provided

I am too lazy to type code... Have a look at the examples found here (second example there has 6 random images being returned) https://processwire.com/talk/topic/328-grabbing-a-random-image/

Update: Version 2.3.7 Following this question, it is now possible to pass MarkupPagerNav options to renderPosts() if you wish to customise your posts' pagination. All the MarkupPagerNav options listed here can be passed as an array within an array to renderPosts() as shown in the example below: $blog = $modules->get("MarkupBlog"); $paginationOptions = array( 'nextItemLabel' => "Forth", 'previousItemLabel' => "Back", 'listMarkup' => "<ul class='MarkupPagerNav Zurb pagination'>{out}</ul>", 'itemMarkup' => "<li class='{class} not necessary class'>{out}</li>", 'numPageLinks' => 5 ); $options = array( 'post_pagination' => $paginationOptions,// array of markup pager nav options 'post_count_text' =>'Article',// other posts options passed as normal ); echo $blog->renderPosts("limit=5", true, $options);

@congomonster, I suppose you are using the pagination that comes with renderPosts(), which is actually coming from the module @LostKobrakai has mentioned. I've added an option in renderPosts() that will accept an array of options to pass on to MarkupPagerNav. Will post an update within the hour

Two things: You never need to change the code in the module itself! Otherwise, your changes would be overwritten with upgrades You don't need this code to be like this: $renderComments = $blogConfigs['commentsUse'] == 1 ? $blog->renderComments($page->blog_comments, 0, $options) : ''; If you read the comments in the demo blog-post.php template file, it says The blog demo could not know in advance whether you or anybody else was going to install Blog with the comments feature enabled/disabled. Hence, it had to make that check by looking into the module configs ($blogConfigs). In your case , you know if you installed blog with the comments feature or not, so no need to make such a check. Hence, use the other code I provided instead, i.e. $options = array( 'comments_post_text' => 'My Text for Post-a-Comment', 'comments_list_empty' => 'Nobody has dared to comment on this article...yet', 'comments_empty' => 'Are you sure you want to be the first to comment?' ); $blog = $modules->get("MarkupBlog"); // Here, no need to check if blog was installed with comments feature; you should know - you installed it yourself $renderComments = $blog->renderComments($page->blog_comments, 0, $options);

I also don't get the 'template file' is needed bit. I couldn't find where that behaviour is defined. If possible, I would want that not to be necessary.

I had to hit the 'refresh' button a couple of times for changes to show up (rather than uninstalling )

Thanks. Will appreciate your professional opinion especially regarding the client-side-image resizing