kongondo

@toothpaste, until I update the Blog docs, it's all here in post #207. What you want is to pass 'post_categories_text' as part of an array (e.g. $options) as the third argument in renderPosts(). Here's a quick one line example - you would probably do it differently depending on your needs, e.g. create the array with all your options first then pass it to renderPosts(). We replace 'Categories: ' with 'Groups: ' echo $modules->get('MarkupBlog')->renderPosts($pages->get('/blog/posts/material-design/'), '', array('post_categories_text'=>'Groups: '));

Sorry for wasting your time!!! Triple facepalm!!!! Agghhhhhhhhhhhh!!!! Bitten once again!!!! I am going to hide under a rock and will not come out soon. ABP - guilty again! Your module works a treat! See example below, working together with Blog Module. Will post example code later in Blog thread...Thanks!

I am testing on a template with hardly any CSS at all. For good measure, I even deleted the CSS with the same results. Below is my output. See the greyed out output for the Social Shares below after email. Yes, email has no 'popup' class.

Thanks for this Soma. For some reason apart from the 'email', all the other social shares are hidden. The <ul><li> is output but the inner <a> and <i> are hidden, e.g. <i class="icon-twitter">twitter</i> is hidden (CSS). 'Twitter', 'facebook', etc are not shown. Same thing happens if I use icons. The <svg> are hidden. What am I missing?

Is the service down? My installs are stuck at 'Deploying Your Site'. Nothing happens, no process bar, nothing. This has been happening for 3 days now.

Not sure you have seen this in Hanna Code's PHP usage notes? Hence $page->template refers to your blog post template whereas wire('page')->template refers to your summary page template.

In that case, there seem to be a number of other options. In PW 2.5.? (can't remember version) you can export and import fields. https://processwire.com/blog/posts/august-2014-core-updates-1/ Maybe even Adrian's migrator can help here? Not sure, would need to confirm

I am a bit confused why you would want to add the fields via the API? If a client wanted a new functionality that required adding new fields, why not just log in as admin and add the fields? Anyway, adding fields of course implies not only creating them but adding them to a template. Adding fields to a template is a two step process. In the first instance, you create a fieldgroup and add fields to it. You then add the fieldgroup to a template. In your case, you would be adding to an existing template so you may not need to create the fieldgroup, rather to 'get' it. If you are not afraid of looking at code, have a look at BlogInstallWizard.php (part of the Blog module). There's examples for adding different types of fields as well as adding to an existing template. At the moment we don't have a dedicated resource that lists the properties of each field type. There are nuggets of knowledge here and there in the forums. My favourite (though probably incomplete and outdated for now) is the APIGen for PW. http://processwire.com/apigen/namespace-None.html. On my local setup, I generate apigen docs based on the latest PW and pulling not only .php files but also .module files. Btw, as part of my upcoming 'ProcessWire Modules' tutorials, I will be writing about this...

Last I checked Atom did not support PHP - a big turn off for me!

Have you gone through this? https://processwire.com/docs/tutorials/troubleshooting-guide/

You need to 'read' MarkupBlog code . Search for rtrim to see an example.. rtrim() http://php.net/manual/en/function.rtrim.php

Hey Jan, cool 'experiment'! Even if this may become obsolete soon, I think it will be a useful learning tool for some of us and a nice toy to play with - so a great addition, thanks!

Yep, I agree with Joss here. If you wanted to manipulate the value at runtime, here's an example based on Joss PHP date thingy... $myDate = date('F Y', $pages->get(5108)->getUnformatted('blog_date')); echo $myDate; //Outputs August 2014, for example.

Why do you think the conversation wouldn't be seen? Module developers follow the support forums of their modules and are notified of new posts If we were to open new topics just because some threads were 'long' things could become chaotic and confusing very quickly. This forum is Hanna Code's support forum. You have raised a Hanna Code support question hence it should be here . To further clarify...(not just for you): Each module has (should have) its own support forum. these are found here: https://processwire.com/talk/forum/4-modulesplugins/ If one wants to discuss general module development they should post them in this sub-forum: https://processwire.com/talk/forum/19-moduleplugin-development/ I hope these clarify things.

That's still a strange path. Blog files should be in /site/modules/ProcessBlog/. E.g. /site/modules/ProcessBlog/ProcessBlog.module. Did you create the 'Blog' folder yourself?

Btw, Peter, what is your use case? Do you have a page that will list all tags used across your Blog? If that is the case, then you should be doing this a little bit differently...

Seem we posted near same time..See my response above yours

blog_tags is also a PageArray. You would have to loop through it as well. Something like below. However, note, the below will produce duplicates since tags are reusable across multiple posts...If you need unique values just holla and we'll sort that out for ya.. $mytags = $pages->find("template=blog-post");//All pages based on blog-post template foreach($mytags as $taglet){ //blog_tags return a PageArray so we loop through them as well //I don't think this is exactly what you want because this will output all tags used, i.e. there will be duplicates foreach ($taglet->blog_tags as $t) { echo "Tags:{$t->title}"; } }

@Peter, Since an upgrade doesn't reinstall the module, any custom fields or pages you add post-install should survive.

Updated Blog (master/modules directory) to version 2.3.0. See post #244 above for explanation of changes.

@Russell - I don't completely follow. Running the module in a sub-directory doesn't seem like a good idea. Delete the sub-directory one. Then update the one in your /site/modules/ directory. If you can wait a few minutes I will be merging the dev and master branches. This way, you can update as normal. If you can't wait, you can also just copy and paste all the latest module files (minus the template files, of course) and paste this in your /site/modules/ProcessBlog/ directory overwriting the older ones. Btw, note that PW now saves an older copy of your module directory when you update a module (don't know if this only happens when you update from URL or uploading a file in contrast to updating via PW's modules' directory. So, you might see a folder .ProcessBlog - that is a backup of older files when you update. Edit Realised I didn't answer you question about deleting Blog Pages. As I had mentioned in a previous post and now updated README to include this (thanks...)

Do you want to mark this as solved then?

Nice site Joss! (Cheap MOT too...sadly not in my neck of the woods )

OK, so not part of the Blog module then...

What was the name of the image field?