Adam Kiss

It depends, I read it as follows: $.each(files, function(i, file){ var urlToFile = $(config.InputfieldACE.dropTarget).pushFile(file); }); But looking at the code, it seems that you may be thinking about moving the HTML5 upload stuff into it's own module (or JS object)

Ding ding ding bingo! We have a winner. Follow my thoughts here: I thought, that the user of ACE Editor sets field in the config he wants to use for images (when dropped on ACE), thus it makes sense that it would be simplest if the InputfieldFile had accessible interface (since it handles upload, etc. already). The code you've provided is exactly what I hope for - with this, I'd only send the urlToFile to ACE Editor and be done. I'm going minimal - I need only the start/stop events (jQuery.trigger with custom event seems to be great for this), but I imagine people are capable of coming up with weird stuff, so if you open up this interface to access from other modules, progress might be great, you know.

https://github.com/adamkiss/InputfieldAceEditor/blob/image-upload/_coffee/modules/editor.coffee#L50 and the last two functions are helpers

Edit: or do you mean code?

Interesting… I don't have much to say here, except 'Drumlapress' is gold.

Rewriting this issue from Github, Inputfield[File/Image] fields have a HTML5/JS upload funcionality. Currently, the functions handling the upload and addition to field, etc. seem really baked in the rest of the JS the field uses for other purposes. I'd really like them to have some sort of interface, so we could possibly peruse this fields - as shown in this video. Right now, I use all sorts of hacks to get correct data (and they might be even not correct), so there could possibly be some API like interface to: push a file to upload (and get a filename back - i currently had to duplicate/hack in page name cleaning function) have the field trigger some events on $(document) [or $(window)], like 'upload started', 'upload finished' have those events somehow put together with the real filename the field uses That's just from the top of my head. Ryan seems to not understand me (waiting for the a-ha moment), so I'm posting this here in hopes @apeisa will) Adam

Bah, I somehow overlooked that part. sorry

Well the rule of thumb is that if you're doing anything consisting of simple manipulation of tree (like getting X children of a parent Y), it should not be more than ten lines, otherwise you're solving the problem the wrong way. And yes, there are multiple things people usually go at the wrong way with PW. and yes, I just pulled the number ten out of my… anyway. Note: and by wrong way, I mean "doing it the hard way you'd do it in other CMS"

I would be superhappy if there was possible to group multiple cache parts You'd have something like: nav.top.cache1 nav.top.cache2 nav.two.cache1 nav.two.cache2 And then you could delete nav.two.* and it would remove all related parts (in my example it's 3 and 4). That would be awesome.

Before After

1280x800… Also my bad! I didn't realize you can move the books around! Even though, I like simpler things , but as a contemporary/experimental solution - it's rather nice. And also, I must say I am in love with the font on the background (or root domain) - your work as well?

Changed. I must say I'm not really a fan of hunting tiny click areas, so I'm not the biggest fan of this either Re: PNGs from PS are always bloated, I've seen crushers make PNGs smaller by as much as 80%.

Oh darn, I really hoped there will be another opensourcecms storm, it's always so much fun to bash those guys.

I think that people spend entirely too much energy on optimizing URLs. It almost doesn't matter, after all - I feel that there is virtually no chance somebody will enter the URL manually (except the index page, maybe). My opinion is that multiple hierarchies = bad. Simple as that. But you have valid use-cases (or problems), so I can try to give you my opinion. [simpler URLs (for blogposts)] I see two options here: I'd either code the root page as a router of sorts (with rules given in case of collision), or didn't simplify the URL up to the root: domain/articles/this-is-article, or domain/topic/this-is-article, or even domain/a/this-is-article would work for me; I'd probably go with articles, because it's most logical - therefore articles will be both article router AND content holder. [simple URLs (eshops)] This is practically the same situtation [Different menus] If somebody wants to build menus manually (and I doubt that), then PW probably might not be ideal tool, but having some 'Custom-menu' tools page seems like a good solution here. And if you want your menus automatic, then I see no problem having millions of menus: if the menu is automatic, there must be a way to describe which content goes there, and then it's a simple problem of coming up with the right query. [Example: catalog] This is precisely the thing I'd build with one catalog and two router pages with using URL segments on (or, if it was simpler, just one 'router' page, and the other industry would have the 'real' tree), and possibly on module for generating the menus (again, there must be a way to tell the computer how you want the tree to be created and/or modified) Generally speaking, I think it's less about the hierarchy and more about the context; and there are almost always ways to give user more context other than multiple hierarchies. --- Edit: Reading through Antti's link, it seems that I echo Antti's and Ryan's opinion

Well, one business day guaranteed (and it's just a first response!), isn't anywhere close to same-day support. Even if you reported the bug first thing in the morning you are not guaranteed to have first reponse the same day. And this is true. Note: this is just from reading through the EE store

LOL

right…

What if the URL was real, as in this would be the tree in the PW: - 2012 - 12 - 22 - my bestest article You could actually create rather simple module to create your page on any given date (meaning: create any needed parent), and even move the articles between different dates, so you actually have adequate URLs. I think this kind of plays both sides: you get meaningful URL parts (as in 2012/, 2012/12/, …), you get simple moving from wordpress, and you keep your tree in sync with your URLs. Edit: this freakin' forum botched my [ code ] spacing, but I hope you get the idea

Whoa there, hold up! It was just my feeling from your conversation that 22 chars work everywhere. That however might not be true.

Avenir is 95, black

Sorry to enter this conversation (as I am no pro), but wouldn't it be simplest just to set it to 22 digits instead of 21, which seems to work everywhere? (I may not fully understand the conversation, though

Security through obscurity FTL --- Well, this makes sense if you have one way hole in system - for instance - you can inject SQL code via search field, but the site won't return results of said SQL, then this makes sense, right? (I do not advocate obscurity, I'm just curious)

Yeah, but technically you most often don't want to have the same aspect ration because of different content techniques you can use while being responsive: e.g. you may want to have mobile contact consist of map+address, or you can have map as large as one screen and address as another one. For instance

turn url segments on your category pages, and then something like this code (browser written, untested): <?php $post_name = $input->urlSegment(1); $post = $pages->get("/posts/{$post_name}"); if ($post->id) { // render post } else { throw new Wire404Exception(); }

Hey there, reading through the module (just briefly), it seems that this module uses preferred method of gmaps - drawing inside DIV (not sure if it's canvas or some div structure). Anyway, when we at Bonetics implemented this (http://bonetics.com/contact/), we've used one relative DIV as a wrapper, which had one 100%x100% absolute div child with id #google-maps (for example). Now, the div you draw the maps into is the absolute one, and you apply responsive resize to the relative one. Hope that helps.