Peter Falkenberg Brown

Hi Ryan, I'm making progress on my first PW site. I'm very pleased, so far! I'm replicating a structure I had done in MODX, and it's an interesting process. On this issue of "Pages with file/image fields require a directory" -- what about the scenario of a site with many thousands of articles, where the article pages have the image field, but perhaps only 50% of the articles have actual images? I would think that it would be much, much better to only create a directory when an image is attached to the page, and when it's deleted, then remove the image and the directory. It seems inefficient to have thousands of empty directories. Also, wouldn't that add to the max number of inodes, perhaps causing an issue? Thanks! Peter

Dear SiNNut, Thanks... it was a good idea, but I only have PHP 5.2.17. See my note hear about the module crashing my /modules/ page. http://processwire.com/talk/topic/1819-markupshortcodes/#entry31944 Yours, Peter

Dear Nico, Yes, a check for PHP 5.3 before loading the module would be helpful. I'm running PHP 5.2.17, and copied the module files to my modules directory, and then when I clicked on check for new modules, I got a white screen, with this error: Parse Error: syntax error, unexpected T_FUNCTION (line 88 of /home/.../public_html/site/modules/MarkupShortcodes/MarkupShortcodes.module) I hit back, but got the same thing even when I just clicked on the Modules menu. After I deleted the MarkupShortcodes directory, all was well. So... it's choking and killing the admin/module page before it's even installed. Perhaps if you add a check for the PHP version, and display a message, "Sorry, can't install... etc." that would be much better. Also, a big note on the Module page would be helpful, to save time. (Ryan, I wonder if code should be added to the Modules page that prevents this behavior. I would think that the check should also come from within PW, rather than relying on any particular module.) Thanks, Peter

Dear Soma, This must be why you're a Hero Member. My, that was fast! I shall update my version. Thank you! Peter

Dear Martijn, Perhaps so. I haven't run into the situation yet, so we'll have to see. But I'm grateful that Soma wrote the module. It will indeed come in handy. Peter

Dear Martijn, Yes, he did a great job; thanks Soma! I guess it depends on the business requirements of a particular website. I do understand your logic. . Yours, Peter

Dear Soma, Your points are well taken. Still, it might be good to have a hard lock module as an option. I guess it's a toss up between the incovenience of open records, verus two conflicts where both people ignore the soft lock. Thanks, Peter

Hi Soma, Thanks for doing this module. How hard would it be to add an option to make it a hard lock, rather than a soft one? Thanks, Peter

Dear DaveP, Thanks for those two links. For email, I've been using this utility: http://w2.syronex.com/jmr/safemailto/ The ShortCodes module seems to be designed for use in templates, unless I'm missing something. I need to parse the tags inside the body field. But maybe I could adapt that. Best regards, Peter Dear Diogo, Thanks! I must have missed that module. So much to learn; so little time. Peter

Dear SiNNut and Matthew and All, Thanks for your feedback. SiNNut, you stated exactly what I meant. Thank you. I think the blend of PW as a framework and CMS is excellent. I'm planning on using PW in both capacties. For example, I might have a page, like "/members/" that runs a PW API web app. But when they leave that url branch, and go back to the main home page, the other pages will all be run via the CMS. Still exploring this idea. Peter

Dear Kongondo, Thanks for your tips about snippets and chunks. One thing that MODX did well, (I think, although it might have affected performance: I'm not sure) is that you could place snippet calls, template vars, and chunk tags directly into the body field of a page, in TinyMCE. I used them both in templates, of course, so that's easy to replicate in PW. But they're also useful in the articles. For example: - a chunk that has a Javascript encoded email address, placed anywhere in an article field, e.g. "{{pfb.email}}. - a template var (a custom field in PW), containing code that TinyMCE would choke on, like a form, or an Amazon-buy snippet of code, or anything. I used [*code01*] 02,03... fields to place those items directly into the article body text. Note that I didn't want to have to mess with TinyMCE's settings too much, to allow raw code. - I didn't place snippet calls in articles very often, but once in a while, I would add a special Ditto call in the middle of an article, that might show "the last ten headlines". It was easier to place that Ditto call in the middle of the article instead of trying to create a special template, to split the article in two places. === So, in PW, I'm planning to: - store the chunks in fields/pages, and noted that one could do a loop replace on the chunks, from the template. That seems fine. - I guess I'll do the same with the template vars (i.e. custom fields). Only the code* fields would be used, and looped over in template. The other fields would just be used in templates directly, as normal. => I'm wrestling with the snippets, however. If I had to migrate one particular client to PW, he would want a ditto call in the middle of an article. I guess I could use a tag, and then run a function at that spot, from the template. I think I could run the function based on the tag name, e.g. 'ditto123'. What are your thoughts about the above? Thanks! Peter

Dear All, I was thinking about this over the weekend. One of the things I've run into with some MODX web clients is that they wanted to have many different options for different template files, for various sections or page types. They were able to create a page and switch the template files at will. I'm considering this method: - add a custom field: "template_file_name" (and a corresponding page to store the individual values in) - add a select field to most of the templates, so that the template_file_name is accessible to all the pages, to choose the template file used for display purposes. - create a small set of templates, containing my custom fields (perhaps 3, one for home, one for section lists, and one for articles) - create corresponding, *unchanging* template files that have nothing in them, except the code to pull in the template file name from the page, followed by an include statement to run the custom template file. I would also set the user role to not allow switching the regular templates. It seemed to me that this would provide the flexibility of having any number of custom template files that could be swapped out easily, without messing with the underlying template and field collection. I also have to say that it seems that it would be easier if the "template" was named something different, e.g. "field collection definition". It's really quite different than the function of the template files, but the names are so close that it's easy to misspeak. It's also initially confusing. Any thoughts? Peter

Dear Ryan, I really appreciate your comprehensive answers! I was hoping you'd take a stab at it. I briefly looked at Laravel, and while it looks fascinating, as Mr. Spock would say, I feel much more kinship with ProcessWire. I will actually be building some public facing web pages, so the CMS will come in handy. And... as a MODX refugee, I believe that I've found its replacement for building "regular" websites, including some of my own, as well as clients'. I've already started to build a small magazine site with PW, to get my feet wet, and I'm really enjoying myself. I'm also very encouraged by the fact that there are a number of MODX refugees here. (I wonder how many?) I used to think that MODX was the cat's meow in terms of flexibility and power, but I think now that PW might just beat the pants off MODX. We shall see... I'm taking the structure of one my MODX websites, and looking at all the functions and items, like templates, snippets and chunks, to see how I can replicate or improve those same things, using PW. I'll report on that. It might be useful to come up with a MODX to ProcessWire Cheat Sheet (unless it's already here and I've missed it). I might write a first draft... I think after I build this first website, I'll be a bit closer to understanding how I can use PW to build my membership web app. Thank you again for your answers! Peter

Dear Sinnut, Thanks! Let me think about how to briefly decribe that. I know my post above wasn't brief, so I don't want to overwhelm folks. I think that one of my major questions is the ease of modifying the admin templates, including the edit functions, version coding things with the API. For example, I would want to have a highly customized look and feel, with lots of hooks, etc, in the view and edit modes for any particular page. I got the impression that trying to modify the CMS would be more work than going straight to the API. Part of this is because I don't know PW enough. My business partner wanted to build all of this as a WordPress plugin, but I thought that might be a real wrestling match, and was thus grateful to find PW. I'm impressed with the API of PW, but I wanted to especially get feedback about the Admin/CMS, in case I was missing something major about its flexibility. Thanks! Peter

Dear All, I have to say that although the docs on PW are a bit scarce, the extremely helpful forum posts are great. Kudos to a responsive community! My MODX refugee status may soon be a thing of the past. After spending most of the day reading forum posts, etc, and experimenting, I have a few questions. I'm building a website which will have a few public facing pages, but will mostly consist of member pages, where each member can only view and work with pages that they own. They will login, and then be redirected to their account home page, which will not have a url, but be assembled by a controller template and simply displayed with a generic url. (I think that's possible.) The web app will be designed to lead them through a very lengthy series of forms that will have post processing hooks for things like calcluations. They'll have a "dashboard", i.e. an account page where they can click on various links to work with their data. * PAGE PERMISSIONS: I read a number of posts about page permissions, but it occurred to me that one way of doing it would be to create a data field attached to each of their pages that would be post-processed to save their user id in that page. So, I tried it out, and it seemed pretty solid. I'd love input on this, especially in case if I'm missing something or reinventing the wheel. Here's what I did: I created an integer field called "page_owned_by_user_id", and added that to a basic page template, as a test. I manually typed in a user id of a test user in an article page that used that template (in action, it would be automatically added). I then modified the basic page template with the following test code: $user_id = $user->id; $page_owned_by_user_id = $page->page_owned_by_user_id; if ( $page_owned_by_user_id != $user_id ) { echo "Sorry: You can't view this page."; exit; } I could of course place that in a function, e.g. "check_user_perms" and then just run the function. I would also add code to allow the viewing of public facing pages. Does this seem like an efficient method? It worked well, in my test, and simply added two id fields (pages_id and data) to a "field_page_owned_by_user_id" custom table. * SAVING CUSTOM FIELDS: Am I correct in thinking that if a page has a template attached to it, that the field group will allow one to automatically save all the custom fields into their various tables, if one uses the PW save function in code? Is this still true even if I use a "main.php" type of controller, as long as I use the page id in the save function? Also, see a twist on this question, below. * CUSTOM FORMS: I've considered trying to alter the admin templates for the above web app, but it's starting to seem more flexible for me to simply use the API, from a controller template file, and then build a whole series of links and forms, based on the user_id that I would capture after their login. If that's true, then my question revolves around the task of building forms, and then saving the data, post processing the data and doing a variety of calculations, with field updates, as well as creating many new pages that would normally be in relational child tables. In other words, any particular data entry form might be primarily from one template/field group, but it might also, in post process, assemble a series of field values that would go in child tables. The "data tables" will of course be created in advance. The run time scripts will just save new data records, or edit or delete records. I'm under the impression now that the function of creating a whole series of pseudo relational data tables is accomplished in PW by first creating the fields (whether reusable or not) and then creating a template with a field group for each particular set of fields, and finally creating ONE page for each pseudo data table (template / field group) that would serve as the parent "page container" for all the records. (Assuming that those records needed to be viewed. I think that if they don't need to be viewed, I wouldn't need the parent page. Is that correct?) Thus, I would save a data set collected from the forms to a new page under that parent container page, and use the template/field group that I had created for the corresponding pseudo "table." Then, if I had to add data to a "child table", I would create a new record (i.e. save a new page), using a child template, and manually include the parent id in that child record. Is the above anywhere close to correct? Is it correct that doing all of the above with the PW framework API would be far easier than trying to twist the CMS app into shape to fulfill all those functions? I'm thinking that it might be, because of all the form customization and hooks. However, if the PW CMS admin backend would be quicker, I'm all ears! * ONLY ONE URL: I'm also hoping that I can do all of this from a main.php type of controller file so that the user never sees any urls except something like /account/. I'm considering this for security, to not provide urls, like "/account/john_smith/". Except for public facing pages. Is that possible? I'm not sure about this, because I'll need some paginated record functions, to list pages under a parent page, but it looks like it might be possible. * EDITING FIELDS Finally (well, at least for this post), am I correct that building my forms to edit a record would be most quickly accomplished by grabbing the fields of a data record "page" using the $page variable, and then populating the edit fields? I've been using a Perl framework/app that I wrote that uses data dictionary files to define the attributes of each data field, including size, type and even list and checkbox/radio values. I then create an HTML template that includes tags for each field, like :!:first_name:!:, that then gets replaced in a loop with the newly populated values coming from the data record. This is done for the various modes of view, add, edit and update, so it's very flexible, and allows one to design the look and feel easily. Does PW have anything close to that, or do I need to build those looping routines to replace tags with field values and attributes, by hand? Thank you all for your very helpful responses! Peter

Dear Pete, That's a good point! Thanks. Peter

Dear Teppo, Thank you for these tips; they all sound excellent. I'll be digging into PW more deeply during the next few weeks, so I'm sure I'll be enlightened. I built a web framework in Perl that I still use all the time, but it doesn't scale well, in terms of traffic (because I'm not using mod_perl), so I'm very happy to find ProcessWire. Thanks again, Peter

Dear WillyC and Soma, Thanks for your answers! I really appreciate it. Peter

Dear WillyC, Thanks, that's a great forum post by Ryan that you linked to. I don't like asking questions that have already been answered, but somehow I didn't find that post. It would be a great item to pin to the FAQ. I think it answered my main questions, but the issue of exporting and importing data sets for some other purpose is still problematic. And... if fields are shared, as Ryan suggested, it gets very complicated indeed. A PW export utility would be very handy, some day. Peter

Hi Folks, MODX has a nifty feature that allows one to create an article, and then switch templates, in a dropdown, much like PW's, to a different template. There is one distince difference however: the MODX templates are simply read-only presentations of that data record. When I experimented with PW yesterday, and switched the dropdown template on a "writers" page, which had some "writers" fields attached, PW warned me that the data would be deleted. I went ahead, to see what would happen, and then examined the tables in MySQL. I noted that the rows for that "writer" were deleted, but that the select_writer_id row was not deleted. It seemed to be an orphan. More importantly however, it highlighted the fact (as I perceive it) that PW's "template" is actually a "virtual row" for one data record, assembling all of the fields. That's ok, but it also creates a "locked in" system, where the template is no longer just a read only way of presenting data, but is also a data dictionary method of storing data. In addition, the page of that virtual data record can't be displayed at that url, unless a template *file* that corresponds to that internal template name exists on disk. This creates the situation where one might create a data record, i.e. page, and then decide to use a different template for one particular page. However, switching templates for that page destroys the data for that record. I'm probably missing something, but it seems to me that PW should have *two* fields: - data_record_definition (i.e. fulfilling the function of the internal template "virtual row") - external_template (used for presenation on the web, to present the data) Then, one could easily switch the external template, without affecting the internal template's data row definition. I'm a little stuck, at this point, on this, because it seems that once you commit to a particular template, you are indeed committed, or stuck (take your pick). I think I saw something about cloning templates, but then you have the problem that if you add a new field to the 1st tempate, the 2nd template is incomplete. (If I saw that correctly.) Thanks for everyone's feedback. Peter

Hi Folks, I started actual work on my PW installation yesterday (I've been reading docs and forum posts prior to that). I added what I would call the equivalent of a "writers table", by creating some "writers_*" fields, and then a writer_id_select field, which I pulled into a regular template, which then stored the writer_id, which allowed me to use the nifty PW routines to grab the byline etc. I kept SQLYog open as I did all this, so that I could examine the new data. I noted once again that each field, like "writers_byline", created its own data table. I think I understand the flexibility issue for that method, but I'm wondering about the impact of that design, in Process Wire. For example: - I read somewhere, a long while ago, that having thousands of tables in a database can degrade MySQL performance. Yet, with a very large web app, or CMS system, there could indeed be a huge amount of tables, since each field has its own table. - Normally, with one data table, with many fields, one opens a row, and pulls in all the fields at once. With the PW method, each table has to be opened, for each field. I wonder what kind of slowdown or system drag or server load happens with that, because it's not just one query, for a row of fields, it's many queries, in order to get all those fields from their own tables. - When one exports a data table, like a "contacts" table, you get one file for the table. In fact, I wrote a Perl script called "MySQL Backup" that does just that; one file per table. Now, that same script would create one file per field, and I can image that trying to access that data from an application outside of PW, i.e. via a restore to that other app, would be quite arduous, since you'd have to reassemble all the separate fields into one table, unless you were willing to create huge relational queries, e.g. "where id=id and id=id.... ". So, these are some thoughts and questions about the rationale that would create this method, i.e. the pros of one field per table have to outweigh the cons of the traditional method. And of course, could there be a point where the system breaks down because of too many tables in MySQL; too many queries, etc? Anyone have any thoughts? Thanks! Peter

Dear Ryan, My four children can't even relate to the concept of a "BBS". "BB What? Does that come on the new Galaxy phone? Huh?" But just wait. Their children will say, "What do you mean, 'cell-phone?' You mean you don't have a wall in your house that turns into a 3-D viewscreen for phone calls, that makes it look like the other person is sitting in the room with you? How quaint." Peter Dear Ryan, Oh; and thanks for the stats about the millions of pages. I'm *very* encouraged about PW! Peter

Dear Ryan, You're very welcome. Thanks for making ProcessWire! It may indeed be my replacement for MODX. Peter

Hi PWired, Yes, I read that post. I used the 2.3 github file. I suppose I also wanted to point out that the PW download link was not up to date. Thanks, Peter

Hi Folks, On the PW download link: http://processwire.com/download/ the link to "download the zip file" comes up with PW 2.2.9. When you go to github, and click on the zip file link, it downloads as 2.3. I've downloaded both, and unzipped both, and the unzip directories are different. So... I used the github version, but I thought that since I'm just starting with PW, I should make sure that's the right one. Any thoughts on the differences? Thanks, Peter