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.

Definitely not a reserved-word problem with a name like "latest-news". I think we must be running into some kind of incompatibility with your server or it's version of PHP. Do you know what version of PHP is running on the server? One thing you can do is upload a file called phpinfo.php with nothing in it but this: <?php phpinfo(); Then load the URL you uploaded that file to in your browser, and PM me the link or send a PDF/screenshot of the result to me.

Changing the password is as simple as: $user->pass = "new_password"; $user->save(); But this a security problem from the front-end because we don't have any way to confirm that the user is who they say they are... without them actually being logged in. In the new user system, an email address will be part of the default user profile. That's one way to confirm a user's identity, and means you'll have the option of sending them an email with a password reset URL. You could implement that approach now by saving account email addresses in some other place. But if you don't need it to happen right away, you might just want to wait for the new user system, which will have this capability built-in.

You can make a template (and it's corresponding page or pages) do just about anything. But I think we need more technical details about what you are working with, because I'm not sure that I totally understand your question? Thanks, Ryan

Take a look at this post from awhile back that documents one way to approach it: http://processwire.com/talk/index.php/topic,17.0.html There are also some changes in progress for the user system that may be worthwhile for your need as well. The only concern I have in your instance is the "clients can register" part. That means that you'll have to implement some extra security measures to ensure you don't get millions of automated spammer accounts. But I can help you through that. Whereas if you are creating the account and password, you don't have to worry about that aspect.

Are you doing this from the admin or from the API? If from the API, what it's telling you is that you need to populate $page->name before saving it. But it sounds like you are in the admin, so it is a strange error to see when adding a page in the admin. What is the name you trying to give the page? The only instance I can think of where you might get this error is if the page name you are trying to use is a reserved word. Also you mentioned some other problems - Can you describe them further? If there is something environment specific, the more we know, the better chance we can track down what's going in in this environment. Since the installer couldn't detect the server type or mod_rewrite, that indicates potential incompatibility. A link to phpinfo may be helpful too (feel free to PM it to me if you prefer). Thanks, Ryan

Not yet positive about the actual format of the file, but the two you mentioned are likely candidates. Though the files may end up being used just for importing/exporting, and DB used for storage. Regardless of the file format, we're going to make them editable in the admin so that the format won't matter too much.

The structure is designed to support an auto update, so that this module can be written at some point in the future. The way it would work is that it would grab the latest zip (like from GitHub), then it would rename your /wire/ dir to /.wire.[version]/, and move the /wire/ dir from the zip into the location of the old one. At the same time, it would also replace the /index.php and /.htaccess files (unless you wanted to do that part manually). Lastly, it would run an update.php file from the zip to perform any necessary DB updates (if there were any). On most servers, we can't assume that the /wire/ dir is writable, so it would likely unzip the latest PW version into a writable dir in /site/assets/, and then FTP into itself to rename and replace the /wire/ dir with the new one. I believe this is the same method that the Wordpress automatic update uses.

The way we solve it currently is to not actually have a /site/ dir in the repo, but instead have a /site-default/ dir. That way when you do a "git pull" to update your installation, it should leave your /site/ dir alone (which is in the .gitignore). That's the intention anyway. (I'm also new to git). Granted, PW will create a new /site-default/ dir, which you would then want to remove after an upgrade (or add it to your .gitignore so that it doesn't get pulled). We could certainly have a /wire/ only repo too, but the /index.php and /htaccess.txt files are an important part of each version, even though they can't be in /wire/. I'm not sure how to handle that... though maybe that would just be a disclaimer for using the /wire/ repo.

Great update! Thanks for your work on this. I did run into one minor issue, and that's if the site is installed in a subdirectory, the redirect doesn't work. The reason is that it attempts to do the redirect to page's path without the subdirectory it's installed in. I just submitted a pull request to you with a possible solution. It converts PW urls to their page ID for storage purposes. This solution also ensures that redirects aren't broken if the redirect_to page is moved in PW. It only does this with redirect_to URLs that resolve to pages... it leaves all the others alone.

Apeisa's example is correct. Thanks, Ryan