Ivan Gretsky

I guess serving mobile version to a considerable amount of clients is not a good idea. So using Unsemantic seems like is a good decision. Skelton is the other thing that could do the job, but it is a framework, not just grid system. And it is not fluid as Unsemantic is. I am sure you are aware of all this. Just for the record )) And no holywars, of course. Those should have ended in 11th century for good.

The point probably is to serve the same content to any browser and be sure it is possible to view the content right. Most of the grids simply break on IE8-. Unsemantic can work without media queries with adapt.js.

It would be great to automatically add a tab to all templates (like you can do with fields). This is handy for the SEO tab for example.

If you could only know what they are saying in the background ))) But maybe then this video would not make it's way here or would have been deleted.

XAMPP is the way to go. They got portable version too. If you do not need to install something not included like Python or Ruby you can live with no worries. There are answers for almost anything you can ask on the web.

1) I think you already got enough to start . You will get the rest only doing real things for money with time limits. 2) It depends on how much time do you have. But I am sure you cаn manage 2 per month just cutting your sleep time. 3) I think that you should't worry too much about the right hosting solution for those first small project, Just get anything shared that suits you with some partner program. I used to register individual shared hosting accounts for clients. 4) Why not try freelance sites? There are probably a couple of them in your area (do not know wherе you are). You could offer you services here in the appropriate branch of the forum. 5) I think best way to learn is to go out and try. Just decide what you have to offer and what do you want for it. And then they try to cut it down as much as they can, and you tell them that crafting a site is something bigger than making a word document. Good argument is how much time does it take to do it. 6) It really depends on where you are. I guess you can analize what your competition has to offer and/or try to estimate how long will it take you to do the job. 7) Just start and then you'll know that to do.

Recently the most popular answer in the forums is "Google it!" I can imagine community becoming less responsive if the moderators have to deal with more and more of those beginner level questions too often. So why not integrate google search into PW forum if it could help? I guess seing some more ads won't hurt nobody ))

Mаrcus! I see a lot of topics you create related to the profile recently. But github repo does not seem to be upgraded. Is there any way to watch the progress of development and/or help testing it?

I wish we could choose Inputfield types on a per template basis and all the other advanced options. This could reduce the number of fields needed drastically. Not sure it is possible though or if it would slow down the system.

Too bad no Cyrillic letters .

It is great! I want to propose an enhancement though. Do not know if it could be easily done, because I did not try Hanna codes yet (but definately will do in the future). Those tags look really scary for the user. It would be great to be able to name those codes, so they will show without the square brackets in the list. But this is probably unwise to do in this modulу, but rather in the Hanna code module itself. Anyway, this is surely usefull as it is. Thanks, Teppo!

There are a few videos by Soma dedicated to plugins. But I also try to notice a bit of a master's backend organisation while he is clicking through the admin. Here is the link.

There is Pootle in case we decide to have our own solution for that. But Transifex seems to be popular. Some Joomla projects were on Transifex. I would sertanly join the Russian translation group whichever way gets chosen.

The theme could be more abstract and consist of field renderers and css to style them. So you Install a theme which provide markup renderers for all field types (maybe a few for each). In the backend you choose which renderer to use for each field. You could choose not to render a field. All renderered fields could go in the main content area stacked or even use some kind of a sub-template to get more custom output. This is how Seblod for Joomla works. Maybe some kind of special profile could be developed which would be themable in an easy and consistent way. But in the end, all this will turn into something less universal than PW without it.

You still could go the frontend way and make use of Form Builder to implement cource publishing feature and maybe profile upgrades as well. If you want to go the backend way follow kongondo's googling advice in this topic or +1 on the tutorial request in there .

I am sure that it is not a simple task to produce a tutorial like that. Maybe the screencast of a backend system of a complex site would be an easier starting point. Sometimes it is nice to actually see something done (not just know it can be) and then do it yourself.

In tutorials section of the site we are encouraged to request tutorials. This topic is such a request. ProcessWire is advertised to be great in not only building unique frontend features, but also custom backends. I would be very much interested in tutorial on building a custom backend for a site. I put some questions that could be covered in such a tutorial in a list below: How to create custom backend pages How to change the default starting page for admin users How to serve different backends to different users depending on roles How to style the page tree (I have seen it styled in some Soma's video tutorials, so it is a request for a best practice or an advice) Anything else you think appropriate here))) If someone could generously provide a screencast of a custom backend workflow it would be great tutorial in itself.

The thread starts with WP and Drupal screenshots. I just wanted to point out that the menu components of those systems may differ greatly from what you and kongondo intend to implement as a module. And those coming from those systems may be confused. I know that as I came from Joomla and it took some time to start to understand why is there no menu system in PW by default. In fact there is, but it is built in the page-tree. Personally I try to use as many default features as possible while working with ProcessWire. It makes me feel safer and pushes me to learn more of it's API and PHP in general. Thats why I think that "virtual page-tree branch" is preferable approach. But in no way do I deny the possible need for a menu builder module and even can imagine using it myself in some cases.

I think, you are right - you will have to rebuild everything in the front-end. Maybe not from scratch, but from some UI library like JQuery UI or YUI. And if you are new to ProcessWire and PHP it might be some hard way to take. Though it is possible to do, I would advise to take a look at some out-of-the-box systems like Moodle before making a decision.

I guess the main reason for menu system components in many CMS's (Joomla! for example) is that it helps build URL structure of the site. So in those systems you create pages (articles, nodes and so on) with no relations to other pages. And after that, with the help of menu system you apply structure to those pages (define what page is child to another and so on). That structure shows itself in the URLs (and causes duplicate URLs, by the way). In PW you just can't create a page out of the page-tree. And that page-tree is a structure in itself. So in most cases there is no need for a separate menu system. If you do not need the URL structure change, a "virtual" page-tree branch seems to provide custom menu functuanality without a module. But if you need to build a URL structure different from the page-tree structure, the modules proposed will not help, at least as I can understand them. URL segments are probably the advised way to do custom URL structure. So menu builder modules could somehow trick the user, who has experience in other CMS's, instead of helping him to understand how PW works.

I just went to redactor official site and the big red buy button is kind of making a call not to include it in a GPL system . And the FAQ section just makes you sure about that. Though it surelly could be done (after purchasing, of cource), as other wysiwygs already made their way into PW. Just see those: http://modules.processwire.com/modules/inputfield-ace-editor/ http://modules.processwire.com/modules/inputfield-trumbowyg/ I think Nico even made his own one, but can find it right now. But I guess the best part of a built in editor is its integration into the system (like image inserts). And it is done quite right in PW. More to that, it is quite easy in PW to make adjustments to the editor options from the admin, which is really cool. I did not know those options even exist untill I started with PW. So I would stick to the default one most of the times. Really cool that CKE is now the default. Just to mention, TinyMCE 4 has a great looking skin now and works fine.

The forum is alright, but the main PW site should make a switch )))

PHP is default on most shared hosting servers nowadays. It is much easier and cheeper to get a site running than with NodeJS, for example. So it seems like a better choice for SMB and therefore developers that just start their career as freelancers.

I would agree with #4. It would be really usefull to have all the valuable forum answeres structured somehow and easy to search. Tutorials are great but they tend to cover basic questions and are not structured in any order. Wiki could be the place, but it does not seem to evolve. Cheatsheet is api reference, a more low-level stuff. We should produce a nice learning curve for the newcomers, so after the 30 minutes with PW they still would learn only a bit, but not turn away. Rather the should find a shining perspective in front of them . I thought about managing some sort of a forum guide (actually started it for myself following valuable topics) which could be a forum topic of it's own, a wiki page or a page in the DOCs section. Those, who are only on the stage of combining plugins will never switch to PW. But those, who understand the need for a customizible solution could have used some kind of a manual or guide.

I got download buttons in the API section not showing right in Firefox. Chrome and IE got them right. Please check if it is not my browser cache or something.