kongondo

You cannot upload images directly like that...See the message in the 'green' info bar. Add an image field to the template that page is using then add an image to it to be able to select it in the RTE. Alternatively, see the text below the 'green' info bar about uploading images from other pages...

Nope..you can call it anything you want (as long as it is a valid PHP variable name) - $b, $myBlog, $thoughts, $blahBlah.... RE comments, maybe paste your template code in pastebin and I'll have a look if I can find some time....

ProcessWire version?

@Pierre - I am moving this to Off Topic dev...

The 'keyword' to search for is PHP Object Oriented Programming (OOP). Find a good tutorial about OOP Classes, Objects, Methods (functions) and Properties (variables). A ProcessWire $page is an 'instance', i.e. and Object of the Class Page (see /wire/core/Page.php). In OOP, you can call/access the members of a Class (Methods and Properties) by 'creating' an instance/Object of that Class. When you use the variable $page, behind the scenes you are actually creating an instance of the class, i.e. $p = new Page(); You can create as many Objects of that Class as you want. The key here is that they will all be tracked differently by PHP - they are independent Objects of the same Class. So, in your case although your wire('pages')->get($pageid) were, from a database point of view, all grabbing the same page, from a OOP point of view, they were all different Objects, tracked differently, i.e. you were doing $x = new Page(), $y = new Page(), etc. Also, this should not work wire('pages')->get($pageid)->of(false); - since you need to get the page first (I could be wrong here) - and even if it did, it was a 'different' Object to the $page in the next line wire('pages')->get($pageid)->$pagefield->deleteAll(); So, in order to tell PHP that you were talking about a specific/single Object, we assign the $page we are after to the variable $p (behind the scenes $p = new Page(); - but not just any Page, but one with the id $p->id=1234 (from the wire('pages')->get(1234). Written late, I could have missed something but hope this makes sense....

You add images code does not look OK. If you had debug on you should get an error round about here I think. wire('pages')->get($pageid)->$pagefield->deleteAll(); Because of this: wire('pages')->get($pageid)->of(false); You only need to call the page you want once. Try this instead: $p = wire('pages')->get($pageid) $p->of(false); $p->$pagefield->deleteAll(); $p->$pagefield->add($path . $filename); // save page $p->save();//maybe even saving $pagefield only would work...rather than the whole page

No worries. Oh, and welcome to the forums....

This code will not work inside a function due to PHP variable scope. $path = $config->paths->root . 'site/assets/tmp/'; It should be like this. $path = wire('config')->paths->root . 'site/assets/tmp/'; Or even shorter... $path = wire('config')->paths->assets . 'tmp/'; If you develop with debug mode on, you will get useful feedback about where your code breaks. More tips here: https://processwire.com/talk/topic/3466-access-config-inside-function/ https://processwire.com/talk/topic/6365-how-to-use-selector-in-function/ Btw, in your 'outside function code' you are using the code below. Are you using thats in a class? Why the $this? $path = $this->config->paths->root . 'site/assets/tmp/';

Update: Blog Version 2.3.4 Blog now preserves all line breaks as paragraphs for posts created via ProcessBlog's quickpost, thanks to idea by @justb3a

Cool.... Wondering though, what if a page has 1000s of descendants? That find could choke up....

There's a number of posts here in the forums about restricting users to only be able to edit the pages they created... Here's some modules that you could look at/customise to help you get started http://modules.processwire.com/modules/custom-page-roles/ http://modules.processwire.com/modules/page-edit-per-user/

Then the problem is in your blog-tag and blog-category templates. You have two choices: Set up access to the pages using these templates, i.e. an individual 'tag' and 'category' respectively by setting up access in their respective parents' templates, i.e. 'blog-tags' and 'blog-categories' AND making sure the two child templates 'blog-tag' and 'blog-category' have No checked for their respective 'manage view and edit access for pages using this template?' setting. In that case, pages using 'blog-tag' and 'blog-category' will inherit their parents' access. Then, in 'blog-tags' and 'blog-categories' you will need to check for the role 'blog-author' View Pages, Edit Pages, Create Pages and Add Children. Alternatively: Set up access on the child templates themselves, i.e. in 'blog-tag' and 'blog-category' templates. In this case, in their parents' templates, 'blog-tags' and 'blog-categories' you would only need to add the access Add Children. In 'blog-tag' and 'blog-category' you would need to grant access to View Pages, Edit Pages and Create Pages. If the above don't work, there could be some access inheritance issues going on...Access issues are of course controlled by ProcessWire itself and not Blog

Have you given the role 'blog-author' the right site-level permissions? In ProcessWire access is controlled at both site- and template- levels. Admin > Access > Roles > blog-author. The permission page-edit is needed...

If it will be able to handle a URL field well, then maybe there is no need. On the other hand, since you already a internal links feature, maybe good to add an external one too...Anyway, its a 50/50 thing...so your call

Seems like my wish came true...even without formally requesting it I agree this is the way to go. Good job!

My bad...I get you now...

It is ready in the dev branch ...No its not.....at least not yet....see below

Yeah, this has been brought up before but wasn't really sure how to deal with it. Thanks for reminding me . For now, I have decided to convert and store the line breaks in 'quickpost' to paragraphs (instead of <br>) since I believe that is the intended action by the user when they use a line break in 'quickpost' to space out their text. Besides, that is what CKEditor is going to do when the full post is edited. Using nl2br will result in lots of <br> all of which CKEditor will wrap in one paragraph. But thanks to your idea, I am now using a pre_replace to do the job. It works fine. Committed to dev for now.

Yes, the export generates JSON. It's all documented here: https://processwire.com/blog/posts/august-2014-core-updates-1/ - Field export/import And here: https://processwire.com/blog/posts/august-2014-core-updates-3/#template-export-import - Template export/import and more here: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/?p=68899

Unless am mistaken, this is called overloading. In PHP, you can overload both properties and methods. http://php.net/manual/en/language.oop5.overloading.php http://phppot.com/php/overloading-in-php/

So you were able to post and approve comments on both? If so, then it must be a collision with some other code/module on your other site... Time to proceed with the troubleshooting... - the tedious bit! One by one, install the modules you have in your 'non-working' site in your new Master and Dev blank test sites....testing if comments work after each module install. What third party modules do you have, apart from Blog? It's probably an autoload module.

If you can set up a new local site (or online @ lightning.pw) running on the stable version of PW (-master) without any third party modules and test your comments code on that, we can begin to troubleshoot what's wrong. Do the same but with a separate -dev version install of PW and see if you still get errors. If you get errors in both, then the problem has to be your code. We can then dissect that...

I can confirm that behaviour. If you use a URL field outside ImageExtra (i.e. add it directly to the template) then it works as expected - the http:// is added for you. However, that behaviour does not seem to work if you pass the name of the URL field for use in ImageExtra. I don't know whether it is a limitation of URL fields or of ImageExtra. Try it and you will see - i.e. try adding the URL field directly to your template and enter www.google.com - the http:// will be added for you. I know that is not what you want (i.e. you want each image to have the URL link) but try it anyway to see what I mean.. I also noticed that ImageExtra does not use the label you give to your custom field (at least not when I tested with a URL field); instead it uses your field's name. In my testing mine was 'www'. It used that as a label and capitalised the first word making it 'Www' whilst ignoring my label 'Custom URL'. Btw: you didn't mention it but in your ImageExtra module configuration screen, did you enter the name of your URL field, i.e. Webseite in the 'otherField'? Which reminds me, I think I will make a suggestion to the module author to move those inputs to the fields Input (or details) tab. Otherwise, it means that every time one uses the module, it would pick up on the fields entered in otherField + the titleField, linkField, etc, meaning everything would be uniform for all instances of that field. In contrast, if those were added to the Inputs tab, then, they would be unique for each instance of the field...hope this makes sense...and it was a btw...

A loop is fine but I am confused. . Help me out here. What type of field is bildermitlink? Image or ImageExtra (FieldtypeImageExtra)? What is www? I thought you said you had a field called 'uurl'? Where did you add www/uurl? Directly to the template or to bildermitlink settings only (assuming this is an ImageExtra field)?

You need to refer to the URL field properly...i.e. $page->uurl - assuming you added it directly to the page. Or did you add it to ImageExtra field instead? In that case, assuming your image field is one that accepts one image max, then you need to access it as $page->image->uurl