ryan

Good explanations! You sold me. I will have to make this my new admin theme. Now I'm really curious why Akismet flagged my reply to Peter a few minutes ago as spam, and didn't flag your message considering all the spam triggers mentioned in your last paragraph...

I was going to say to type "title body filefield.description" into the search fields in Modules > Process > Page Search. But went and tried it myself and see we're using a multi selection field rather than a text input. So I went ahead and changed it to a text input so that you can use subfields (like filefield.description) for searches. If you grab the latest commit, you should be able to configure the Page Search module to use filefield.description for admin searches. https://github.com/ryancramerdesign/ProcessWire/commit/1cc0c0549d1f55fb380211037dc267be10b0b71a For your own searches, you can already do this just by including filefield.description in your selector. For example, this would look for a match in either title, body or filefield.description: $matches = $pages->find("title|body|filefield.description*=something"); If you start getting a whole lot of fields in your selector, you might get better performance out of bundling all the fields you want to search into a FieldtypeCache, and then searching the single cache field rather than the other individual fields. You can already do this. ProcessWire will let you select a field for automatic sorting as long as it has the "autojoin" option set in the field's configuration. So if the field you want to sort by isn't showing up in Children > Sort Field, then chances are that it's not set for "autojoin" in the field config. Go ahead and check that autojoin box and let me know if that solves it? Thanks! Ryan

I just installed [digital]. Well played and nice design... but is it really necessary to have such abrasive background music for an admin theme? I mean, good thinking, but I'm just not sure how I feel about singing admin themes. I could also do without the pharmaceutical ads and popups, but I guess that's what AdBlock is for... I just didn't expect to have to use it for a CMS admin theme. The contextual text ads randomly showing up in the Page List were a nice touch, but personally confusing to me. However, I am intrigued by your "live help" chat window. Though I don't think it's working because when I typed a question about TinyMCE in there, it apparently connected to some chat room for older folks discussing topics I won't repeat. Needless to say, they weren't very helpful. So while I like the idea, I'm not so sure about the usefulness of the execution. If you can fix these issues I think you'd have a great admin theme. ;D

What are the field types you are trying to add to the search? The text search in the admin can only search fields that are indexed for fulltext searches. This includes text, textarea, cache and I believe a couple others. But of course all data in ProcessWire is searchable, but that search box in the admin is designed purely for partial-match text searches. It would be fairly simple to modify or extend the admin page search process if you are interested, I can guide you through it.

You are right, that would make sense. See the latest commit, it contains updates to the FieldtypeURL/InputfieldURL so that it reports errors as you would expect. Note that it still saves the page, but it will now at least tell you about the error. I'll be adding an additional javascript validation option for Inputfields once we enable required fields. Thanks, Ryan

Currently all files attached to pages are stored in /site/assets/files/[page_id]/. If someone has a URL directly to a file, there is nothing to prevent them from accessing it. Down the road, I figured we would add another dir, like /site/assets/files-private/, and those requests would get sent to PW (via the htaccess) rather than letting Apache handle them. PW would determine whether to passthru the file data based on whether they have access to the page. There is significant overhead in doing this (depending on filesize), so it's not something we'd want to do on other pages.

You don't need to worry about moving the files to the proper place. Just set it to the path or URL where the file is located, and it'll take care of it for you. <?php $page = new Page(); $page->template = $templates->get("your-template"); $page->parent = $pages->get("/path/to/the/parent"); $page->save(); // a page has to exist before you can add files to it // add a file to a single file field: $page->filefield = "/path/to/file/somefile.pdf"; // or, add a file to a multi-file field: $page->filefield->add("/path/to/file/somefile.pdf"); // don't forget to save it again $page->save(); You could also do this if the file is somewhere else online: <?php $page->filefield = "http://some-domain.com/some-file.pdf"; In all of the above examples, ProcessWire will copy the file to it's own storage location behind the scenes. I will look at what we can do to make that name field optional or automated.

Peter, In that case, it's not working quite how I'd planned. Now that we've got an example of this scenario, I was able to update it to work. https://github.com/ryancramerdesign/ProcessWire/commit/570f18127dda799c5352669f7df86c40fbf2d2f5 Grab the latest commit, or just that file if you prefer. Just tested here, so hopefully it will work there too. Let me know. Regarding an optional 'name' field... this is considered the one common element for all pages and any other objects in ProcessWire to have. Maybe we can auto-populate it with something if omitted. Are you adding these files manually or via the API? Thanks, Ryan

5000+ files would be more than you'd want to put on a page, just because it would be difficult to manage from an administrative standpoint. So I think your approach with pages is fine. I'm just hoping you are adding all these files with some automated API functions rather than manually. So it sounds like the main thing is how they appear in the admin page list? If that's the case, we can easily change what appears in the page list. By default the page list displays the title field (if there is one) and otherwise displays the name field. You can modify that behavior by going to Modules > Process > Page List and editing the fields to display. You can display a field specific to your files template, and it'll get ignored by all the templates that don't have that field. So here is what I think you want to do: Go to Setup > Fields > Title. Uncheck the "global" option, so that your files template can exist without a title field (optional, if you want it to). Go to Modules > Process > Page List. Change the "name of page field to display" to: filefield.basename title Replace "filefield" with the name of your files field. I'm also assuming that your file field is a single file, and not multiple files. I've not tried doing this with file fields before, but I think it should work.. let me know what you find. Thanks, Ryan

Peter, There isn't currently a way to do that directly, but there are some alternatives. It would help me to understand the context of your need. What's the field you want it to generate from? To disconnect name+title: You could uncheck the "global" option on the title field, and that would prevent it from appearing on the "add page" screen, which would basically disconnect title and name. In that scenario, you'd be forcing the user to enter a name for a page independently of anything else. You could hook into the $pages->save() function and automatically set the page name for new pages (those that don't have an ID yet). You could create your own Process module for adding pages, perhaps extending ProcessPageAdd. Then edit /admin/page/add and select your Process rather than the default. You could also setup another page and Process for adding pages of a specific type in your admin. There are other options too. What approach is best probably depends on the situation... tell me more and we can figure it out. Ryan

I can't seem to get it to install. Going through the instructions, I installed each of the modules and added the videos page in admin, then added two child pages "add" and "edit", and assigned the appropriate process. I can get to the video list page, but when I click "add video", I get: Call to a member function getPageInputfields() on a non-object (line 40 of ProcessVideoAdd.module) I'm wondering if I might have misunderstood part of the instructions: How do I set the default child template to be "video"? I think the only way is to do that is by editing an existing template... but which template? One other thing I noticed during the install: I dragged the "VideoLibrary" dir to /site/modules/. PW could detect all the modules except for your MarkupVideoLibraryDataTable module. The reason is that it's in a dir called "Markup". Instead, the directory should be called "MarkupVideoLibraryDataTable". The reason for this is that a directory name needs to match the name of the module within it. The only exception to that is when you are creating a directory for the purpose of grouping other containing directories (like /site/modules/VideoLibrary/). Lastly, if you are interested, the entire install process could be contained in a 1-click "install()" function in any one of your modules. For instance, an install() function in ProcessVideoList could install the other modules it needs, create the templates and pages, assign the Processes to the pages, and have everything setup with one click. This is probably worth doing if you want to create a module for distribution to others, and I'll be happy to guide you through it.

Very cool, I look forward to checking this out. I'm wrapping up work for the day right now, so will try first thing in the morning. It sounds like you've put together a cool module here. This may be assumed, but just wanted to mention newly added modules should always be installed in: /site/modules/ (not /wire/modules). Modules are self-installing, so if you have one of them that calls upon the others, then you only need to install the main one and the others will get installed automatically when called upon. Of course, there's no harm in installing them manually all at once too, but just wanted to mention this part in case it ever saves any time.

I went to create a new page with the name "0" (zero). You are right that PW didn't like it. Though the error I got was different than the one previously posted here (see screenshot). But the problem is in how PW checks to see if it has a value: if(!$page->name) $this->error("missing the name field"); I'm changing it to: if(!strlen($page->name)) $this->error("missing the name field"); This is fixed in the latest commit: https://github.com/ryancramerdesign/ProcessWire/commits/ Thanks, Ryan

I started in Pascal too: "Turbo Pascal" (pre Delphi). Here's my "shareware" from 1992: http://thecomputerroombbs.com/3.html (search for "datav31" DataView) ;D

I understand, that makes sense. You can probably tell I have a preference for functions with 1 or 0 arguments for public API stuff. The strategy with the API is that if functions start taking multiple arguments, then it should be split into multiple functions. But this isn't as much of an issue with the get() function, especially since the second argument is optional as you suggested. But in this case, the get() function is common to all classes in ProcessWire based on the WireData class. If I add an argument, I have to add it to all of them, but the unformatted option would only be applicable to one of them (Page). If I just add it to the Page class, PHP will complain with strict mode errors. So I do think it's a good idea you proposed, but there are a couple of good reasons why we probably shouldn't. Do you think that getUnformatted() is too verbose? We could always look at adding a shorter alternate, like getu() or something, whether native to the class or from a module.

It's probably best if the newbies don't change it. If someone knows what they are doing with markup and semantics, then I do want them to be able to figure it out though. TinyMCE settings aren't the most clear thing in the world (I don't totally understand them myself! I spend hours wading through the TinyMCE wiki and forums), and I do agree with you about documentation. This is the reason why it's not an allowed element in the TinyMCE field by default. Assumption is that people are using the $page->title field (or a separate headline field they've added) for their h1 rather than assuming it'll get built into the bodycopy.

Btw, looking closer, what is the strtoint() function? I don't think that's a PHP function.. one of your own?

Looks like a good solution! I would suggest one change: use get() rather than find(). It will produce the same result, except you won't have to have the shift() at the end. Not to mention, it'll be more efficient/faster since it's not attempting to retrieve more than 1 page: <?php $match = $pages->get("parent=/tournaments/, template=match, date_registration <= $date_start, $date >= $date_end, sort=date");

There is already is the getUnformatted() function: <?php // will output a unix timestamp echo $page->getUnformatted('date'); // these will output a formatted date echo $page->date; echo $page->get('date'); // alternate syntax getUnformatted() works the same way as the get() function, only the output is never run through the outputFormatting filters. Another way you can do it: <?php // below will output a formatted date echo $page->date; $page->setOutputFormatting(false); // below will be a timestamp rather than a formatted date echo $page->date; // anything else you get will also be unformatted // i.e. no entity encoders, etc. // optional: remember to turn it back on when done: $page->setOutputFormatting(true);

These tags are disallowed by default because some suggest building page structure or introducing possible non semantic markup. Something like TinyMCE can very easily get out of hand if it turns into a freeform markup tool. So the current settings are really geared towards ensuring that the markup is specific to a field and not the entire page, as well as trying to minimize the damage a client could do with markup and pasting. Pasting is probably the biggest issue, and even with the allowed elements we have now, it can still be a problem. I know there are sometimes needs for div and span tags, even within a field like this. But to take full advantage of them, you are going to have to get into the TinyMCE settings even further than just the valid elements. Granted, you might be able to input them, but you won't be able to see what they do unless you get into tweaking more TinyMCE settings. If it's for your own use, then great, but if it's for a client, then expect them to break it. In my sites, I try to organize an search accessibility/SEO strategy that optimizes the title tags and h1 headline (among other things). If I give the client the h1 tag in the editor, I know they will use it (it's bigger!) but it'll mess up your ability to exert some level of control over the page semantics and hierarchy, especially as it relates to search accessibility/seo (assuming headline use in the context of the page). Regarding HTML5 tags, I do think it would be worthwhile for us to add some of those to the default allowed elements. I also recognize that everyone has different needs, and we should make the system flexible enough to support those needs. Currently it is, but you do have to understand how the TinyMCE settings work, and they are a little cryptic! So while I do want to have default settings for best practices (like they are now), perhaps we should setup a separate thread or forum for pre-defined TinyMCE tweaks that people can paste in? Or maybe when I setup the documentation for this fieldtype, I can have a section there with predefined settings they can use... what do you think?

This is something I would like to add. It was in PW1 and just hasn't yet made it into PW2. I was planning to do it in combination with the tag parser, because the URLs would be a form of tag: {url, page=123}. But now that I think about it more, I'm not sure it is a good match for the tag parser, because I want tag parsing to be optional... yet I don't want URL-to-ID translation in TinyMCE to be optional. Plus, this should be relatively easy to implement... moving it up on the list. Thanks, Ryan

Adam, This is easy except for the date part, which I want to make sure I understand. You need it to match the pages that fall in today's date? To do that, I think we have to find the timestamp at 12:00 am today and 11:59 pm today, and then use that to compare with your date_start and date_end fields. Here's how I'd at least start: <?php // get 12:00 am today $today_start = strtotime(date('Y-m-d ')); // get 11:59 pm today. There are 86400 seconds in a day, so subtract 1 to get 11:59:59 today $today_end = $today_start + (86400-1); $matches = $pages->find("template=match, parent=/tournaments/, date_start<=$today_start, date_end>=$today_end"); It may need tweaking to get it right, but it's a start. Having sample data to test with is key. As for the date_end - 1 day part: I think you could accomplish that by modifying the $today_end to arrive at what you are looking for (or maybe substitute the $today_start). Though I'm not sure I understand the context well enough to propose the right solution for that part of it... I think it'll be easy though. Tell me more about that part if you'd like.

I want to make sure I understand how to duplicate. So create a new page, and set the name is "0" or something different? Thanks, Ryan

Very cool Adam. I just installed and tested it out on one of my existing textarea fields and it works great! This opens up some cool new possibilities, like having pages as CSS or JS files. Tell me more about the way you are using it in your own projects? Nice work. Thanks, Ryan

ProcessWire works in both of the ways that you described for Wordpress and Wolf CMS. By default, each page has a parent, but that is just one of many ways you can retrieve them from the API. For example, you could retrieve all pages using the "news" template, regardless of where it was in the site, by using this API command: $items = $pages->find("template=news"); 20-100 articles on the back end is not going to get bulky. ProcessWire is designed to deal with tens of thousands of pages (or more) on the back end. I think you will find it can scale better than WordPress in that respect. Though I don't have enough experience with Wolf CMS to make any comparisons with that product.