teppo

@Macrura: sorry for the slow reply, but.. no. This is loosely related to a discussion at GitHub, here: https://github.com/ryancramerdesign/ProcessWire/issues/566. I'd like to hear what Ryan has to say about CC, BCC and attachments before going and putting together custom solution for that. My opinion is that all of these should be implemented in the base class (WireMail) so that WireMail module authors (at the moment meaning mostly me and Horst) don't have to cook up case-by-case solutions. Even if the modules still required some customisation and couldn't use WireMail features out of the box, at least we'd have compatible implementations.

It's a good thing that ProcessWire has the flexibility of an Olympic gymnast. We can already extend it to so many different ways without having to somehow compromise the core package. Whether it's new site profiles, theming systems or whatever we can dream up, that's already doable. Doesn't mean that everyone has to love and use them, though. What I'm trying to say here is essentially that it's not away from you if someone builds a themable site profile. You don't have to use that, you are free to keep on doing what you're already doing. Relax. As an example of this from slightly different angle, I personally have a very strong dislike of so-called templating systems. From my point of view they complicate things unnecessarily and only result in worse quality. I'm still happy every time I hear that someone has built a cool templating system module for ProcessWire or a cool site using Twig / Smarty / whatever. That's good for them -- and what's good for them is usually good for the community. This is one comment here that really stuck with me, but not necessarily for the most obvious reason. I've seen many (nowadays) very competent developers emerging from the muddy waters of less flexible CMS'. I guess I mean that this works the other way around too; low barrier of entry brings in developers who might not be that experienced yet, but once they get the feel of it they can become very productive members of the community. Seen that happen here too. On the other hand, it's kind of sad seeing how some folks grow (professionally) in an environment that forces them to bad practices, and once they've reached a level at which they could do something really awesome, they keep trying to force that inflexible system to do something it was never intended to do, because it's the only thing they really know and jumping into another environment entirely is a scary thing to do.

This is great, Philipp -- thanks! I'm tempted to forward this to a few co-workers right away Two minor additions you might want to consider: a note about inserting images within RTE (mainly from alt tags point of view, but also that PW automagically resizes images, which in turn reduces unnecessary load) and Redirects module.

I'm going to agree with Nico here; a properly built theming system, separate from core package, would be a godsend. I'm assuming that nobody really means that, but I can't help noticing that every time a discussion about having more site profiles, easier installation for site profiles, some sort of theming etc. raises it's head, there's a sudden and mutual urge to kill it with fire. The way I see it ... Site profiles are not away from core development. Ryan doesn't have to spend his time working on these. Easy method of picking the profile you like during installation would be cool, but not necessary. Theming isn't evil per se. We don't need theming support in core, we can build it using modules (as Nico said) or simply using template level code. I've done both.. without losing my sanity. If someone feels that having easy-to-use site profiles and plug-in modules is away from hardcore developers and flexibility of the core itself, think again. These are not mutually exclusive things. Just my five cents. Take it with a grain of salt, please -- I'm in the middle of coding streak and just needed to vent my brain for a sec. Keep on keeping on.

@Nick: I'd like to point out that the approach you're taking is not what I'd advice on doing. It's very important to understand that ProcessWire is, first and foremost, a CMF. What this means is that it's very good at dealing with various content items (which it calls "pages"), describing the schema of those items, allowing you to manage them via API calls, define relations between them etc. Without going into too much detail about this, I'll just say that by using ProcessWire's own tools you are not just getting more benefit out of the system, but also more likely to build a solution that's manageable in the long run, easy to extend and update via built-in tools.. and, perhaps most importantly, as safe as possible (as long as you prefer API calls over SQL there's literally no way for SQL injection issues to creep into your code). What you are doing here sounds essentially like taking ProcessWire as a starting point but then coding an application that does effectively the same thing over and around it. This approach fits better one of the more bare-bones application frameworks (Zend Framework, Laravel etc.) It may seem like the obvious choice before you get to know ProcessWire's capacity and set of features (and there are valid use cases for it even then), but I hope you see why I don't think it's the best option in this case Anyway, since ultimately you should do what you see as the best option here: With ProcessWire you don't typically add columns to database tables or new tables to the database, so there's no UI for this (apart from PHPMyAdmin, of course, if you prefer something like that). You can communicate with the database using API variable $database, which is just a fancy way to use PDO style queries directly from your own code. You can see some examples of that in the source of my Version Control module. It's a bit old topic (there's probably newer material available too if you try searching the forum), but here's some discussion about custom login forms. Personally I tend to avoid custom login forms and rather allow users to login via native login page. This is connected to the fact that I don't like creating new custom Admin tools for them either and would much rather either let them use built-in tools or create a new Process module for them to use (method no. 3 in my earlier post). Hope this helps a bit.

Pretty much the same old arguments there: no front-end themes, end-user can't add new functionality via back-end and "it doesn't look like WordPress". Based on a couple of rather similar reviews (bad choice of words, but anyway) I'd say that it probably wouldn't hurt if we had more site profiles available.. and if they were more obviously visible at processwire.com. I feel that this is one area where we're a bit behind from what we should've / could've done, since people only just getting to know PW tend to miss these entirely. Just saying.

Each landing page is effectively it's own mini-site. Not sure what else to say here -- they'll be considered separate, small sites by Google and other crawlers. They themselves probably won't rank extremely high (Google likes quality content that is updated often), unless they're targeting a niche keyword. I'm not really sure what you mean by this. Care to elaborate? Yes. This depends on how your menu has been setup. You'll have to skip those pages one way or another -- make them hidden or exclude the template they use in the code that builds your menu. You should enter all hostnames you're going to use, i.e. your main domain, all the domains used by the landing pages etc.

This isn't exactly what I had in mind (thought you had those users already, just wanted to give them permission to edit a page), but there's an example of creating an user at the bottom of the $user page. If you just want to use Page Edit Per User and grant specific user access to a page via API, that looks more like this: // I'm assuming that you're already creating pages via API; not going into detail about that.. $p = new Page; $p->template = $templates->get("some-template"); $p->parent = $pages->get("/some-parent/"); $p->name = "some-page-name"; $p->save(); // give current current user access to edit previously created page $user->editable_pages->add($p); $user->save('editable_pages');

If you've already got a form that allows the user to create a page.. why not simply make the form add the user access to edit created page too? Unless that's possible, I'd suggest creating a new module based on Page Edit Per User; instead of current onMyBranch() method, simply check if given page was created by current user and based on that return true or false.

Hi there, Nick, and welcome to the forum! PW can handle this, but this isn't something any single module alone will do for you. It'll require custom code work, the amount of which depends a lot on how many users you'll have, whether you're prepared to create user accounts and connect them to editable pages manually or if you need to automate registration, how customised you want edit views for these clients to be etc. Below I'll try to describe three possible approaches you might use to make this work: 1. Keep client's user profiles (i.e. user accounts, which in ProcessWire are also pages) and publicly viewable product/info pages separated. Each user would have an account to your site but also separate, publicly viewable page he/she can edit. For this approach, I'd start with Page Edit Per User module, which allows you to define pages that specific user (one with no access to edit any pages by default) can edit: /clients/ # public part of your page /client-x/ /client-y/ /client-z/ # page for client z: publicly viewable info, products etc.; # after logging in, client z can edit this page /processwire/ # ProcessWire admin area /access/ /users/ /client-x/ /client-y/ /client-z/ # user account for client z: not publicly viewable; after # logging in, this client can edit page /clients/client-x/ 2. Add product information etc. custom fields directly to user's profile pages and then render those publicly. The problem with this approach is that all your users, including superusers, will have these custom fields, which might not make sense in your case (if you need other type of users later, it's going to be very confusing). Also, you'll still need public URLs for the profiles -- not much of a problem though, as you can always create a template that fetches user (like Pete descried in the thread linked to above), either based on a GET param or URL segment. If you go with this, be very strict with validation, i.e. before rendering user page make sure it's one that should be rendered, i.e. one of your clients and not, say, superuser account. 3. If you're confident in your skills with code, you could also create a Process module (a new view/tool for Admin area) that your clients use to handle their products. This would, essentially, be a custom-built CRUD tool for managing user-specific pages. This thread provides some useful pointers for this. Using this approach it would actually make sense to include basic info as custom fields on user profiles as explained above and creating separate pages only for products these clients sell (assuming that there's more than one product per each client). Hope I didn't confuse you too much with this -- please don't hesitate to post any questions this raises and/or you still have. Would be happy to clarify. I'd strongly suggest that you start building this thing and then ask once you face any specific issues.. the more you can limit the scope of your question, more likely you are to get a swift and precise answer

Something like this should work (assuming that the name of your comments field is 'comments'): $comment = new Comment; $comment->text = "my text"; $comment->cite = "my name"; // etc. $p = $pages->get('/about/'); $p->comments->add($comment); $p->save('comments');

Does this work for you? RewriteRule ^columns/culture-of-heart/(.*)$ http://significatojournal.com/columns/culture-of-kindness/$1 [R=301,L]

If you're asking if embedding YouTube videos in an iframe is safe, yes. If you're asking if embedding iframes is safe in general, yes and no -- content within iframe doesn't have access to your site, so in that way you're safe, but malicious content within an iframe can harm visitors of your site, so naturally you'll have to be picky about what you embed. An even easier way for embedding videos from YouTube or Vimeo is the Video embed for YouTube/Vimeo textformatter.

$page->image (assuming it has the capacity of containing multiple images) returning only first image is a problem if you're going to iterate contained images. Sure, you can make $page->image return first image of many, but then you'd need another method, something like $page->image->getArray() in order to iterate over many items. I don't think that one use case trumps another, especially since it would be a breaking change. Judging from your sample code, I'm kind of wondering if you are aware that $page->image is just a call to custom field called 'image', not something that's really built-in to the core? If that's just a proof of concept, that's cool, but in real-world use cases you can't reliably assume field 'image' to always exist Edit: forgot to mention that the ability for multi-file field to return single item has actually been added to dev branch. It's not quite what you described it (it won't work as a method) and the use case might be different from what you envisioned (though what do I know..) but you might want to check it out anyway: https://github.com/ryancramerdesign/ProcessWire/commit/83826e993ecd57af22373cc878abac8a51f11ffe. Edit 2: re-reading your post, you seem to use 'image' and 'images' somewhat interchangeably, when, in fact, there's no connection at all between these. Changing max files allowed to '1' in field 'images', like you mentioned in your post, definitely won't enable $page->image. Perhaps I'm misinterpreting this (or it's simply a typo), but if you're suggesting that $page->image should point to first item in $page->images, that's not feasible, as 'images' is also a custom field with no guarantee to be around everywhere (and any template might have dozens of other image fields too, which would then need similar logic).