adrian

On the field's input tab you can define a css file under "Custom Editor CSS File", although that option is only for Inline Mode, although that is what I tend to use most of the time these days anyways. Just quickly, this (http://ckeditor.com/forums/CKEditor-3.x/include-custom-css-ckeditor) might be relevant for regular mode.

Ivan - thanks for the feedback - glad it has made you so happy Without getting too far down the road on the resize on upload topic in this thread, does the "Max Image Dimensions" setting on the Input tab do what you need? The description explains it as: "Optionally enter the max width and/or height of uploaded images. If specified, images will be resized at upload time when they exceed either the max width or height. The resize is performed at upload time, and thus does not affect any images in the system, or images added via the API." If you need some different behavior that you don't think already exists, perhaps you could post something in the Wishlist board.

If I understand correctly, that is exactly what Batch Child Editor does. It has a new section under the Children tab where you can paste the names of the new child pages to be created. Check out the screenshots here: https://processwire.com/talk/topic/6102-batch-child-editor/

I have brought this up with Ryan already, so hopefully it is on his radar. Perhaps an issue on Github would be a good reminder for him though. This was my message to him:

It's tricky Take a read here: https://processwire.com/talk/topic/2867-small-change-to-inputfieldfilejs-to-facilitate-front-end-html5-uploads/

lisandi - take a look at: http://modules.processwire.com/modules/batch-child-editor/ It is not about CSV importing to create pages, but I think it does handle your needs for quickly creating child pages under a specific parent. It also allows modal editing of child pages which makes things much quicker also.

Ivan - take a look at the latest version for me - let me know if that works how you expect. It should work exactly as you requested.

I had forgotten about this post, but check out this new module - coming very soon https://processwire.com/talk/topic/7723-protecteddevelopment-mode/?p=78233 Based on the poll results, it will probably be released as a separate module, named ProtectPages or something along those lines.

You could hack the core to allow uppercase characters, but obviously this is not a good idea. Here is the function that handles this: https://github.com/ryancramerdesign/ProcessWire/blob/a8024bb49785370aa2e3867bd683094663cfeabf/wire/core/Pagefiles.php#L258 A little reading on this issue: https://processwire.com/talk/topic/7730-why-no-uppercase-or-special-characters-in-the-attached-files/

When you say the module supports capital letters in random strings I am assuming you were browsing the generateRandomString function? That was a bit of an oversight on my part. Even though that function generates the string to include capitals, the PW core does not allow capitals in filenames so they are converted automatically to lowercase. I should probably remove the capital letters from the $characters variable, but it really has no impact either way

ceberlin - it should be fixed in the latest version I just committed. Please let me know if it works as expected for you. Sorry for the delay.

@salles - unfortunately not, but I am curious how you are managing your image uploads with FTP - they won't be attached to a PW page, and so won't be accessible via the API. Please let us know your workflow - maybe there is something we can do to help. Ivan - I think it should currently work almost like that by just using img-{$page->path} - if there is more than one image uploaded, it should start appending -1 etc, the same as PW does natively. Is it critical for you to a predefined number of characters in the number suffix like in your example? If so, let me know - it shouldn't be a hard thing to implement.

Hi alekaj and welcome to the forums. I posted a bit of a hack to make this work: https://processwire.com/talk/topic/201-fieldtype-select-aka-drop-down/?p=45320 Hope that helps.

Hi ceberlin, Thanks for the report - sorry about this - I'll take a look when I am back at my desk in about 10 days. It might be obvious when I start looking into it, but could you please clarify what "admin backend of the frontpage here" is. What is the path in your browser address bar? Thanks.

ceberlin, Just so you know, the new enhanced version (with page specific, editor managed control) is not released just yet - I am on vacation for the next two weeks, but I plan on releasing when I am back. The login process is still handled by PW, so need to do any additional sanitizing/cleaning.

Not sure about actually dreaming, but definitely in that blurry time while falling asleep and then lying there after just waking up - brain seems more clear and tries to actually figure out the problem, rather than the trial and error approach that can sometimes happen when you're at the computer trying to get something to work.

I haven't tested, but from memory, I think this is what you need: $t = $templates->get('basic-page'); $f = $t->fieldgroup->getField('fieldname', true); echo $f->cropSettings;

Thanks vegardw for spotting this. Would you mind filing a bug report on Github please?

Hey charger - woke up with an obvious solution. I just committed an update that should take care of your needs. Now the temporary filename is: original-filename.upload.tmp.pdf Hope that works well for you. Thanks for letting me know about this.

Sorry now I understand - it's the writing of the description that is the problem - makes total sense I often use this module with images (so not an issue), and when I do it with PDFs and other files I haven't ever used $file->description so I haven't had this issue yet. The tricky thing about trying to fix this is that filename formats that use fields that aren't available at upload (like description) need to be renamed on save, but if you don't want the name to also change on each future file save (which you wouldn't given that you are including the date in the filename), the module needs to know it is the first time the file has been saved, which is why I use the tmp-filename intermediate renaming. Only files named tmp-filename get renamed on save. All others are ignored unless the "Rename on Save" option is checked. It's almost 2am here and this is not a simple fix, so I am sorry, but I think it will have to wait a couple of weeks, but I'll definitely put it on my list and I'll let you know when I have a solution.

Hi charger - sorry, I am not sure what the problem actually is. Because you have chosen to use $file->description the module has to use the tmp-filename option until the page is saved, when the description field is available. If you used $page-name or something else that is already available when the file is uploaded, it will rename fully as soon as it is uploaded. Maybe you have already figured that out though? Why do you need to know which file is which before you save the page? Once the page is saved the names will match the entered descriptions. Perhaps if you could explain your usage scenario I might be able to come up with a solution for you. I am on vacation for the next two weeks though, starting in a few hours, so I might not be able to do anything until then, unless a clear idea emerges and it is easy to implement. I guess I could go with renaming on page save, but that always seemed less elegant - shouldn't be too hard to make it an option though.

It seems like it might be server specific. I just tried again on my local dev setup and it works as I reported in my last post. But then I just tried via lightning.pw and it failed with the same message you are getting. I honestly don't know why though. Do you have another environment you might be able to test with?

You don't need to, but I think lists are more semantically correct in this case. I am sure someone with a little more time right now will have a more complete explanation for you.

Hey Max, You want the <ul> and </ul> outside the foreach and then use li inside: <li class="articlePost">

Good point! I will have a need for this early next year. If it hasn't been tackled, I'l look into it then.