felix

Thank you very much! Yes I do. Please see my answers below. I'd love to further discuss the topics I brought up though. Yup. That's the reason I'm currently waiting for 2.4 to be finished (I said that in another thread about writing blog articles, too). Otherwise I'd propably have to refactor all of the stuff on a daily basis. There currently is too much (very positive!) change going on. Apart from that there is a lot of other work to do. We're currently building about 6 websites in parrallel (all driven by processwire - yay!) which is good for our business but bad for doing sideprojects like this theme. WOW. I didn't read that until now. Thanks for the hint

You obviously don't know owlcarousel then

Setting a class which disables pointer events while scrolling = no more (re)paints when accidentally hovering elements <3 http://www.thecssninja.com/javascript/pointer-events-60fps

http://www.malsup.com/jquery/block/#page was propably what you were searching for.

typo3 neos which is now in beta does most of the frontend in place editing stuff as well as adding content templates exactly the way you've mentioned. I must admit that at it's current, more advanced state it's exactly what i had in mind when i was opening this thread. but after all it's still typo3 (typoscript, flow... yikes!). that's why i won't be using it.

I'll use svg then

Of course i will I might even translate the first article somewhen in the near future. Even if there are a large number of people who understand german here in the forums this might not be the case with the majority of people that are just using processwire without telling us about it. Or even worse (as you've mentioned): People who could be convinced using pw by these articles but don't understand them. We actually chose to do the blog in german because we didn't want to introduce barriers for our developers/writers to just write down stuff. It's much easier to write something in your mother tongue and maybe translate it later. We do all speak english and read english sources every day but writing professional articles is sometimes even hard to do in your own language. Wow: I believe that's really a hard job to do. As most germans only watch dubbed movies: Even if you've got the best actors a bad dub can ruin the whole movie. It happened quite often to me that most of the jokes and puns were lost if I watched a movie in german after seeing it in english before. BTW: My favorite language for breaking things in web development is finnish. Not only that it looks funny (sorry teppo ) but it's a pretty good test if your layout can handle lengthy words and the CMS a lot of "umlauts" Das ist verdammt noch mal wahr, alter! (That's damn true, dude!)

Just found this thread: http://processwire.com/talk/topic/1920-processwire-logos-download/ - Michael van Laar did the vector work for the logo. I actually don't think there will be a legal problem with making a font of it: As long as you don't alter it to say "mySuperAwsomeOwnCMSWire" it's used as intended (for branding pw instances). I think the best way to implement this would be ligatures (process and wire) as well as the letter "w". There is an option in iconmoon to do this: you can just upload 3 .svg graphics, select ligatures from the options menu, enter process for the first ligature and wire for the second and there you go (in fact i already did that for my theme yesterday ).

http://jankfree.org/ Strapped for time or just getting started with eliminating jank from your projects? These are our must-see resources!

At work I'm mostly listening to some youtube playlists.. For a "relaxed" working athmosphere my favorite yt channels are the sound you need: https://www.youtube.com/user/thesoundyouneed1 (mostly house, some hip-hop) and liquicity: https://www.youtube.com/channel/UCSXm6c-n6lsjtyjvdD0bFVw (liquid drum and bass) For "getting things done" I'm quite a big fan of... "BASS" :

*bump* Any progress on this? I'd love using it in my upcoming Theme!

I've just tried that, too. You're right: It doesn't translate very well. That's not surprising given that german is one of the worlds most complicated (and confusing) languages concerning grammar. It's a quite funny read though. You're right: There are a lot more articles to come. I'm actually thinking about publishing a series of "how to build a simple website with processwire" on a large german tech magazine as a guest author in the future. But that's just an Idea and I don't know if they are intrerested yet. And I think it's better to wait until 2.4 with all it's improvements is finished before publishing it. Thanks a lot! I'm glad you like it.

Thanks a lot for your great Feedback! That's what the article was intended to be: An easy introduction for beginners. After reading the article again several times I think the part about Templates, Fields and Pages still misses some "polishing" though. Due to the quite lengthy sentences it's not that easy to understand which of these does what. I think I'll add some sort of "Begriffserklärung" tomorrow Yup. I feel the same. That's why I've linked it in my article. Thanks for your finding. I already fixed it.

Just finished the first post of an upcoming series about processwire (sorry: it's written in german )

You might want to have a look at this module of my coworker which does exactly what you've mentioned: It separates the "view" (mostly logicless) templates from something called "data providers" (controllers) and adds some logic to define reusable chunks. Plus: It also plays nice with this one which lets you use twig for the view templates.

WOW. I didn't know Sir Trevor yet and really love it!

Very nice and well executed site. I love the idea of structuring the page-tree like this!

Very nice site. One thing I noticed is that scrolling is pretty sloppy. You should consider watching this video and applying the techniques used there. I just opened up dev tools and did some "translateZ magic" and got huge performance wins from it.

Thanks a lot! I'm not always sure if the way i'm writing sounds like intended as my school english got kind of rusty over the years. But I enjoy writing in english and the discussion itself for sure. On topic: Introducing new "cutting edge" stuff always includes a certain risk of the tools beeing discontinued and therefore betting on the wrong horse. Thats why all of the stuff I mentioned already has a strong foundation and is established among many users/projects. You're propably right: PW doesn't actually NEED it but it would have certain benefits that i've already mentioned performance wise. I actually just meant the methodology. Sorry about not making this clear. I'm with you here that introducing the stack of tools as a whole that'd for sure be overkill. Thanks for mentioning - i didn't look up the sourcecode of any of them. I was just talking about the general look & feel (and also mentioned they're not as complex as PW). If you look at them they seem "light" and easy to use due to their lack of clutter. That's what makes them a role model for me. There's a pretty similar saying in germany: "Das Gegenteil von Gut ist gut gemeint" (translated: "The opposite of good is something done with a good intention") which basically means that worst thing that can happen is people doing something wrong thinking it helps you and then rely on that. Correct. That's the complicated part about it. Either you'd wrap them all into a define() closure or shim them. But if you'd shim them you'll have to register all of those plugins and build a list which has to be dynaically generated into the require.js config (see: https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-shim ). Yup. There are tons of testing frameworks out there (mocha, qunit, and jasmine to name a few). Then there are testrunners which run those tests not only on an (i.e. node) js-interpreter but in a real browser enviroment (like jsTestDriver or karma). Yup. I've already started to code some stuff. But I don't have that much time currently as my family and some paid projects we're doing have more priority currently. But I'll try to release some code as soon as possible. You're welcome! Thanks for your feedback! -- As already mentioned I'm only drawing a picture here. I'm aware of the fact that this is not something that could be done easily. My intention is more to "get this on the roadmap" for some future release or to have people at least think about it as well as getting a feeling if there are even people thinking the same. I'd also like to keep discussion up and running. If there are people learning from it and getting inspired that's great and makes this discussion even more valuable for all of us. I'm currently investigating in how much work it would be for me to rewrite certain scripts but keep their functionality and don't break things. As you said: It's a lot of work and not something that can be done until tomorrow. In my company constant change and adapting new technologys is one of our "core values" as we help our customers in changing their communication and methodologys a lot. So I'm pretty sure there will be more to come as this discussion continues

Nice! Would you mind creating three other glyphs? It would be nice having "process" and "wire" as two seperate glyphs as they are often coloured differently. Also the "w" from wire would be a nice addition to do a "picture sign" for navigations.

I'd love to hear the methodology you would have chosen! I also not a big fan of jQueryUI for the same reasons you've already mentioned. Removing it would mean to rewrite most of the core JS though. That'd be a pretty substanical decision to make. -- How would using modular patterns change this? As stated before: the only thing "new" would be require.js. Apart from this BEM would even make it easier to change things (and you don't have to use it yourself if you are developing a module). You're right. Processwire is blazing fast. I'm only drawing a picture of a "better" (from my point of view) architecture. Well if you count in the various module developers which also tend to inject customisations into the backend (new fields, admin pages...) you actually HAVE a huge amount of people working on the backend and NEED some sort of standardization. Just look at all this !importants in every module. Once again: I never mentioned replacing jQuery with something else (especially not ExtJS which is a nightmare). I'm fine with using it although the way it is used could be more modular and less dependant on certain dom structures (proper event delegation, micro-templating or even directives like in angular would be fine). Yes and no. The "cleanest" way would to wrap all (core) modules into a define(...); closure. You could go and "shim them" all instead. But that's a nasty thing to do. This - for some people - is quite a subjective one. But from a "professional" point of view there are quite a lot of things that could be done better (in terms of UI/UX). PLUS: If you want to sell/market something it better looks "sexy" Accessability is more like a way of thinking about and architecturing things. Many of the core modules which either produce DOM-Elements or modify them (js) would need some tweaking. This only covers the PHP Part. No JS-Testing until now (there are again some requirements for this - scripts need to be written a certain way to make testing efficient and reasonable). Maybe you're right. I'll explain this a bit further in an upcoming post as i don't have time to write down all my thoughts on this now. This has a lot to do with how different personalitys and the way they handle changes to things they are already used to. Maybe it's the best way to start off with a theme, get some feedback and then as development continues some ideas and code might find their way back into pw. I don't like the idea of starting a fork of PWs backend as i think this would be pointless and do more harm to PW than it would help. Nevertheless it'd be great to keep this conversation up and going.

Hey, thanks for your answers. I'll write something tomorrow. Had no time today

Concerning "fancyness" and the Design part: Maybe it's easier to understand where I am heading if I share some more general perspective of engagement with you: I adore the system and want to give something back I'd like to make processwire more known as we would all profit from this in several ways I like the way the processwire community acts and communicates: You're all kind and lovely people around here in the forums Having said that here is "my plan" to discuss and think about I'm a CTO and developer at a Communication Agency and (as i already stated) and have a strong design & UI background as I completed vocational training as a media designer. I'm also very interested in marketing. To be kind: What I'm trying to do here could be summed up as "Content Marketing". To Explain this further: Me and all my co-workers were in search of a "perfect" CMS that fits our needs because we were tired of all those typo3s, drupals and wordpresses out there. We discovered processwire and all loved it. I even managed to convince my boss that we should start using processwire as our first choice CMS because it seems promising in the long term. He agreed because he trusts me with this kind of decisions. That was mostly because I told him that I know there are plenty of other developers feeling the same. That's a good starting point: When a lot of people are searching something there is a business case for it. But there was one thing we didn't like and in my opinion is a reason processwire doesn't get the credits it deserves: The design of it's backend which until now (sorry: no offense ryan) looked kind of "oldish" (i love where the new dev-branch theme goes though). If you're looking at choosing processwire from a bussiness perspective it is nothing (at least our) customers already know, so there are some things to consider apart from how efficient and fun it is to build websites with: How do i convince my customers this is the CMS he needs? Will my customers have "fun" using it and be satisfied (as in "WOW, this is SO SIMPLE and BEAUTIFUL" i'll recommend it to all of my partners and drop my MS-Word for it!!11)? Will there be more attention (and thus more potential jobs) in the future? If not: How can we manage to draw more attention to it (again: for us and the community because we do believe it should have)? Most people like "nice looking and simple" things (take the iPhone for example). Processwire is (imo) just simple yet. That's good from a developer point of view but won't sell you anything. So let's work on that. If we made it more "nice looking" we can start the "marketing machine" saying: Customers love it's look AND developers it's simplicity. It's so super-duper awesome that a really big bunch of hip "early adopters" (that's us!) is using and has written some articles in about it (which is something we're about to do, too). The people you should try to reach here aren't just developers but designers and marketing guys who are really good at sharing and promoting things once you've conviced them that this is an awesome system to use. Once PW is more known: How can we position ourselfs as experts when someone is looking up people who implement things with PW for him? Engange Be visible Help making things better Promote where you can Last but not least: World domination! ;D Ghosts marketing did a pretty decent job on that (except for the world domination): No one knew how the system would work but it looked simple and beautiful so it got a big buzz, is widely recognized and people are starting to build stuff with it. I know Ghost reaches out for a different kind of users (more End-users and Bloggers) and I didn't dig too deep into Ghost but as far as I can tell it's pretty "basic" compared to what processwire can do.

Ok: Let's just leave out the fancy design for now. If we do that there is exactly one tool apart from bower which I've mentioned: require.js. If you don't like using this: I'm OK with that from a "don't use too many fancy libraries" point of view (but IMO there are - as i mentioned - several good reasons to think about it). Other than that I only talked about making things more modular and fast which isn't dependant on any library or framework. When you remove the "prose part" i was basically saying: Modularity Use OOCSS and make Javascript less dependant on Markup and other Javascript Performance Keep an eye on performance issues and make things as fast as possible Accessibility Add some markup that helps disabled people to use processwire Testing Good software (which processwire is) should be tested I'm with you here. Let's take OOCSS as an Example: For a long time I didn't like the concept of OOCSS and kept using descandant selectors for "all the things". While this is a conservative and valid way to write CSS there are certain pitfalls and problems which make it hard to maintain and extend. When it comes to complex frontends that are beeing maintained and extended by multiple developers it's good to have some structure and guidelines to assure everyone is running in the same direction. I recommend reading these articles to dive more into this concepts. Implementing - for example - BEM syntax and methodology would be pretty simple: It's only thinking about structure in another way and adding / removing some classes. As diogo mentioned SASS is already used in the new admin theme and i'm pretty happy with that as it adds another layer of easier theming and DRY. If I were about to introduce a lot of "state of the art bells and whistles" i would have mentioned doing the backend with angular, ember, polymer [more namedropping and fancy frontend frameworks here] or even building a processwire api framework which acts as a facade and abstratcs dom manipulation and common tasks out so you could even drop jquery and use zepto, prototype or yui instead. But I didn't do that for a reason. I'm fine with keeping it simple (stupid) and not overenigneering things (I've done quite a lot frontends for magento which imo is an overengineered nightmare and a perfect example how to complicate things while maximizing modularity to a level no one will ever need). Sorry: I can't follow your argumentation at this point. I'm still not getting what the fact that processwire doesn't bake in anything at the frontend has to do with the style the backend is implemented. The frontend part is "your project": This is the what you are going to produce the way YOU like and processwire is a very efficient tool which helps you to achieve this without getting in your way. So if we make processwire even more efficient and customizable (if you're interested in customizing things) what makes that a bad thing? Why would one need two interfaces? I think it's OK for both editors and developers to have a decent, up to date, simple, good looking, efficient tool to work with. For me there is no need to seperate things here.

Hey SteveB Actually what I'm aiming for is exactly what you've mentioned: A modular backend that can easily be themed and extended. Apart from bower (which i personally like but i'm not surprised others don't) nothing of this is actually something that ties you into a specific Framework (in fact the processwire backend does already tie you to use specific frontend components - namely: jQuery and jQuery UI and there is nothing wrong with that as they are widely known and used). What i'm promoting is more of a "keep the backend fast and modular" approach which provides theme developers even better tools to achieve their very own personal setup. Maybe the design and the "improvement of technical setup" threads should be separate discussions. What do you think? //Edit: If I read your post a second time: Maybe there has been a misunderstanding. I didn't talk about making any changes to the way processwire assumes what you will do with it in the frontend. That's the thing i actually like the most about it and i'm totally with you it shouldn't be changed (if i were thinking about how to change the way processwire works I'd be better off searching for another CMS.)! Again: I'm only talking about the "frontend of the backend" here. //Edit2: I just realized that this actually might be the kind of productive discussion that i was aiming for. I get your point that complicating things too much is very valid. If processwire would only be customizable with a higher computer science degree (which i don't have either) that would be very contra productive. Thanks a lot for your input!