Pete

I point people to Facebook and Google as massive PHP adopters. Not sure which part of Google, I just read somewhere that they use it a LOT. It is an outdated viewpoint and has been for many years - all the cool kids now use PHP and benefit from it's rapid development cycle compared to other languages. Sure, there are some neat things in other languages that aren't yet in PHP that others love to scoff at, but at the end of the day it's perfectly good for 99.9% of the people using it. and, yes, massively scaleable as long as you've got the programming skills and the server power.

The problem with my idea of a "simpler" blog profile is that if I build it it's going to feel a bit wrong as it will throw some best practices out of the window to essentially "dumb it down", so if I were to attempt that then I might feel a littly dirty by the end of the process

Bearing in mind what Joss wrote about different languages needing to explain to their web developers in different ways (better ways of structuring an introduction to a product, local knowledge of what re the key points for that country etc), I think a rough structure for these localised sites would be something as simple as: Introduction to ProcessWire and what makes it different Local language videos and tutorials List of local developers (local site admin would have to approve entries and needs something like FormBuilder managing new entries to this I think. Local jobs board - this could be clever as you could post a job and specify whether you want to advertise only to one country, several, or all - the beauty of Multisite From another topic last year, in my head it's coming back to something like this: http://director-ee.com but whereas that's more about devs and jobs I think the localised introduction and written/video tutorials would make it stand out more.

I guess the next question is how to handle it ryan? Would you see each local site being a separate PW install using the new template or is this something for multisite with a few trusted authors? I guess in the case of multisite we're not looking to reproduce the main ProcessWire.com site anyway (actual content can be discussed later on) so it could share some common core. If we're thinking about each country and going so far as to having a list of devs that know ProcessWire from each country to show there is broad usage of ProcessWire then it makes sense to also have us.processwire.com, uk.processwire in addition to de, fr, fi etc etc. That way we could just set everything to use templates and DB from us.processwire.com maybe? Just a thought.

I think why I like the idea is it's "officially unofficial" with no worry about domain names. But yes other local sites are welcome, my thinking was that Nico's idea would be a good way to show relatively quickly that we care about every country and supporting everyone.

I was thinking AJAX search functionality would be good so I agree there. Since not everyone types in image descriptions it should search the page title too I think, as well as even the summary field. In fact, that could be a setting too - which fields to search on

I found Lemonstand is a bit easier to understand from a templating point of view, but with any of these systems it's bewildering as Joss says - especially compared to the E-commerce module Antti has made where you build your site as normal with the visitor in mind and then simply add one field to a page to make it a product. I know that's a shorter version of how it actually works, but it is MUCH easier and you're focusing on getting it right rather than wasting time on learning another system and wrapping your head around yet another templating system.

Glad you added that last sentence Joss, I was just thinking of how long the "loading" icon might take otherwise I actually think it might be best to have them show up from all other pages but categorised first. The logical categorisation would be based on the template name when I think about sites I've done, so "Gallery", "Campsites", "Cakes" in some of those cases, or "Skyscrapers" in ryan's case I was thinking about trying to categories them by the page parent, but that doesn't work really as many would be under a title of "Home" on a lot of sites. I think that if this idea progressed further that categorisation by template wouldn't be a bad idea, but should be optional as it actually requires you to have thought about your template names and structure a bit

Oops! Well having the templates is good, so even if you can't remember what fields you added the template code will give you an idea

Bless Google cache: http://webcache.googleusercontent.com/search?q=cache:TUGVrtwwgcoJ:process.besser-landen.de/+&cd=1&hl=en&ct=clnk&gl=uk&client=firefox-a

@ray - I was thinking that it would start with a "this is how you post in ProcessWire" so that you're showing the end-user how to enter content in ProcessWire as opposed to WordPress. At the basic end, this shows them that it's really simple and nothing to be afraid of. Then a simple 30 second bit at the end that adds a field to a template (shorten the sequence maybe) and show them how easy it is to do that for the slightly more adventurous Wordpress user. I think we just need a direct comparison as a starting point - this is how you create a "post", upload images and insert them into the "post". Then if we skip the bit where we setup categories and show them how easy that is we've pretty much covered a lot of it. Someone has already developed a tag field too but I can't seem to locate it in the Modules directory. @Joss - I agree. Ryan's profile is excellent out of the box already but - no offense ryan, and I think I've said this before - I wouldn't mind seeing a version that is even simpler code-wise. I know functions are the sensible way to go, but a version with more of the PHP code inline done neatly would probably appeal more to beginners and those WordPress users that are happy enough to dabble in WordPress' template code but not comfortable with functions etc. Something else to go on the list I think are a few alternative themes out of the box, but I think we've talked about that before. It's not really something you need to think about with ProcessWire as you can do what you like template-wise, but I think a few choices of killer designs would certainly entice people in who don't have the skills to begin integrating their own templates, but that would certainly like to learn over time.

Hi all, just a quick note that Nico posted a reply to this topic in the wrong topic, then I replied to his reply thinking we were both talking about this topic - basically go up five posts and read the posts that come after that to get up to date

Hi Luis Any chance you can post a screenshot? I'm trying to describe this profile in another forum topic but the link seems to be throwing a ProcessWire error.

I forgot about the config option - seems like the most sensible solution since page IDs don't change and after initially setting these in the config you would never have to change them again.

Here's the topic I was talking about where Luis was working on a profile: http://processwire.com/talk/topic/1732-shop-for-processwire-apeisa/?fromsearch=1 Unfortunately the link seems dead, but from memory it was quite far along Joss so it might be an idea to ask Luis for a screenshot. I thought it was extremely promising in that it was almost ready in terms of how it looked, so if it can become a community effort then we might get one profile ticked off very quickly

@Nico - I blindly replied to your post thinking we were both posting in the topic about local PW sites - did you mean to post in that topic instead? If so I'll move our posts over there

I'm going to state the obvious here and point out that you shouldn't change a site's structure that significantly after launch anyway. Having said that, I wonder if the best way of doing this is something like the PageHistory module that tracks page locations and renames (I think that that module only tracks renames but it might do both). Then calls using the API like in your example could be routed to the correct place (pretty sure that that module does'nt do that yet but I might be wrong!).

I remember playing with Antti's module a while back and it works well from my limited time with it. I actually wish for one job that is now an uber-customised Lemonstand installation that I had put some time into working with this module, but there were time constraints and I didn't know as much then as I do now about ProcessWire and modules. From what I've seen though even a PayPal module should just be a case of a few hours' work and you get some neat benefits with ProcessWire of being able to make any page a product etc etc. I think at one point someone was working on a profile for it that made the default layout look more like a shop and it looked really impressive - I just can't find the link on my phone.

I'm with Nico on this one - I like the idea of local sites very much, but if we can approach it with subdomains we can standardise a look and feel much more easily as well as work more closely together on what we feel could be covered on the local sites. If we could pull together on features and content for this we could maybe even use the multisite module and translate some common content into various languages. We might also benefit from it looking more "official" this way - it would acknowledge that the dev team (ryan, but I'm thinking like a customer) cares about engaging with and supporting customers across the world. Just out of curiosity, how many German/French/Finnish etc CMS systems are there out there? I mean ones developed with English not as the native language? Also how many developed by English speaking countries where the devs have actually bothered translating parts of their official site or offering country-based portals? I'm extremely interested to see if this might be a relatively simple way to draw in a much larger user base by standing out from the crowd

I think it may have been discussed before, but some videos here on ProcessWire.com showing an easy conversion of a WordPress site might not be a bad idea. Since the basic elements of most Wordpress sites are the same it could just be as simple as a comparison of what you do in Wordpress as opposed to how you do it in ProcessWire. Off the top of my head, you would start with how to make a post in either system which is 99% of what they do on it, before showing them the technical possibilities by adding a custom field in 5 seconds in the admin, then adding it to the template and blowing their minds with the possibilities. What we really need is a series of videos like this comparing things I think as they don't know how easy it is unless you show them.

There are a few ways to do it, none of them straightforward 1) Modx had a lot of extra forums for discussion in each language om their main forums. Whilst i can see the point, I also think it leads to less sharing. 2) Local sites per country. I think this might be the answer, bit if each has its own forums then you run the risk of fragmentation again. 3) Making the main Pricesswire site multilanguage - this is actually a great idea, but there is a LOT of content to translate. If you can hook it up to localised domains though that would be amazing! I like option 3, but option 2 is more easily achieved. If there were to be localised sites with forums then that's fine, but personally I think it would be best if support requests were somehow handled on these forums and that's when it gets a bit messy. And a huge amen to Adam's rant But I understand the difficulties in choosing to say no to that person if there is several months' work on the line too.

If it's a page field (I think it is) then you need to edit that field, click on the Input tab and set "Label Field" to "title".

Hmm, good point. Maybe some tables are in need of repair?

This: $field = $fields->get('$dati_auto[$i]'); Should be without single quotes, like this: $field = $fields->get($dati_auto[$i]); Otherwise you are treating it as a string.

Only thing I can think of is maybe mySQL has crashed - I suggest restarting that.