Leaderboard

I think it makes sense to keep the direct output, since more advanced developers will most probably start with a blank state anyway.

Just to correct the quote above, delayed output is more scalable, not less scalable. Direct output is what doesn't scale, but it doesn't really matter when it comes to the default profile. I have worried about this aspect a little bit: making something as easy-to-understand as possible, versus showing what is a best practice. Delayed output is just as simple as direct output (not to mention it uses a lot less code), but it's not as easy to understand at the very beginning. On one hand the PHP developers evaluating ProcessWire cringe when they see the direct output method used in the old default (now classic) profile. On the other hand, beginners find it easier to relate to since it's common in other platforms. Both are our audience. If people think delayed output isn't beginner friendly enough, perhaps we need to have two versions of the default site profile. A beginner edition and an intermediate edition. Attached is a beginner edition of the default site profile. @Woop if you or anyone else gets a chance to take a look, please do and let me know if you think this is a more beginner friendly approach. I think it probably is, even if it isn't an approach I'd suggest someone use for anything but smaller sites. site-beginner.zip To install, just grab a fresh copy of ProcessWire 2.5.0+. Place the contents of the zip in a /site-beginner/ directory and then load the installer from your browser. For site profile, select "Default (Beginner Edition)". The readme file in /site/templates/ has also been updated in this profile to reflect the structure of the template files. As for re-writing the text in the default profile (something mentioned way earlier) I agree on this and I need to talk to Joss. But I think getting the template files as simple as possible is a bigger priority at the moment. I think a lot of people installing CMSs for evaluation are more interested in the system and templates than in what demo content is in the fields. But for those that do read it, we can do better.

As in most cases with PW, there are multiple ways to accomplish this. That can be scary if you're coming from a module-based system and/or are not a coder, but once you “get” how much freedom it can give you to not have to rely on modules, it's a thing of beauty. Yes, it means you're going to have to write PHP code, but you have the trusty PW API to help you with it. It's really not that big of a deal, trust me. (I'm an idiot in PHP myself.) Let's assess what you need here and strip it down to very basic concepts. Basic concepts are great, because they are usually generic and thus reusable. As you probably know by now, the most basic concept in PW is a page. So what you need is a page type to list all the items, a page type for the actual items and a page type for categories. You'll probably want a superordinate page type for categories as well, but since those don't necessarily have to emit frontend markup, they're pretty easy to define. Your page tree for this might look like this: OverviewItem A Item B Item C CategoriesCategory A Category B Category C Categories as well as its child pages most likely only need a placeholder template since they don't necessarily emit frontend markup. You could have a category.php in your templates folder that looks like this: <?php // Placeholder template for categories Now, in your template for items (let's call it item.php), you would need a field to associate the items with a category, meaning: with a page that is a child page of „Categories“ and/or has the categories template. So you would create a field of the Page fieldtype, call it e.g. “itemcategory” and in its settings limit it to one page (meaning one category), which has to be a child of the page “Categories” and have the categories template. All that is pretty self-explanatory once you see the Page fieldtype in the PW backend. If you add this “Item Category” field to your item template and create a new page with that template in your backend, you can now choose a page representing a category for that item. (Let's skip the actual content of item.php, that's not really relevant for the list here.) Now, how do we list those items in your format? We need a template for the overview page, let's call it item-list.php. In that template, we can do this: <?php // Get all child pages, i.e. items $items = $page->children; echo "<ul>"; // For each item in our list foreach ($items as $item) { // Create a list item including a link to the page, the page // title and the category title echo "<li><a href='{$item->url}'>{$item->title} ({item->itemcategory->title})</a></li>"; } echo "</ul>"; The filter is a bit more complicated, but mostly because it depends on how you want to implement that. One option would be to just go with a JS-based solution, at least that's what I would do. (I'm a bit more comfortable with JS/jQuery than with PHP, so …) You would change your item-list.php maybe like this: <?php // Get all children of the categories page $categories = $pages->get('/categories/')->children; // Create buttons for all categories <div class="filter"> Filter: foreach ($categories as $cat) { echo "<button class='show-cat' data-show='" . strtolower($cat->title) . "' type='button'>{$cat->title}</button>"; } echo "</div>"; // Get all child pages, i.e. items $items = $page->children; // List all items echo "<ul class='items'>"; foreach ($items as $item) { echo "<li class='" . strtolower(item->itemcategory->title) . "'><a href='{$item->url}'>{$item->title} ({item->itemcategory->title})</a></li>"; } echo "</ul>"; So now you have a button for each category which stores the lower-case name of said category in the data-show attribute list items which have class names which also have the lower-case name of their associated category which means you can write a little piece of jQuery $('.show-cat').click(function() { var showme = $(this).data('show'); $('.items > li').hide(); $('.items > li').hasClass(showme).show(); } which gets the associated category class of the button and then first hides all the list items and then shows only the ones which have the class associated with the button (i.e. the class matching the selected category). Please note that this JS code a) requires the jQuery library and b) is not perfect for performance, but the easiest way to quickly show you how to do it. It would be better to instead add and remove classes, but for that we would need another code example for the CSS you'd need for those, and I'm already posting a really long example here. Also please note that all this is untested and written from scratch off the top of my head on a lazy Sunday evening, so there might be typos. There might even be logical errors in the code. (There probably are. As I said, I'm an idiot in PHP. ) Sorry about that if that's the case, but I hope this example gives you an idea of how simple it can be to write the code for this yourself instead of relying on a module. Yes, other systems might give you a module ready to plug in which gives you about that functionality without having to write a single line of code (well, probably not), but this way you control exactly what code is used. You don't have to have some part of it in one specific way because the module's author decided to do it that way. You can have it your way.

Hi seedle, Firstly, 2.5 is the current stable version so you should grab that instead. As for page/pages: http://processwire.com/api/variables/page/ http://processwire.com/api/variables/pages/ I am not really sure what information you need, but to clarify, wire('page') is effectively the same as $page, but due to PHP variable scope $page is not available inside your own functions, inside PW modules, or on a script that is bootstrapped to PW. That is when you need to use wire('page'). Same goes for all the PW variables: wire('input'), wire('sanitizer'), wire('user') etc. If you are wondering what $page and $pages are actually for. Basically, $page gives you access to all the fields on the currently viewed page on your site, eg: $page->body $pages gives you access to all pages on your site - you can query the pages you want using selectors, which are Processwire's version of database queries. It sounds like you might benefit from reading through some of the new tutorials: http://processwire.com/docs/tutorials/ and of course the cheatsheet: http://cheatsheet.processwire.com/ Hope that helps!

Hey, after reading woop.s pdf over http://lightning.pw): Login: http://terbium-znu.lightningpw.com/processwire/ Name: demo Pass: demo123

@blad: you simply can set maxwidth and maxheight for the imagefield(s). Look at input Tab in the admin. I'm on mobile. There is no module needed, Setting both fields to 800 for example resizes the original Image with the largest side to 800px. Edit: wow, it seems it tooks me 4 minutes to post that on a much to small smartphone. @blad: nice you have found it.

I think i need to sleep

Also don't miss to throw an 404 error, if there are more url-segments than there should be and if the used segments are not valid.

Just a heads-up: I put (almost) all of Apertus' features into an aforementioned fork of Reno, "SuperReno". https://github.com/marcus-herrmann/AdminThemeSuperReno When you're logged in as super user (and have configured the environment in the theme's settings), you will see the following. On the other hand, SuperReno looks just like Reno when logged in as non-super user.

The GetStarted module has it's own thread now: https://processwire.com/talk/topic/7666-getstarted-a-module-that-helps-first-time-users-to-understand-processwire-faster/#entry74360

Hello from Holland, This is my first post. I love the approach of this CMS, great work! Is it possible to make a sortable list of items or contacts? Each item links to a detailpage. Is there a module or guide? I'am no coder. I have included an image.

I think the rewrote looks really good. like diogo pointed out, experienced PHP devs will probably see the possibilities PW brings and use their own strategy. having the "direct output" as the default profile and then adding the "delayed output" version as an alternative seems like a great compromise (if you're ok with maintaining both).

@adrian Works great here now. Thank you for the work on this module!

Thanks again! I just spent some time revisiting this a bit. It's a bit more complicated that just removing trailing, commas, spaces, tabs etc because it is possible that these might be intentional if someone wants an empty value for the last field on the row. I have implemented a bunch of extra checks to make sure fields/pages etc can't be created without a name, so you shouldn't ever get the unnamed field issue anymore. I have also tried to make sure that the first row has no leading or trailing misc stuff so that the fields get properly created. But with the subsequent rows I allow trailing commas with nothing afterwards in case it is meant to be blank. I just tested with this mess and it looks to be fine: , ,Title, Number of Beds>Integer, Number of People>Integer, Kitchen Facilities>Text ,Single, 1, 1, Fridge Only, Double, 2, 2, Fridge Only Suite, 3, 6, Full Kitchen , Would you mind trying again at your end to see if I have still missed something? Thanks Adrian

You have my email

Hi there You can read it all here: https://processwire.com/about/roadmap/ enjoy the read

Thanks again Steve - great 2¢ suggestion I have set it up using your second option and I think it works great. I have also added a fix for the blank fields / extra commas issue. Please let me know if you find any problems with it.

I thank you Soma for taking time to respond to my questions and LostKobrakai for giving some good feedback on my selectors. That is a fantastic bunch of info that you have provided, and really does help me to understand the platform and the methods that I will need to employ to complete this. This is just a general search before I get to any filtering or sorting. This search just needs to return a more complete and less filtered result list that holds items that are just generally associated to the query. Mostly what I see that people will search for is something like Artist Name | Artwork Name or Artist Name | Medium or even just a search for Tag. From here they would filter their search based on department, year,price,medium. The reason that I have used so many fields is mostly due to the fact that I am also creating descriptions specific to the templates, so that a very basic user would be able to interact and understand what they had to enter in order to make an item display on the site, I also am working with another developer friend and wanted to try and keep the variables in a naming convention that they would hopefully be able to intuit their meaning easier. The data that I would like to be searchable is pretty basic as it would mostly be just the items themselves, and all of their relevant metadata. About 80% of this site will be this template (items): title contemporary_artist_selection - links item to their artist. As items may be in different parents or sections the artist will be selected using a page field so that it can be located globally. artwork_year artwork_ed artwork_medium artwork_dimensions artwork_price artwork_sale_information Tags artwork_description gridSizer - used for markup and will not need to be searchable artwork_img - used for markup and will not need to be searchable meta_description meta_keywords So now at I'm a bit of a php noob so I didn't realize that this was not going to work, good to know . I suppose I would have gotten here in the end, but I really appreciate you helping me on this. This is when I get to the EUREKA moment. Your suggestion would be perfect for this. I could create a cache field that held all of these fields in one field and just reference it for my search! So now to look into creating this functionality and using this instead of trying to search the specific fields in the beginning. I can then run more specific searches based on user input. You Soma are a GENIUS.

Hello, I've got a list of bookmarks of interesting desktop-based and web-based applications related to all this, but the list is not organized, I'll try to do it when I have more time. For information, and perhaps to have some ideas, there is this one (web-based) at least : https://www.odoo.com/page/download (Windows and Ubuntu installers are available). Online Demo: https://www.odoo.com/start There are, for example, Project Management, Billing and Accounting. For accounting, while configuring at the beginning, you can apparently choose the Germany accounting package and the accounting (plan) model: Configurable Account Chart Template, Deutscher Kontenplan SKR03 and Deutscher Kontenplan SKR04. I remember also at least one desktop-based application quite complete. (And there is a fork of Odoo (Ex-OpenERP): Tryton, with a desktop-based version still available.) I'll really have to organize all the bookmarks related to these subjects . In fact all my bookmarks (in the different browsers and computers I use). I often also prefer desktop-based apps when available.

Sure. This is the structure, nothing special so far ("Zubehör" is "Accessoires", a hidden node). Under that node, the client can build accessoire categories and in that single items. These items can consist of several different item variations and multiple images. This is the UI for the accessoire items: You see the Pro Field Multiplier for the item variations (unfortunately I had to double/triple that because it is not yet multi language aware). Will try to extend the language field tabs for also tabbing alternate language fields. Each product has a page field for selecting either accessoire items or whole categories: In this accessoire template I then list the items and them into the accessoire tab. The product features are filled with the ProField textarea, in the template I only render the features that are filled. One special here: German is master data, for language variations they only have to edit the changed feature. If you have further questions, go ahead! Thanks, fixed. This is just a helper navigation item for mobile, I forgot to redirect it to the first child. sure, will tell the client to rename it. Thx again!

This sounds like a great idea - I am very intrigued by the enhancements you have added and would enjoy having them, but I honestly don't think I would ever install it because I like having access to the latest improvements to the core modules, rather than waiting for these to propagate to third party modules. I would love to see a way to extend themes, rather than needing full replacements. Maybe we need to propose something along those lines to Ryan? From what I understand Reno is an extension of the default theme, because you can't use Reno without default also installed, but maybe the process can be refined to make it easy to extend with some minimal code.

If you don't have include=all in your selector, there's no need for has_parent!=2. If a visitor (guest) user searches it won't return those in admin anyway, only for superusers. It's generally a good approach to specify templates you actually want to search only. Also you can only have one "has_parent!=2" in the selector, so you couldn't use it for if you need it to restrict a search to a branch. I don't think there's one simple answer to building a search like this. I'm not sure about what exactly are the details here, and what is important to be able to search. It really comes down to what field you search and how. Relevance, as far as I know only works with a single find(), using full text search on a single text field using * or ~ , this will return the results sorted by relevance already, everything else won't give you relevance. By the glimpse at your code there's would be a lot of overhead and using this approach won't ever give you a relevance search results. Of topic: if (count($word)>3){ you can't count string only arrays if(!$matches) This doesn't work. A PageArray if empty doesn't return false, you'd check with if(!count($matches)) So what to do? I don't know an answer to what you should do. In general you seem too have a lot of fields, that seems unnecessary and could be simplified and reused, instead of having 3 "xname_description" fields, you could have one "description" field and use it everywhere. This will help reduce the fields to search for at least. Building search once you enter a complex setup with lots of fields and pages and want ot have relevance you might be best up to create indexes, like the cache field to combine text fields to one (hidden) cache field, that you would then search with a single query.

No need to store something here ... $pa = $pages->find("template=basic-page"); $content .= $pa->render(); $content .= "<a href='{$page->prev($pa)->url}'>prev</a> "; $content .= "<a href='{$page->next($pa)->url}'>next</a> "; This is the same on all those pages, as they use the same template. Works fine.

Updating Blog version 1 to Blog version 2 Note: some paths have changed. You will have to update such paths in your template files. Please see point #10 below 1. Log in as a superuser. 2. Backup your site! (For good measure). 3. Update Blog version 1 to version 2. Grab version 2 in the previous post OR from Blog's dev branch in GitHub 4. Paste the contents of the attached update script (blog-upgrade-version-1-to-2.txt) at the very top of one of your site’s template files. This script will create a ‘settings’ page under ‘blog’. The fields in the pages ‘blog’ and ‘posts’ will now reside in this new settings page. Their existing data will be copied over to the settings page. There will be no data loss. In addition, one extra field called blog_small will be created and added to the settings page If you want to enable the Auto-publish/unpublish feature FIRST install the module SchedulePages. Second, uncomment line #41 in the update script AND comment out line #40 of the script before copying and pasting. Save the template file. 5. View a page that uses the template associated with the template file in #4. 6. A success message will be displayed if all went OK. 7. Undo the changes to the template file in #4. Save. 8. Go back to your site’s admin to confirm things went fine, in particular: Check that a ‘settings’ page was created under ‘blog’ View ProcessBlog’s module configuration settings page (admin > modules > blog) by clicking on its settings button. You should see a message about Blog already fully installed Visit Blog Dashboard to confirm things went OK. If you enabled the Auto-publish/unpublish feature above, you should see two extra date fields in the Quick post dashboard (‘Publish from’ and ‘Publish until’). Similarly, edit one of your Blog’s posts pages. You should see these two date fields as well at the very top of the page. 9. Manually remove the now redundant fields in the templates ‘blog’ and ‘blog-posts’. Template 'blog': fields to remove: Blog Title - 'blog_headline' Blog Tagline - 'blog_summary' Footer - 'blog_note' Quantity of posts to show on blog homepage - 'blog_quantity' Template 'blog-posts': fields to remove: Posts truncate length - 'blog_quantity'. This will now become blog_small in settings page 10. Edit your template files paths that pointed to these fields you’ve just removed to now point to their counterparts in the settings page, e.g. $pages->get('/blog/settings/')->blog_quantity; That's it. You are updated. If you want to, you can now even rename your Blog pages to whatever you want (within reason of course ).... Enjoy! blog-upgrade-version-1-to-2.txt

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

I personally would not welcome PW becoming as popular as WP, and there is no need for it to be so. It is not competing with the mass market appeal of wordpress as it is in a completely different market sector. Huge numbers of users does not equate to a good product, just an overused one. It is not possible to have commercial templates for PW as it has no templating system - how would you know what people call their fields? Do you want to tie people down to only one sort of field name/type/strategy? Do you want to restrict people on how they construct templates? Many of the devs in here do not use a header/footer type system. As soon as you introduce a templating layer (Like Joomla has, for instance) where if you want to do something completely different you have to bung in a ton of overrides, you now have a bulky, slow system again. The advantage of PW is that this is completely missing - this is a good thing. As for standards, everything is built on the API and PHP - that is ALL standards. Any professional can build modules quickly and easily, though for most things like galleries, dancing frogs, and the rest there is no need whatsoever. Why limit people to restrictive module systems when they can just go and grab ANY bit of JavaScript out there and simply drop it in? As I said before, if you want to use PW as a WP clone, then create a profile that has all that sort of functionality - but that is a different product, not PW itself.

Such discussions are very difficult for non native speakers but i try my best to harm nobody. since Norbert and Argos were members of my former community, too i have some thoughts on this topics and maybe the reasons of such wishes... We all came from a former real big community with worldwide devs and contributors. The former CMS we used was one of the real big ones that was in use, but in lack of marketing and a scary name "WebsiteBaker" it was not so big public visible.....kinda like PW too. This websitebaker was a great cms (now development is stagnate for the last years) with a easy mediaadministration, simple templatesystem (php), pagetree, one site could have a different template and unlimited sectionblocks where a sectionblock was a addon like a form, gallery, wysiwyg, poll and so on. Cons are that every addon produce own HTML output, not easy to setup, update for a dev. -> But easy to get a website up and running fast.....with strong borders and limits. -> Former CMS was like a setup a db -> install -> install a template ->install some addons ->fast result! But Processwire is a different thing and i've to strict confirm the "hero" and "distinguished" members on theire points! Just some background on my person the short story: - i'm a web-hobbyist, - i studied agrobusiness, - my family have a little farm in southgermany, - i work in a ngo, since a couple of years i've a small business helping people - especially from the agrobusiness to get a more "pro" website up and running than a "standard hoster websitebuilder" could even with a small budget and the very most important thing easy to use/update so they get along. My understanding for OpenSource was always that if you use such piece of code you have two options 1. contribute with your time 2. spend money to push such good work! Since my projects all have a small budget (with some less exceptions) i always try to invest some spare time to contribute, help in forum, try to code something....(In former CMS i was a forummod, wrote several tutorials, assisted several addondevs with translations and testing, started a project for a portable version with preinstalled version on a WAMP server2go) I've not a webdevbusiness to make a living - but since i'm a economist i understand one simple goal/rule: What is good for the client is usually good for me if i running a service with one big exception -> if the good thing is that the client don't need my work anymore! So we talk about "make it userfriendly" or "make it devfriendly" ? i think processwire is a great tool for both devs and users, since i could make the website (and the backend) for my clients real userfriendly without limitation like other cms have. So it is "friendly to me" and after all my work it is "friendly to the enduser"... I don't think that standarisation would be good here - i like particularly that a pro user could adapt a MFC template system and a nonpro like me use a simpler technique. Yes PW more a CMF than a CMS but this is great for everybody that creates professional websites or even apps. @Argos: i think there is a big misunderstanding about the "user" - i think you mean with user -> somebody that use/install/build a site with PW? but i think others here might think user -> client that use/work with a fine adjusted ready to work installation of PW? No offend to you (i honor your work that i know from the last couple of years) and like i said it is hard in a non native language but i try to ask: Since i'm a complete self educated person (no design education, no programming edu) i think that in current times of webdesign nobody without some skills in coding or a partner that devellops for him could stand in the long-range. We live in times of using explicit combination of javascript (if not required for a website - but surely for a app or mobile website), serverside javascript via node.js is on the way, the morst good CMS all works with PHP or even a own language like typo3, preprocessors for CSS like SASS and LESS, JSON data for serving different things, imagehandling for responsive design and so on... since we work with computers and software - all is code - i thought even drawing is just math? @Norbert: there could be indeed more examples, easyer entries for new users -> that wanna try out PW and install it. But hey that is something to do - nothing to write about it. I know you are a experienced programmer so you've no problems to setup a website for a customer "userfriendly" so why this is such a big topic? For my first project i take the time to setup the most things you've mentioned so i can recycle them easy for the next ones... PW is hard for the first beginning - if - you don't search the forum, don't look at the example code in the templates, read a lot of posts, dig through the doc is fun while you learn fast....the tuts in the wiki are old but working. To change this only simple things are to do. Take the 2.5 create template and fields and use the export - share it - so a new user easy get it work with one click and import such examples like a setup for a calendar, news and so on. Or write some tutorials.....if my first project is finished i will do share my learning for other newbees...like other users here did before. @all former other CMS users: PW will/should never be like a other CMS or your former used CMS. Just switch your minds and start to change the way you thinking before - and you will be surprised. I felt in love with pw in lets say about a 30 minutes trial I get the first grasp until lets say the next 3 hours I belief i'll stay for ever in the status Newbee since every day i read this forum i'll learn new things from this great community Best regards - Martin

Last reply for today, and only because I sneaked in the phone when I shouldn't anymore if you are a professional site creator, and want to do it well, honestly you have two options: or you partner with a coder or you become a coder. As you said, it will make your life much easier. If you want to become a coder, in my opinion there's no better tool than PW, and no better place than this forum. I hope you won't feel discouraged by this talk, and that you stick around. start with the basics, without hurrying, and I'm sure that in some months you will be surprised with how much you learned.

And what else should be in the core? Forum? E-commerce? Local finances tax systems? Should we vote and have in the core the most popular features? Or should we leave the core light and efficient so that even an average developer can quickly create any of those for their clients? Should PW be aimed at the regular Joe that wants a blog like all the others in one day, or should it be aimed at the regular Joe that is willing to pay a competent PRO to create a customised solution? There are dozens of good CMSs made especially for that public, like http://www.couchcms.com/ or http://www.surrealcms.com/ or even http://grabaperch.com/ . These tools don't try to be more than that. They have a focus, they follow it, and they do it well. Pw is actually a very simple system (in the way you mean it), but yes, it is directed at coders and everyone willing to learn a bit of code. But it's not only usable by coders, they are only intermediaries who make it usable by anyone with a business who wants a website. In that context, the potencial users that know HTML/CSS but are not willing to learn a bit of PHP become a much smaller percentage.

What you described here is the opposite of PW. Call it what you want, but if these are your requirements for a tool to call itself a CMS, than PW is not —and won't be— one. This can happen with site profiles though. We only have to wait that they appear, and they will with time.

I switched CMS too......I've the comfort of a small project without a deadline. But learning PW is faster as any other cms ! As fast as this forum and the real talented users share and awnsers

This is the only way I know to create different sizes when uploading images: <?php class ImageCreateThumbs extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'ImageCreateThumbs', 'version' => 100, 'summary' => '', 'href' => '', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHookAfter('InputfieldFile::fileAdded', $this, 'sizeImage'); } public function sizeImage($event) { $inputfield = $event->object; if($inputfield->name != 'images') return; // we assume images field $image = $event->argumentsByName("pagefile"); $image->size(120,120); $image->size(1000,0); } } https://gist.github.com/5685631 What I don't know is if it really makes a difference (I guess), and if using drag and drop ajax upload and old school upload would process image one by one. My suggestion is to also upload image already in 1000x* pixels because if they upload 3000+ px images it will just takes a lot longer.