adrian

Thanks @flydev - it's fixed in 4.16.13

Ummm - none of the menu items at the top of their site work ? The last update was in 2011 ? Are you actually serious ? Sorry if you are - maybe it is actually awesome ?

Ryan - I think this is really important!!! Earlier (https://processwire.com/talk/topic/20596-new-post-new-pw-website-ready/?do=findComment&comment=178332) I mentioned all the different ways to get $page that are listed on the variables page - turns out there is of course another $wire->pages which you don't mention there, but you do mention on the bootstrap page. I am not sure how to best clean this all up, but I think it makes things very confusing. Perhaps the entire website should stick with "$page" etc in all examples and wording, but then there is one dedicated page that explains what version can be used when/where and the pros and cons of each.

I've been using Forklift (https://binarynights.com/) since I switched to Mac in 2011. I haven't found anything better to take me away yet.

Actually, what you want is this:

According to the docs it doesn't keep <p> tags: https://processwire.com/blog/posts/processwire-3.0.101-core-updates/ What you want is keepTags so you can specify the tags to keep - I think the only catch is that you'll need to specify a lot more than just 'p' like in my example. Perhaps keepFormatTags should include <p> - maybe something to mention to Ryan on Github?

Back to the idea of the demo site having a Tracy Console - esque sandbox/playground with pre-saved API examples. Obviously this is just the Console in its current version, but you can see that I've saved the examples from the new homepage into the snippets list so that users can select and run them and edit as they wish. I think with a bit of work this could be cleaned up nicely to work as a way for users to see just how great the API is.

Regarding those API examples on the homepage, there is an error in the first one: echo pages('/')->children->each('<a href='{url}'>{title}</a>'); Exception: syntax error, unexpected ''>{title}'' (T_CONSTANT_ENCAPSED_STRING), expecting ')' You need to replace the single quotes around {url} with double quotes so it looks like this: echo pages('/')->children->each('<a href="{url}">{title}</a>'); That said, I don't like this example - firstly there is the use of the functionsAPI (which I mentioned above will be confusing unless you are planning on turning this on by default in new installs), but also it outputs this with all titles on the one line. Perhaps a more useful example would be this, especially given that you state it as: "// Render your site’s primary navigation" This is OT, but did I just discover a bug with these? EDIT: https://github.com/processwire/processwire-issues/issues/779 This doesn't work: but these do: Why does getting the homepage ('/') in the first example NOT work?

At the time that @kongondo looked, it was linking to http instead of https which was the problem. The current link works for me now also.

Another issue that relates to my comment about the title of parent level pages being displayed in the header next to the PW logo. Typically the text of that title goes to that parent page, but in the case of the search page, it goes back to the homepage, eg: http://processwire.com/newsite/search/?q=tracy - I feel like this one should at least reset the search page to: http://processwire.com/newsite/search/ which actually brings up another issue - if you end up at this page, the search input field is poorly placed over on the right - it needs to be larger and left aligned and also it should not respond with "No matches found." when no search term is entered.

Can you please disable autocomplete on the site search field - the browser's results get in the way of seeing/clicking the ajax returned results.

Most of the links on this page https://processwire.com/newsite/docs/modules/types/ are broken - check out AdminTheme and all those below it.

Not sure I like the showcase thumbnails in the right sidebar on some of the about pages, eg: https://processwire.com/newsite/about/why/ - they seem out of place to me and it's not actually clear what they will take you to.

Speaking of mobile: There are several padding issues - see screenshots below with various buttons. There is also always a horizontal scrollbar. Not sure about the color scheme of the hamburger menu - it looks like it doesn't belong. The search box in the hamburger version is not ajax - is that intentional? I feel like the breakpoint for the footer prev / next links is off - they end up on top of each other, rather than side-by-side on quite wide screens. Not mobile specific, but just noticed that: https://processwire.com/newsite/docs/modules/types/ doesn't list WireMail as a module type. Also, should the naming conventions section list "Process" modules?

Ryan - can we get a new favicon for the site?

Just committed a nice little enhancement to the Adminer panel - it now loads the panel with the relevant table or row based on the current context. So if you are editing a page, it will load the row for that page. If you are editing a file, template, or viewing a module's config settings, it will do the same. If you viewing the main page list tree or the main templates/files/modules pages, these tables will be opened in browse mode. Probably not something you'll use that often, but because the Adminer panel doesn't load anything until you open it, I like leaving it activated as one of my default panels so I always have really quick access to view whatever is in the DB for what I am currently working on. Anyway, hope you all find it useful on occasion.

I would also say that it should also mention JS libraries, scripts, etc. No need for a plugin for a simple JS carousel etc.

@bernhard - I'd love to see something like this - this is exactly the skinning type approach that I think is needed for the PW admin. It makes so much more sense compared with creating new themes in most situations.

Try this link: https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2F&amp;css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-1.css

There have been a few recent comments about the text in various sections being too verbose - I'd just like to mention that I agree with this ? I am not totally sure I like @3fingers re-colored version, but one thought I had yesterday before I saw it was that I find it quite a harsh change going from the simple single blue color of the new site to the multi-colored admin panel in the demo. I am not saying that the website and the PW admin need to look identical, but I do think it looks so different that I feel like I am somewhere else with a different product. @3fingers version ties the two together, although I am wondering if maybe the admin should look more like the site by default? I am not suggesting any change to the admin immediately, but something to think about?

Hi Ryan, Not exactly sure how this would look or work at the moment, but what do you think about having the Tracy Console panel available on the demo site so that users can play around with the API. I am thinking of having some snippets in the snippet sidebar already saved so that they can load those as starting points / examples. Some examples would show using d() calls to return objects, but we could also have some with echo outputting actual HTML with PW variables embedded. Think of this as ProcessWire codepen / fiddle type feature. Obviously save operations etc would have to be prevented so they can't damage the demo site. On another note, maybe down the road users could have access to their own demo site like Wagtail does (https://control.divio.com/demo/get-new/wagtail/) where the user can actually edit page content and see the changes on the frontend - a little like the old lightning.pw Anyway, let me know what you think about the Tracy Console idea.

A few more thoughts: I feel like the Selectors page (http://processwire.com/newsite/docs/selectors/) needs to be more prominent. To me, this is more useful than the current "Getting Started" and "Tutorials" pages. Or at least, it should be a page that is listed on the Getting Started page. Speaking of the tutorials page, I don't like that most of these are external links - even though they are great resources, I'd rather have users see a centralized source of the best tutorials on the PW site itself. I don't like the pages that put the title next to the PW logo in the header, especially given that not all pages do this - I know it depends on what level page you are on (although not entirely), but I still find it a little confusing. I also don't think that the "Community" top level link should go anywhere. On the variables page, you have: "page() accessing as a function can be very convenient, when available." - how or why wouldn't it be available? I know, but new users won't. This one: $pages->wire('page') is actually quite confusing - again, I get it, but certainly never thought to use it like this and I think it would be really weird to do something like: $pages->wire('fields') I would say this option should not be shown. I also am not sure about showing: $this->page when on the very next line you state that: $this->wire('page') is more efficient - why would anyone want to user the former? Sorry for all the negative, but you know how feedback often is ?

I would go with the first image for the existing posts and then from now on you could make use of a "feature image" option.

Overall looking great. Just a couple of quick things - I'll try to dig in deeper later. I think The API examples using a mix of $pages and pages() is confusing. I would stick to one approach The demo site should be running the latest stable which is currently isn't I'd like to see a Github link on the homepage or preferably the footer for all pages. I think it gives an open source project legitimacy and advertising this upfront can be an important thing for swaying someone to look around further. On the site directory, is there a reason for the category order? I think it's especially weird that "Newest Additions" is second. Speaking of the sites directory - are you running a regular check on all these site (using @teppo's isit.pw) to make sure they are still powered by PW - I think it looks really bad for PW if a listed site has been moved to another platform. The "What you'll love" page is so long. I saw the TOC links at the top and didn't initially realize that they scroll down on the current page. It seemed link too much to look at - where do I start? This page (http://processwire.com/newsite/about/requirements/) lists PHP 5.4, but this one (http://processwire.com/newsite/docs/start/install/new/) says 5.3.8 still. At the bottom of http://processwire.com/newsite/docs/start/install/new/ you state: "See our download page for additional download and installation options.", so I think it should link to http://processwire.com/newsite/download/core/, rather than http://processwire.com/newsite/download/ I think the master and dev download buttons on http://processwire.com/newsite/download/core/ should show the version numbers Afraid I don't really like the blog page - I feel like the blocks are too confusing - I'd rather a more normal vertical approach and an image (when available) to go with each summary. I was surprised that Page Reference fields are not listed here (http://processwire.com/newsite/docs/fields/). BTW - I think that all docs needs to use "Page Reference" rather than just "Page" because in PW "Page" is already used so much. BTW - thanks for the link to Tracy from http://processwire.com/newsite/docs/more/

On some sites I actually have a "menus" tab on the homepage and in that tab there are two page reference fields: one for top menu and one for the footer menu. This way the site editors can easily adjust which pages appear where and none are shown anywhere by default.