apeisa

Ryan: thanks for your clarification. What I meant to say "saves values to db" => "process their own input". I first somehow thought that inputfield handles that (since schema and db saving etc are there), but of course not - inputfield cannot know how fieldtype collects data. When I found ___processInput -method from InputfieldFile then I understood (at least something)

Ryan thanks! Now get back to your holidays man! slkwrm: Thanks, glad you tried it and all worked. I was thinking about pagination and might do that at some point, but for my current needs (one personal project where I need this) this works very well now (takes max 100 images and loads them asynchronously). As what coding took. PHP code required very little time, and that was super easy. I had working "load image from url" module in under 2 hours. And this was my first inputfield, so took some time to look and learn how these work. Before this I spend also little time to understand what inputfield does compared to fieldtype (I somehow first thought that fieldtype saves values to db process their own input (see ryan's clarification), but it is inputfield what does that). Then JS coding.. it was little bit harder. I have done some ajax coding and used few JSONP APIs before, but this one was little harder beast than earlier ones I have done. I thought this one would be one ajax call, and looping through results, but it required a little bit more... Flickr has nice API (especially the documentation), but I had to create 3 different calls - and as they are asynchronous - it took a lot of trial and error to get all working. First call to get image ID:s, then loop images and from inside that loop 2 more calls for each images separately (one for image sizes and another one for details like description & author - the latter is not yet done btw). Right after all information for one image is found => draw image. Probably never done anything that complicated with js/ajax before (still learning the basics), but it ended up pretty well (the actual code is not probably very nice, but at least it works ). I didn't find any tutorial that would worked for me, so I made a lot of mistakes first. That took probably one full work day (7,5 hours - not sure since I developed at the night time few hours at time). And probably finishing this takes few more hours - so probably something like total 2 days of work. But what is important here is that most of the time this took was me reading and learning javascript. Nothing to do with Processwire - that part was super quick.

It doesn't matter if it is square or rectangle. Rectangle has also a center point (sorry, don't know the actual terms here). <?php $thumb = $page->image->size(200, 100); //width: 200px, height: 100px

Hmm.. This got me thinking. What we would need for API usage is not cropping, but just to set the point where to center the cropping. So if you have image of person's head, you could click between person's eyes so there wouldn't be any cropped heads. For RTE-use I think just any working cropping tool would do, but I am not that interested about that

I released my InputfieldFlickr module: http://processwire.com/talk/index.php/topic,382.0.html

Quick screencast: http://screencast.com/t/7uLnAgD1SkP Grab the code: https://github.com/apeisa/InputfieldFlickr Not production ready, since it doesn't save authors name nor url anywhere (and most of the Creative Commons licenses require attribution by name or link). I will develop this further soon, but decided to post this already since it is pretty nice to play with. Especially if you are building site with lots of images and need to test with placeholder images, then this is easy way to grab those quickly. Code is not prettiest and there are many places to improve, but this is my first "independent" module, meaning that it is developed without Ryan's direct input. So I am kind a proud of this one

Thanks for your kind words Pete. And don't exclude yourself out - you are important part of the friendly atmosphere here!

Yep, I tested this too now. If you set parent then it shows only short tree and allows to go deeper - but saving other than direct children doesn't work. So bug here.

How have you configured your fieldtype? You probably have setting "Parent of selectable page(s)" -> this mean that you can select only direct children of the selected page - so it works as expected. Easiest solution is to have common template for all topics (ie. "topic"). Then leave "Parent of selectable page(s)" empty and select "topic" from "Template of selectable page(s)". If you don't have or don't want new template for your topics, then you have to write custom selector to "Alternate/custom code to find selectable pages". That is not very complicated, this should work: return $pages->get("/topics/")->find(); Code above assumes that you have page /topics/ which keeps your topics tree. And of course you could use ->get(5232) where 5232 is page id for your topics page (so that selector would work even if you decide to move your topics page).

Yep, that was easy. I just send you a pull request, but probably not wise to pull before you come back.

Ryan, I would love newer jQuery, since one of the modules (flickr image search) I am developing would really benefit from jQuery 1.5+ (http://api.jquery.com/jQuery.when/). Not in hurry though with this.

Yep, I have seem some weirdness on that. I just didn't now when it happened. Usually I read all one by one and using browsers back button, so very rare for me.

slkwrm: I think that what you are saying makes a lot of sense. Somehow similar situation that Drupal has compared to WP and Joomla. There is good post from Dries about that: http://buytaert.net/joomla-vs-drupal-business-models-and-commercial-ecosystem and some very good comments, like this one here: http://buytaert.net/joomla-vs-drupal-business-models-and-commercial-ecosystem#comment-32841

Probably best solution is to rely to the community here. Things like amount of downloads/installs, development activity and discussion right on the "module page" would give good indicator about the quality of the module.

Yep. But have you heard that he can build skyscrapers with just bare hands?

Robert: that video is from Processwire 1.0 (I assume). Many things work little different in 2.0. It was nice watch and probably helps to grasp the concept - but might be more confusing than helpful for some users. Actually for me that was very interesting to see and compare to 2.0. There is much more "everything" in 1.0, and comparing these two really shows that great design is always to make things simple. Separating fieldtypes from inputfields: brilliant. Hiding fieldgroups: brilliant. Although it seems that 1.0 was already pretty simple cms (considering the flexibility). PS: Ryan, you have great and very clear style on your videos!

Adam: You are absolutely right: we have pretty big challenges coming with site upgrade, promoting pw and handling all the new traffic. All these things are top priority, and something like marketplace or even centralized module distribution are things that come after that. That is probably year or two, when critical mass is reached and we really need a solution for this. I started this discussion early because I wanted to hear what is general consensus and how Ryan feels about these things. I'm not sure which way is best, but I would love to see a lot of polished and well supported modules (that usually means commercial, at least for support). But commercial modules introduce few problems: Price tag (they cost money, not a problem if you have a budget) They don't courage to contribute (why would you fix bugs from commercial code that makes money for someone else?) Commercial module doing something that should be in core I see the latter as a most problematic - though probably easily avoidable. Let's say that there would be brilliant multilingual module which costs 295$. Perfectly made in PW style and everyone loves it. It should be in core. Like CCK was for Drupal. Well, as CCK was open source developers just integrated it into Drupal core (before that everyone just installed it). Another example from Expression Engine: There was commercial 3rd party module SafeCracker, which extended EE in a way that developers loved. As EE is commercial software then company behind EE just bought the addon and offered it as a free download. But in case when module is commercial, but cms is open source. It could lead into a stupid situation: community could code everything again, and be sure not to copy the module code at all. Or leave the situation as it is: we have solid cms but multilingual/form-tool/some-other-should-be-in-core-module costs money. BTW this seems to be situation with Concrete5, where company behind the C5 are also big seller of commercial addons. I think the ideal situation is probably somewhere between these two alternatives. First Processwire should always have clear roadmap, for at least for few big next steps (like we have now: multilingual, user forms, versioning etc), so people who want to develop modules could develop modules which will be in core (they should contribute developing those as core features, although os module would be great way to start it). Also open source modules should be encouraged because they allow contribution and it really gives a processwire a lot. But problem with open source modules are that they are often unpolished, forgotten and/or unsupported. Sometimes they are only beneficial for other "module developers" or people who are willing to fork and fix. Then there are things that gets build many times, because they are stuff like "well, I need it for this site only" or "this is so messy, that I won't release it". Or from the other side of the fence: "oh how I wish there would be bridge between pw and smf, and someone who could help me install it - I would easily pay for it". So that developer takes the extra mail and polishes and supports the module so that he thinks it is worth money for some people. Then it would be great to have commercial modules easily available - or better yet - some easy and effective way to support open source developer. What would be most effective way to support open source modules and processwire core? And by support I mean hard cash now One alternative would be that official marketplace could get creative: maybe to support only "pay what you want" method, so if you want to get the software for free you can have it for free. But downloading process always reminds, that "developer of this module asks donations to keep develop and support this module. And by the way it wouldn't hurt to support the core development of processwire while you are into it". And of course developer may decide not to want any donations or wants to give all donations towards processwire core development. People and companies do like to donate, if they are encouraged to do so. The reason why there aren't any commercial drupal modules are that they aren't allowed in drupal.org. And the reason that there are so many commercial modules in Concrete5 marketplace is that those are encouraged there. So the way we decide early on will be very important. People are like sheeps, we usually follow how others do things and keep doing it that way So I think we should aim to whichever creates high quality modules and tries to keep those as open source.

That will probably be the case, since I don't think there are enough users yet to make commercial modules meaningful. Also not sure how GNU GPL v2 license works with commercial modules? When I look at the current state of different cms ecosystems, I think that commercial add-ons are very much welcome. If you compare the quality of EE add-ons vs Drupal modules, it is amazing how much better EE add-ons are (considering also that Drupal is so much more popular than EE). But as a developer I would hate a situation that I would need to buy from 5 different developer few addons that I always need (seems to be case with EE, but they do have http://devot-ee.com/add-ons/store/). Also the cost that modules are (from 10$ - 100$) they are easily worth it, if project needs it. These are just my initial thoughts, but I try to describe what I think as a ideal (or at least interesting) situation: One centralized store for all addons (modules, themes etc). This would be supported by company behind ProcessWire (Ryan Cramer design). Store would keep little amount (10%-30%) of payment, but would offer free marketplace for developers and customers. Same marketplace would be used to share open sourced themes and modules (ability to donate). This could also be combined to premium support, so if you pay premium support, you get free access to (all or just some of the) commercial modules. Money would of course be shared between support and add-on developers based on usage. All this should be done as openly as possible, so everyone sees how the money flows. Other scenario would be, that all addons would be free, and supported from premium support subscriptions and donations. I think Concrete5 is only CMS product that has "official" marketplace. I just read how it works (http://www.concrete5.org/developers/marketplace-submission-rules/) and I think that is pretty close what I had in mind. And it seems to be going pretty well (lot's of add-ons and themes).

Amazing documentary about global financial crisis of 2008: http://www.imdb.com/title/tt1645089/ Anyone watched?

Just wanted to start discussion how people feel how ProcessWire ecosystem should evolve in the future? What I am thinking about are mainly 3rd party modules, themes and site profiles - and how they are provided. All open source? Commercial modules? What is the direction that would be most beneficial for processwire and people & agencies using it? There are huge differences how these ecosystems work between different systems: Joomla, Drupal, WP, Expression Engine, Concrete5 etc... Also Ryan has mentioned few times about possibility to offer commercial support for PW. All these things are very interesting and I know this is little early on, but I think it would be great to start this discussion now.

Hi Leslie and welcome to forums! Strange error and I haven't spotted earlier. Can you provide few other details that might help debugging this one: 1) Which browser you are using? 2) Is the frontend demo site working fine? 3) Are other aspects of admin working? 4) Does your javascript console give any errors? Firebug or some other browser plugin enabled? (pagelist uses javascript)

It works this way in 2.1. When editing templates you can choose it to show system templates also. There is user template that you can extend like any other template.

As I said, not on the roadmap yet. Just wanted to mention that Ryan have thinked about exactly same kind of import/export tool that Sevarf is looking for.

Actually this has been discussed earlier. Import tool is coming, but not on roadmap yet: http://processwire.com/talk/index.php/topic,130.0.html

I build custom "widgets" for lukio.fi site. Very close what Adam described above, I think. It took about 30 minutes from concept to working code. What I built is something like this: I have one page as a container for all widgets: /tools/widgets/ I have template for "default" widget. That template has title, summary, link_title and link_url fields. This is only because that site had lot's of that kind of widgets, which have some text and link. I have different kind of widget templates also, one which allows banner image and link. Of course there could be any kind of widgets: most obvious would be just textarea that allows html or youtube widget, which would ask only youtube video id etc.. Then I have "widgets" page field, which I have on my normal templates, like "home", "page" etc.. This is multiselect, so you can choose as many widgets as you want. As you could guess it just allows end user to choose widgets from /tools/widgets/ children. I have also widgets() function, which is on sidebar of those "home" and "page" template files. That loops all chosen widgets and returns their content. Because there are different kind of widgets, it checks the widget template and outputs the code based on that. So if widget template is "youtube" it returns youtube embed code, but of course adds there the youtube id from fields. You could also have multiple widget page fields if your site design requires widgets in multiple places. No problems there. And if you are using asmSelect, you can drag and drop widgets to any order you want.