kongondo

For questions specific to MarkupLoadRSS, please ask them at the module's support board here.

This looks awesome @adrian, thanks! I've just a quick glance, could this do breakpoints and step-throughs as well or its more of a logger?

@jtborger, You are not wasting anyone's time. The fact of the matter is that overall, there is still a lot of room to improve ProcessWire's documentation and tutorials across a range of topics spanning both basic and advanced stuff. It is something we are aware of and are keen to improve. Part of the Road Map for 2016 is exactly that...'continued and greater focus on documentation and tutorials'. Of course this does not mean everything will be done and dusted by the end of play 2016 but there should be some positive advances nevertheless. Whilst there are some great examples in the forums regarding various uses of the ProcessWire API, those cannot and should not be considered as a long term solution in lieu of proper documentation. In the meantime though, they are a good place to start if you are searching for particular answers. Welcome back to the forums

And we are back... I now recall I have seen this error before (when I was playing around with enhancing the Comments Manager). Yeah, the error is not very intuitive. ProcessCommentsManager should at least catch the error and give a more informative message. What is happening is this. In line #92, Comments manager is calling a constant from the Comment Class. The Comment Class is not a module but a .php file. It is loaded/required_once in FieldtypeComments.module line #22. So, unless you at created at least one field of type Comments, you will get that error. That field does not have even have to be added to a template yet for this to work. If such a field is present, it calls FieldtypeComments.module which in turn loads the Comment.php class and everything is fine and dandy. So, long story short, first create a field of type Comments before attempting to load ProcessCommentsManager. I would also file a request on GitHub for @ryan to consider catching the above error and returning a more meaningful error message for supersusers.

Hi @_NameLess_, Not a great start, eh? Welcome to the forums. I am going to test in a minute but I have not seen this error before. It seems to me you installed the module on your own custom path? Is there a reason for that? i.e. you should let PW determine the path. Is this a local install or remote? I'll test and get back to you

Tony, You are looking in the wrong place. renderArchives() is only responsible for all archives (e.g. /blog/archives/) and year archives (e.g. /blog/archives/2015/). For month archives (e.g. /blog/archives/1/) it is all about renderPosts(). Have a look at line # 33 in blog-archives.php. Just before that is where you need to pass your options. I am assuming you are using the blog-archives.php demo template file that ships with Blog. $options = array('post_count' => 0, 'post_comments' => 0, 'post_author' => 0); $content .= $blog->renderPosts($posts, true, $options);

@kixe, Thanks for pointing these out in advance. I am not being naughty but as you can tell from here, Blog is only compatible with ProcessWire 2.4 - 2.7 . I have been so busy I haven't even had a chance to install, let alone play with ProcessWire 3.X. So for now, I am not able to support Blog for that version of ProcessWire, but I do appreciate people catching such bugs in advance (although, PW 3.X is still an evolving beast)

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