jordanlev

Sometimes the system needs to serve the markup -- isn't this the whole point of ProcessWire's theme system? What is it about forms that makes them not conducive to using custom markup? I am often in the same boat as the OP -- sometimes you just need to create a complex layout on a form or work within an existing CSS framework or style guide. And from what I can gather, it's pretty simple to do with PW's form builder. Here's an example: <?php $errors = $form->getErrors(true); if ($errors) { ?> <div class="errors"> Please correct the following errors: <ul> <?php foreach ($errors as $error) { ?> <li><?=$error?></li> <?php } ?> </ul> </div> <?php } ?> <form method="<?=$form->method?>" action="<?=$form->action?>"> <?=$session->CSRF->renderInput()?> <label> <?=$form->my_first_field_name->label)?> <input type="text" name="label" value="<?=$form->my_first_field_name->value?>"> </label> <label> <?=$form->my_second_field_name->label)?> <input type="text" name="label" value="<?=$form->my_second_field_name->value?>"> </label> <input type="submit" name="submit" value="Save"> </form> You could even "mix and match" automatic markup output of just some fields but not others, if for example you have a complex field type like a page chooser, by calling <?=$form->get('my_complex_field')->render()?> -Jordan

Some other frameworks and CMS's I've used have a handy function called "h", which is a shortcut to htmlspecialchars($string, ENT_QUOTES, 'utf-8'). This makes it super-easy to escape output in your templates. I don't see anything like this in ProcessWire, so I'm wondering what is the best way to define a utility function like this that is available to the entire codebase (I intentionally want it to be in the global namespace)? Ideally this would be in my /site/ directory (not /wire/), but it could also be in an installable module I suppose. Thanks.

I'm attempting to write a module that will create some templates, fields, and pages upon installation. I found this helpful forum thread that shows the code: https://processwire.com/talk/topic/4921-how-to-create-template-file-using-api-under-a-module/ ... but I am curious what is the conceptual difference between fieldgroups and templates? Looking at the database of a basic install, I don't see any records in the fieldgroups table that are not also represented in the templates table. Is it possible to have fieldgroups that are not part of a template? If so, what are some use cases for this? If not, then why even have two distinct entities instead of combining them into 1? Thanks!

I am a newbie to ProcessWire, so I am only guessing here based on my experience with other CMS's... The requested path needs to be provided to the processwire system somehow, so it knows what page to show. If you're not using a CMS or a framework, then usually what is served to the browser is a php or html file that exists at the requested path... but with a CMS like processwire, there aren't actual files on the server for all the pages that are created in the dashboard. So instead, ALL requests for all paths are sent to the processwire system, and it examines what the requested path was and retrieves the appropriate content from the database based on that. The "it" variable is how the requested path is communicated to processwire from apache. I've seen other systems use a different approach, using php's $_SERVER['PATH_INFO'] , but sometimes this causes problems depending on the server settings, so perhaps processwire avoids this method to cut down on potential problems.

@Newbie, click on the field name to edit its settings (see attached screenshot). It took me a while to figure out too

That gets me halfway there... that module only hides one of the settings under the "Settings" tab. I'd like to hide that tab altogether. I see that there is actually a template option called "noSettings" that is set on the user, role, and permissions templates. But this "noSettings" option does not appear to be exposed via the admin UI. Do you know how I could have a module that sets this on a per-template basis? Or do I just need to update the database manually to add this to the array of options in the "data" field of the "templates" table?

Ah, thank you. I didn't notice I could change settings on individual fields. That is perfect! I also found the "Don't Allow Unpublished Pages" setting which cleans up the buttons like I wanted. So the only thing left for achieving my ultimate vision here is somehow hiding the "Settings" tab (and ideally just hiding both tabs altogether... because if the user is only going to see the "Content" panel then there is no need to show the "Content" tab control at the top, because there should not be anything else available to switch to). Thoughts? Thanks again (and again)... the helpfulness of this community is really great

Thanks for all your help. I am slowly making my way here. My next problem is that I do not necessarily want a "title" field on these templates. I am unable to remove the "title" field from the template though because it appears that they system requires it on every template. How can I override this requirement so that I can remove the title field from some of these templates? Or if that's not possible, can I hide it from the user who is editing content and automatically populate it in the same way I'm auto-populating "page name" (url slug)? Other little things I'd like to polish up are: * hide the "Settings" tab when editing the fields * hide the "Save + Keep Unpublished" button when adding a new layout element (and change the existing "Publish" button to just say "Save", like what you see when editing it after it has already been published) Last but not least, does anyone know how compatible the PageTableExtended fieldtype is with the Fredi module? Should it "just work", or would modifications need to be made to one or the other? Thanks again! -Jordan

Thanks for the ideas, sounds promising. I'm unfortunately having trouble figuring out what you mean for 1c: "make use of Input > Automatic Page Name Format, and then go to the template context settings for the title field and make it invisible and not required". I am unable to find "Input > Automatic Page Name" setting anywhere. Is this something I need to install first? Is it a setting on the field? Or on the PageTable field? Or on the template? Or something else entirely?

Okay, I've got the PageTableExtended fieldtype installed and working. I see a few things that make this not an ideal solution, although perhaps I need to configure it differently? 1) Every new "layout element" that is added to the PageTable field creates a new page in the sitemap. For my purposes, this is not ideal for several reasons: a) I don't want these "layout elements" to be accessible via a url... they are only intended to be a portion of content on the page I'm adding the field to b) The sitemap gets littered with these pages which are not really pages (well, I don't want the users to see them as pages, even if technically they are pages under-the-hood) c) The user is required to enter a title and url slug when adding them, which doesn't make sense in this context (because as far as the user is concerned, they're just adding content to a page, not creating new pages) 2) I want to create new templates for each of the "block types" that users can add as layout elements, but I do not want those templates to be choosable when they add new pages to the site. I *only* want them to be choosable in the context of this PageTable field. If I set the template to not be choosable for new pages, then they are unable to add them to the PageTable. Any thoughts on if it's possible to overcome these issues using this technique? Thanks!

Derp... I forgot to checkout the dev branch after I cloned the repo. Will try again, thanks!

I had some time this weekend to install the dev branch. Unfortunately I could not get things to work as expected. Primarily, I was unable to find the PageTable field. Doesn't seem to be installed by default, and cannot find it on the processwire.com modules page. I did find the PageTableExtended module, but installing that led to a php error about not being able to find the PageTable field module. Not a big deal, I'm sure this will all get sorted out by the time 2.5 is officially released, but this is why I generally try to wait for official releases before learning about a new system that I'm not already familiar with

Thanks everyone for your responses. It looks like the PageTable Extended feature might be the solution I'm looking for. I'll try it out when 2.5 is officially released soon.

Is there a way to achieve a situation where my users who are editing a site can choose between different sets of fields that they will place in a certain spot in a page? My understanding of how ProcessWire works is that the developer creates fields and then assigns fields to a page type, then the user can log into the dashboard, create a page of that page type, then edit the content of those fields that were defined by the developer. But instead what I would like is to be able to designate an area of the template in which users have a choice of fields they want to add (actually, what I really want is for the user to be able to choose a SET of fields that I have defined and grouped together as the developer). What I am trying to recreate here is an amazing feature of the Concrete5 CMS (which I have been using successfully for many years now) where you don't define the types of fields that must be placed in a specific spot on the page, but instead define "areas" that the user can then choose which fields (actually, a set of fields, which C5 calls "blocks") to place in that area. These areas are "repeatable" in a sense because the user can add as many or as few of these blocks as they want. The primary use case for this is the main content area of most pages -- I don't just want one WYSIWYG editor the whole section, but instead I want the user to be able to choose that they want perhaps a WYSIWYG editor, an image or two, a video, etc. I came across this old thread in the forums which seems to be asking a similar thing: https://processwire.com/talk/topic/3264-selectable-layouts-within-a-repeater/ -- perhaps that will help explain my question even more. Thanks for your thoughts. -Jordan

Ahh, I see... that does make some sense. I think this kind of feature is related to "content structuring", which seems to be ProcessWire's strength, as opposed to "loose content areas primarily intended for display" which is how I think of things coming from the Concrete5 world Thanks, Jordan

Is it really that big of a waste, since you're only re-using the *definition* of the field across templates (which I can't imagine takes up a lot of space in the database)? The data that goes into the fields is on a per-page basis, so I guess I don't really see why it's better to create the fields and then add them to the template as 2 separate steps, as opposed to just saying "this template should have a field of type X". Is there some other feature of the system that benefits from sharing field definitions across templates? Thank you.

And one more question: Can someone explain to me the reasons why fields are created separate from templates? When I create a template, I would think that I could just add any kinds of fields to that template, but that does not seem to be possible -- instead I must go to the "Fields" page and create the fields, which are then available to *all* templates. It seems to me that it might be better to just create fields for a specific template -- because it would be fewer steps and also because it seems "messy" to me that I would have fields that are created for one special template available to all templates. But since PW is such a well-thought-out system I am thinking there must be good reasons behind this decision so I am curious what those are. Thanks!

Hi everyone, Thank you so much for your comments and your warm welcome to the community! @apeisa, I think you are referring to the difference between "front-end editing" versus "inline editing" (I read a forum thread about this here for ProcessWire but I cannot find the link now) -- and I agree that true inline editing is very difficult to do, but the way Fredi works now I think is very good (pop up the editing interface in a dialog box). I think it would be nice if there were more options on the $fredi object. One example is if you could set the width and height of the dialog box. Another thing is if you could utilize more complex markup (almost like providing a small template for the fredi "edit" link itself, instead of only being able to customize its text) because then you could do things like put a border around the editable area and make the whole thing "clickable" (which is how Concrete5 does it, and I think it very intuitive because people do not have to search the page for a small "edit" link, and also because it requires less tweaking of the page layout becaue it is just adding a 1- or 2px border as opposed to a new link which could push elements down or sideways on the page). Also, it would be nice if there were a way to change a page from "view mode" to "edit mode" (although I think this is possible if you write your own javascript to show/hide the ".fredi" classes, but would be nice if it were more built-in). One question I have is about "draft" or "preview" mode on pages. I know that you can create a new page and keep it in a "draft mode" (so it does not yet appear on the live site), but when you make more changes to a page that is already live, is there a way to keep a separate "draft" version of it so that the logged-in user can make some changes and save the page but without publishing those changes to the live site? Overall I see that the correct way to do things in ProcessWire is by writing modules (as oppoed to adding a lot of features to the core). I think this makes a lot of sense and when I start using PW for real projects I will keep this in mind. About the "file manager", are there hooks in the PW system that would allow me to add to the Rich Text Editor's "Image Insertion" feature so that instead of listing images on the page, it could list images in a custom "file manager" object I could create in my own module? I really dislike the 2-step process of adding images to another field on the page before you can insert them into a rich text area (but I understand that some people like this, so I am not saying it is bad -- but it is not what I prefer). Thank you all again, I look forward to discovering more about how ProcessWire works! -Jordan

Hello, My name is Jordan Lev, and I've primarily been using Concrete5 for the past 5 years to build websites for clients. I just came across ProcessWire the other day (not sure how I missed it for so long), and it is very impressive and really jibes with the way I think about building sites. I actually have created several Concrete5 plugins that offer functionality similar in spirit to the way one constructs fields and templates in PW, so it was pretty incredible to discover an entire CMS that embodies those principles! I have been playing around with ProcessWire a little bit, and reading through some forum threads. I'm hoping a project comes my way soon that PW would be a good fit for, so I can actually use it for a real-world website. For those of you who have never built a site with Concrete5 before, I encourage you to check it out (if for no other reason than to get some ideas on a slightly different model of how a site can be put together). I think what C5 is most well-known for is its front-end editing, but I would say that there is a deeper reason C5 is so well-loved by people like me: it really allows you to "design the editing experience". I think PW is somewhat similar in this regard, although it seems that PW is more about "designing the content structure" (which often overlaps, but not entirely). I've read some posts by Ryan that indicate he is concerned with separating the definition of the data from the display of it (for example, https://processwire.com/talk/topic/4189-flexibility-in-page-design/#entry41205 ), and that is a fantastic way to think about things (and very refreshing if you've every worked with less modern systems like Wordpress)! But I also think that philosophy is more well-suited to larger sites that have a lot of structured content. The places where I think PW could be made even better than it already is are for the smaller-scale marketing/informational sites, where tying the content and the display more closely together actually makes sense (especially for the non-technical users who have to manage the content as time goes on). For example, I think the much-discussed "file manager"/"media manager" feature is pretty critical to an easy-to-use workflow, and I feel like there are ways it could be done that honor the underlying spirit and simplicity of PW. Also, I think front-end editing is a HUGE win in terms of ease-of-use, and the "Fredi" module seems to offer that functionality (and there are a few minor tweaks I'd love to make that would allow the site editing experience to be even more "designable"). I have seen comments in the forums that are both "pro" and "con" on the things like file manager and front-end editing, and I think the difference in opinion stems from the difference in the kinds of sites people are building (larger, more structured sites that are served better by PW's existing dashboard versus smaller, less-structured sites I think are better-served by a tighter integration with the pages themselves). What I would love to know is how interested the ProcessWire community is in even attempting to make PW a better fit for these smaller-scale websites. Are people interested in discussing these ideas, and possibly even working towards making them happen? Or is the community primarily concerned with the larger / more structured sites and not interested in rehashing this line of discussion? Or perhaps I'm making some assumptions and generalizations here that aren't true? I just want to share with you all that some of the things Concrete5 has are incredible (pretty much every client has been blown away at how easy and intuitive things are with Concrete5 when I first show them the sites I've built), and I am interested in understanding more about how to make this happen with ProcessWire, and also sharing my experiences and insights with you all in the hopes that ProcessWire can be more appealing to a wider set of users without sacrificing its underlying simplicity and design philosophy. So I'll leave it at that, and am looking forward to hearing what people have to say! Thanks, Jordan