kongondo

Welcome Ukyo! Thanks for the contribution!

Edited above code in my post to make it tighter...+ clarified some stuff...

I see two problems One, on this line, since this is within the foreach, everytime it gets a new record (page) - i.e. on each new loop, you are wiping out the previous value of $out...hence, in your last code, it will only output the last record having wiped out all previous ones. $out = "<div class='referenceTeaser post'>"; The second problem is with your first code; you are returning $out within the foreach. It should be outside the foreach. The idea is that you need to return what you want to finally output/use...So, we don't return anything too early... Try the below code, modified from your second code attempt. We first initialise $out outside the foreach...Subsequently, we concatenate it. In addition, it is not always a good idea to use the same variable name for different things. E.g., you already have $page = wire('page'); In your selector, I would use $children = ...blah blah. function renderReferenceList() { $out = '';//initialise the variable $out //$page = wire('page');//no need for this as well $pages = wire('pages'); //$page = $pages->get(1065); // Referenzen//no need for this here; combined below $children = $pages->get(1065)->children("limit=15, sort=-date");//changed variable name to $children foreach($children as $child) { $out .= "<div class='referenceTeaser post'>";//note the concatenation $out .= "<h3 class='articlehead'>{$child->headline}</h3>"; $out .= "<p>" . $child->summary . "<a href='{$child->url}'><i class='more'>Referenz ansehen</i></a></p>"; $out .= "</div>"; } return $out; }

If you are bootstrapping PW you cannot use $page...OK, I stop here; Horst was faster! Edit: To avoid magic quotes issues, you also want to use wire('input')->get rather than $_GET. http://processwire.com/api/variables/input/

Follow-up to my post above about the 'example template files': 1. If you decide to hide some widgets (say recent posts), the HTML is still showing up and reporting 'no posts found'. That's just an oversight on my part. 'Unavailable' widgets should not even output their HTML; 'no posts found' should mean exactly that. I'll try to fix this later, but it is not a high priority . 2. On a related issue, you will need to install and configure MarkupTwitterFeed in order to use the example 'Twitter Widget'. Update: I have updated the example Template File 'blog-recent-tweets.php'. The references to some fields were wrong . Also updated the README + First Post.

Steve, I am wondering if it is useful to also include the CHMOD values (777, etc)? Just thinking out loud... Very, very trivial request: Please change Ok to OK...

If you are using ProcessWire 2.4 (which I assume you are), all you probably need to copy over is the folder /wire/ (deleting/replacing the old /wire/ first). ProcessWire never touches your site's folders, i.e. /site/. In some upgrades, replacing the old index.php and .htaccess may be necessary. If this is required, it is specified in the upgrade process. If you only need to copy over /wire/, instead of replacing the old /wire/, you can just rename it to say, /wire-old/. This way, you can quickly test the old (2.4) and the new (2.5)....by renaming the respective folders. Note: only do this if you know what you are doing ....In addition, as much as upgrading PW is relatively safe and easy, always make a back-up of your database...(which you should be doing anyway regardless of upgrades...)

Thanks for clarifying. Fixed in the latest commit. I think the problem was that you have a page called widgets. The previous selector was looking for pages with a parent 'widgets'. Good catch! I have changed the selector to be more specific.

Update: After closing an edit modal (widgets, posts, tags, categories), the parent page now refreshes to reflect relevant changes (e.g. date, author, published status, etc)...

Nice one Steve!!

I have updated the author's posts' table to show both 'published' and 'pending' posts.

Hi all, Thanks for testing and comments. Template Files One thing I should have clarified. The included demo example template files are just that; a demo. They are not part of the 'blog' module. They are not meant to showcase any templating approach. They are intentionally verbose (e.g. similar markup repeated across all of them as opposed to, for example, using head.inc, footer.inc or some other approach e.g., main.php, etc.). The idea is that the user decides how to structure their blog, what CSS framework to use (or not to use), JS, etc. On the contrary, the template files are meant to showcase MarkupBlog. What you can do with its methods/functions. Yes, MarkupBlog generates some markup but these are necessary and minimal. Using wrapper DIVs etc, as shown in the example template files, you can structure your blog however you want to fit in your new/existing site. Even the CSS and JS are demos! . In a nutshell, MarkupBlog does not come with its own CSS and JS. What is included is just meant to give you an idea of how to use it . In due course, I will do a write-up of all the methods available in MarkupBlog and what they do. @Max.. As per above, it is not difficult to fit MarkupBlog into your existing site's structure. In fact, since it is a module, you can even call it wherever you wish, in whatever template files, even your existing ones. What I am saying is that you don't even have to use the example template files! You just need to know the parameters MarkupBlog methods expect and you are on your way. This may be a bit advanced for you at the moment, so you might want to instead edit the example files as much as you wish Role and Permission Note that Blog installs the role 'blog-author' and permission 'blog'. These are available to you to control access as you wish. They are not automatically applied to any user. With these, you can can control the finer details of your blog. Authors Currently, the 'authors' tab/view only shows the count of 'published' posts per author. I'll soon update this, probably with a two different columns; one showing count of 'published' and the other showing count of 'pending [unpublished]' posts for each author.

Thanks for testing totoff. I believe you are referring to these template files: blog-recent-comments; blog-recent-posts; and blog-recent-tweets. Yes, currently, the template files are not being used. I have been mulling whether to leave them as is for those who wish to directly render the contents of those template files. I'll think a bit more about this but it is likely I will remove the template files. Incidentally, the first 2 templates are quite similar; will probably merge them into one. Regarding your second issue, I haven't experienced that (see also video demo). Publishing a post using the 'posts' view, whether as unpublished or published, forces a reload of the page since a button is clicked. The 'posts' table below then shows the newly created post at the very top (selector sorting is by date descending). I think what you probably mean is that when you edit a post, the new post status is not reflected in the posts table. That is correct; this is because the editing happens in a modal (actually an iframe) that is not really aware of the 'page below it'. I will see if I can use jQuery to force a reload of the 'page below' [hope this makes sense! ;-)]

@Charles - you are too kind! Thanks. @all - updated the first post + README...

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

And...:?... ....it should be tags...and it works...

categoriesList() is a function. Look at the code of this function... /* CATEGORIES LIST This lists available categories */ function categoriesList(){ $categories = wire("pages")->find("parent=/categories/, template=TUT_news_index, sort=title"); $out =" "; foreach($categories as $category){ $out .="<li><a href='{$category->url}'>{$category->title}</a></li>"; } echo "<ul>$out</ul>"; } ...that should give you a hint....

Reviving this old topic.... For pages created in bulk using the API, many will have the same timestamp (e.g. batch create 1000 pages using the API); the only unique thing for such pages will be the ID. If I limit my selector to one template only, the ID then becomes a more reliable get selector to use with < or >. The assumption here is that since IDs are incremented, a greater ID denotes a later created time. In bulk page creation then, the timestamp is less reliable and will return the same result every time which is of no good use when creating next/prev links ...maybe I'm missing something?

It seems you unpublished the page? You are in the backend, one that only you can see, why does it matter to see a pretty URL? OK, what is happening is this. When 'viewing' a page like the one you've created in admin, what you are actually doing is editing it...hence the .../edit/?id=1006. If you want something like .../admin/settings/ what you need is to create a process module or use some other modules available for PW. I am inclined to think, though (apologies if I am wrong) that you are a newbie to PHP as well? I am hesitant to point you to advanced stuff until you at least learn the basics of PW

"process to assign....": This tells me you are assigning your 'settings' page the 'wrong' template. Do not assign it the admin template. 1. First create your own template (no need for a template file; just the template). Call that template, say 'settings'. 2. Add the fields you want to that template. 3. Go to Admin (I mean the page Admin in the page tree), create a new page under the 'admin' page. Call it 'settings', give it the template 'settings'....you are good to go.. .... Pages under admin can only be seen by the 'supersuser' - so, no worries that people with the wrong permissions will see it . In addition, as I stated, these pages cannot be directly accessed via the frontend + your page will not have a template file....(not that it matters since this is an 'admin' page). Have you read up on the docs about how PW works? If not, you might want to do that first

Hi Madalin, Welcome to ProcessWire and the forums! There are a number of ways to achieve this. If it is only a settings page, then you can create the page as a direct child of Admin. I don't know what you mean by "to show as tab with some functionality" but the page should show up as a menu item in Admin. You will need to have a template for that page, of course. Add as many fields as you want to that template that will be used by your "settings" page. You can then pull up data from that page using the PW API, in this case you would want to use $pages since pages in Admin cannot be accessed directly in the frontend (so no $page). To output your settings fields...example.. echo $pages->get(12345)->title//Here, 12345 is the ID of your settings page. You can also retrieve the page by its path or title or name... Have a read here http://processwire.com/api/variables/pages/ http://processwire.com/api/variables/page/

Or if you are lazy like me... This should work as well, I think... $session->redirect($page->child()->url); In some cases, can be a good idea to first check if page actually has children ... if($page->numChildren) $session->redirect($page->child()->url) Oh, and welcome to PW! Edited: corrected code, etc...

....nothing to see here, run along, ta ta...

Cool first post @carrdesigns! Welcome to the forums!