ryan

The opening <p> should already be there since its a TinyMCE field. But if there were any posts still in place that hadn't yet been saved with the new TinyMCE field, then this could account for it. I think the fix would be to go and save all the posts that don't yet have TinyMCE markup. Or account for either possibility in the code: if(strpos($page->summary, '<p>') === 0) echo substr(trim($page->summary), 0, -4); else echo "<p>" . $page->summary; echo "… <a class='more' href='$page->url'>" . __('View More') . "</a></p>";

Just launched this site a few minutes ago. It's not totally done, as I've still got some detail work to do, but figured it was at a good point to share: http://www.houghtonacademy.org I did the design and development on this one. Like the blog profile, this one uses the Skeleton responsive CSS framework. Though I went a lot further with the media queries on the mobile side than I did for the blog profile. So you should see a nicely optimized layouts for tablets, mobile portrait and mobile landscape. So far only tested on iPhone though. Many of the graphics (though not all) are also optimized for Retina displays. When you get to the homepage, you should get a different photo and tagline on every page load. Highlights (in terms of ProcessWire development): Faculty Directory: http://houghtonacade.../about/faculty/ The data for the faculty directory is updated once daily and it pulls from a service called Veracross, that manages all their school systems. They are all represented as pages in ProcessWire, so the client can add unique biographies and such that aren't present in the service it pulls from. Form Builder is used throughout the faculty directory to power the individual employee contact forms. Events Calendar: http://houghtonacade.../news/calendar/ The events calendar uses jQuery plugin FullCalendar and it pulls from a ProcessWire-powered JSON feed. ProcessWire gets the data from a Veracross feed a few times a day, caches it, and creates a new feed specific to use with FullCalendar. The events data is also used on other pages in the site, such as the homepage. Photo galleries: http://houghtonacade...f/photogallery/ There are several photo galleries throughout the site, and they use the Photoswipe jQuery plugin, which is really great when using mobile as it duplicates the behavior of using the built-in iPhone photo gallery. Thanks to Soma for recommending this back in another thread. Video pages: http://houghtonacade...out/headmaster/ These are powered using the TextformatterVideoEmbed module and are responsive (per the latest update to this module).

This should work, but one [minor] thing to note is that I've setup that summary field to double as the <meta description>. You could go ahead and just create a new field and call it 'meta_description' (or something like that), or you could continue to use the existing 'summary' field, but you'd want to strip the markup out of it for placement in the meta tag: In /site/templates/main.inc, change this: <?php if($page->summary) echo "<meta name='description' content='{$page->summary}' />"; ?> To this: <?php if($page->summary) echo "<meta name='description' content='" . strip_tags($page->summary) . " />"; ?> (basically you just add the strip_tags). Another minor thing is that the <div class="post-body"> now has doubled <p> tags around that summary. That's because the it was previously assuming that the summary wasn't marked up. Since it is now marked up (TinyMCE), you'll want to do this: In /site/templates/markup/post.php, change this: echo "<p>" . $page->summary . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a></p>"; To this: echo $page->summary . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a>"; (basically just remove the surrounding <p> tag) If you want to have that "View More" link contained within the last paragraph, rather than on a separate line, you could do this (I think… writing in the browser here): echo substr($page->summary, 0, -4) . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a></p>";

That's correct, this is how it's setup here. The assumption is that "author" would be a limited access editor that you might only give access to post new blog entries, but feasibly you might give them access to add categories and tags too. So the role is setup and ready for you decide what you want "author" to be able to edit. I would suggest giving author access to edit posts, categories and tags, but not home or widgets.

I was actually thinking of adding a "Tools" menu to ProcessWire admin (in addition to Pages, Setup, Modules, Access). The reason for it is that we've now got a lot of tools that don't necessarily fit the definition of "Setup", so thought it might be handy to come bundled with another place like that. PW1 had such a Tools menu like this.

Don't give me too much credit guys. I've got all of 15 minutes invested in this particular module, and most of that was writing the instructions. But the subject came up on another thread and just wanted to have a proof-of-concept of how simple it is to plugin your own hooks to customize user access in any way you want.

Thanks Mike! Great addition -- I will update the profile to make this change. One thing I wanted to mention about this blog profile. I know that you are evaluating ProcessWire among other CMSs, and wanted to highlight that the Blog profile might not necessarily be the best single place to evaluate ProcessWire from. It's just one application/template approach among many that people use. I think that the Basic profile included with ProcessWire actually does a better job of revealing the inherent simplicity, and path-of-least-resistance, of the template system. Whereas the Blog profile gets into using ProcessWire in a more MVC front-end framework approach. So it was intended not just as a blog profile for people to use, but also as a next-step (from the basic profile) demonstration of a more advanced approach. This is a great approach to use, but I usually get people started with the basic profile before exploring this, and other approaches. I'm guessing you probably know all of this already. But even if this is old news to you, I figured I should also mention this for others that may be reading about the blog profile.

PW 2.3 protects file-based assets to unpublished or non-public pages, so this won't be a concern much longer. Matching up names is just one way to do it. I just put together a quick module that provides another way you could do it even more easily:

Assign edit access to individual users on a per-page basis The user must already have page-edit permission on one of their roles in order to get edit access to assigned pages. Otherwise, they will only gain view access. This module is fully functional as-is, but intended as a proof-of-concept for those wanting to go further with adding custom edit and/or view access. The main functionality in this module consists of only a few lines of code, so it should be a simple edit for anyone wanting to take it further. If you make some useful additions to it, please post them. How to use Create a new role called "editor" (or whatever you want to call it) and give the role "page-edit" permission. If you already have a role in place that you want to use, that is fine too. Under "Access > Users" locate the user you want to assign edit access to. Edit this user. For this user's "Roles" field: choose the new role you added, "editor" (or whatever you called it). For this user's "Editable Pages" field: select one or more pages you want them to be able to edit. Save the user and you are done. To test, login as the user you edited to confirm it works how you expect. http://modules.processwire.com/modules/page-edit-per-user/ https://github.com/ryancramerdesign/PageEditPerUser

Antti coded the HTML5 upload capability and may be able to speak to it better than me, but I don't think we have control over that particular order?

Great module Soma! Tested it out and worked nicely. Only thing I'm wondering about is the name: ProcessTools? How about something that better describes what it does, like ProcessPageAdder or ProcessBatchPages or something like that?

I wonder why this is the case, and if there's anything we can do about it. Seems unusual that Google's algo would be so different in Germany. I'm wondering if we need to do anything to indicate that we are "German friendly" or something to make Google like us better there. I would guess I account for 90% of the US traffic.

The result I reported was when not logged in to Google. Searching for Open Source CMS shows us on page 2, second to last result, and still does when I try it now. Tried it over the iPhone (AT&T network) just to confirm. If I'm logged into Google, it appears higher, but also says "You and Antti Peisa Liked this" or something to that effect. Also, we are #1 for the term Open Source CMF, but apparently that's not a very competitive term because I don't see it showing up in our search logs at all. I think there are all kinds of factors that can affect where something appears in Google, even from data center to data center. Though I am surprised it's now showing up for you. Can you double check? By Country: By Continent:

The latest version of Form Builder (0.1.7) now has a File Upload input type, so we're a little ahead of schedule on having this ready. It's currently in beta test, but available for anyone that wants to try it out as a download from the Form Builder support board. So for anyone that was waiting for file upload capability in Form Builder forms, we've now got it.

I think it just depends on the needs of the site. I'm guessing every site will have a little bit different needs. I tend to veer towards keeping no 3rd party modules installed for my starting point, and then install them as I need them. The ModulesManager might be the best candidate to have installed since it'll make installation and upgrades of any other modules a piece of cake.

Gazley, sorry I'm about a day behind on messages here. The error you are getting indicates the FormBuilder module is getting included twice somehow. I'm not sure how this would happen, so definitely a mystery. But since there was corruption in your fields table, it certainly seems possible there could be corruption in your modules table too (maybe 2 entries for FormBuilder?). And if there's corruption in one place, then there's very likely a bigger problem. Any idea how things started getting corrupted here? You might want to start with a fresh copy from your local server, because clearly something was lost in the migration. What version of PHP and MySQL is the new server running? I also think WillyC's suggestions are good, but they are plugging holes rather than finding what's creating the holes. I wouldn't be comfortable knowing that somehow the data in tables was changing after doing a simple export/import. Whatever is causing that is very likely the source of the problem. First thing I'd do is look at the DB dump file to see if it contains a proper entry for your 'summary_on_home' field. If it does, then the problem is likely occurring during import to your new server. If it doesn't, then the problem is likely with the export from your local server.

Interesting, I wonder how one gets listed there, or if it's just controlled by the owner of it. I looked around it a bit but didn't see any way to submit an application to it.

I'm not sure I understand the question, but I should be able to answer to anything Form Builder related. Can you post more details (in the Forum Builder support forum)?

This is a bug. I'd actually fixed this one a week or two ago on the dev branch but hadn't carried it over to master. I just put it on master so it should be fixed now.

I'd suggest changing this line: if ($pages->find("template=blog-article, tags=$tag")->count() > 0) { To this: if ($pages->count("template=blog-article, tags=$tag") > 0) { The reason is that find() loads all those pages, whereas count() just counts them... far less overhead if you don't need the actual pages loaded (which it doesn't appear that you do).

These should be in here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module For the multi-value version (InputfieldPageListSelectMultiple) it looks like I don't have those translatable in the master branch, but they are in the dev branch. When you upgrade to 2.3 (or use the current dev branch), you'll want to translate these two files (via the Language Support translation capability): /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module

Nice job. So far I can't think of any major pitfalls other than with Page reference fields. That is one fieldtype that has a parent_id property (or at least it can). But I don't see this as a major problem, as it would just require the person going in and double checking that it's pointed to the right place after the field is updated. Either that, or the module could be configured to disregard that particular property. We have this same issue with Form Builder export/import from site-to-site when a form contains Page reference fields. It's not been a problem--so long as you know there may be some loss of translation there, it's easy to correct. So overall I think the approach you are taking here seems like a good one.

Why is it called TinyMCE anyway? BigMCE or GiantMCE seems more appropriate?

You could also change the label with Language Support.

I've really been enjoying this module. This is a must-have development tool.