ryan

Can you confirm that the URL is correct, like when it shows the ? on the front end? Are you able to view files/images from any pages? Or does this universally affect all file-based assets on your site?

You can edit it in Setup > Fields

I got your PM and tried out the site. Definitely something strange going on, because all those URLs with the server path in it should be resulting in 404s, yet they aren't. Do you have any other modules installed other than the default ones that come with PW? Would you mind installing a new/stock copy of PW in another directory on the server, just to see if it behaves in the same manner? That will at least tell us whether we need to look more at the server and your site profile, or if we have new situation that is triggering a yet unknown bug in the core.

Those are the expected values there. That makes it more of a mystery because it looks like ProcessWire isn't having any issues getting the proper values from your server (there's no issue with the server environment). What you are seeing in your output is the value of $config->paths->root rather than $config->urls->root. My best guess is that something, somewhere is setting $config->urls = $config->paths (or at least, $config->urls->root = $config->paths->root). Since we haven't seen this elsewhere before, I'm wondering if there might be something in your site that's reassigning that $config var, perhaps a module. One way to test is to install a new stock installation somewhere else on the same server and see if it produces the same result. If it doesn't, then we have to look at what's different with your site. Also, I'm assuming that this breaks all of the links. If it was substituting the server's disk path for the URL, then everything would lead to a 404. But just want to confirm? If the links aren't broken, then we're very likely dealing with some server or browser "feature" that is trying to translate URLs to paths... but I've not heard of such a thing.

But is having past versions of pages query-able in that manner very useful? I'm sure there are uses, but I couldn't think of any situation where I would need it to be (outside of page_id and timestamp). I think of past revisions as archives kind of like a Time Machine backup on my Mac. The main value is just in having the archives. The data is no longer current and won't ever be queried for anything other than page_id or date. At least, that's my outlook on it. But I'm sure the same could be said the other way around. It's just a matter of where you want to make the compromise. I think having selective versions of pages like you mentioned is a good compromise. This is something that I think may be best to implement in the core ProcessPageEdit module. Right now I don't think the hooks are there to do it without having a module come in and create a clone and modify the POST 'id' var before ProcessPageEdit init() is called. Though I suppose you could hook in before Pages::save, see if there is a $_POST['save_draft'] var set (or something like that), clone, then substitute in your new draft version. There are options, but it's not as straightforward as I'd like. It would probably be a frustrating first module to build. I think this capability belongs in the core, and it will be straightforward to implement there. But if you want to try building the capability, I'd recommend working in the core module: ProcessPageEdit. You can always save it out as another module and just change the Process being used by the /processwire/page/edit/ page in the system.

I'm using the default theme for a site as well. I started out just building the site and planned to build out the features and then design everything (I like to design with known output). It didn't work out that way... the client decided that the default theme was what they wanted, so it stuck. I explained that it was hardly original and used on processwire.com, etc., but I guess if the shoe fits wear it. The lesson for me is that if I'm building out a prototype then I need to do it with no design/stylesheets so that there's no possibility the client decides they want to skip the design phase.

Nice job putting together this site in PW ljones, thanks for posting!

If you were changing the value of $config->http404PageID, then you'd need to do it before ProcessPageView::pageNotFound. As you mentioned, Page::render just isn't useful in this case. A good place would be in your module's init() since init() is called before the $page is determined. You could also do it in a before hook to pageNotFound, but I don't think you've got any more useful information at that point than you do in init(). This is unrelated to the above, but Module::ready() is a good replacement for Page::render in many cases. It was recently added to the Module interface as an optional function, and it works very much like Module::init() but is called after the $page is determined rather than before. To use, add a ready() function to your module, and PW will automatically call that function when the $page is determined and available in the API, but before it is rendered. As a result, it is a good replacement for before(Page::render), and doesn't require a hook. But note that neither Page::render or Module::ready is going to be useful for handling 404s.

I think that using pages in the system to maintain versions does simplify a lot of things, but it might be tricky and limited in others. If you are literally saving a version on every save, then you could end up with quite a large site tree and tables of data (whether visible or not). All the data in the tree is setup to be optimized for fast selection and searches. Everything is indexed. Past versions of pages don't really need that. So you end up with adding unnecessary overhead to the live tree. I am shy about the idea of having hundreds of thousands of pages in the system that don't contribute to the live site's data ... kind of like keeping all my past work projects on my desktop. But if you are in control of when you want to create a new revision (so that you don't end up with dozens-hundreds for each page) then the overhead might be a good price to pay for that capability. In fact, if you are using versions in a controlled and careful manner like this, then pages would probably be a good way to go. But if you are automatically creating a new page every time someone hits save, then I would be worried about the scalability of that. Either way, I like the way you are thinking about this and I think your ideas here have a lot of merit. The approach I took in the revisions module in development was to make a version on every page save() but just keep it JSON encoded in a flat table or files. I figured this is archived data and didn't need to be indexed in the DB. It prepares the array of data by calling each field's $field->type->sleepValue() function, which reduces the data for that page's field down to a format that can be stored anywhere. The big challenge is how to handle fieldtypes that involve files. I haven't solved that one yet. If you use pages to create your versions, you won't have to worry about that because PW's clone() function will take care of it for you. I wouldn't worry about things like users, roles, admin pages, etc. Instead, I would just suggest letting your module have a configuration option where one could check boxes next to all the templates they want to maintain versions for.

I wasn't aware of this, just added to issues list. Thanks, Ryan

I think that we do want to add module dependencies. It was always the plan, but I left it out just because it originally wasn't really necessary. Now that we're getting a lot of modules, it's time to finish it and add a 'requires' option to the getModuleInfo() where it can specify an array or CSV string of modules it requires. This will be used by the system when installing/uninstalling to check and see if it's okay to install and/or uninstall.

I'm not sure why that wouldn't be working either. It looks correct to me. I was originally wondering if there might be some condition where the 404 was getting thrown before your module was init()'d, but looking in the source I now see that's very unlikely. However, it is feasible if there is another 3rd party module involved that's getting init()'d and throwing it before your module is init()'d. Nico, can you describe more details about how to reproduce the case you are getting? For instance, when debugging this stuff, I think it's best to start with a stock installation with the latest source, that doesn't have any other 3rd party modules installed. That way we can remove any other factors that may be accounting for the different behavior. Then make sure it can be reproduced there. If it can be, then check to see if there are any other factors that might help Oliver reproduce it (like URL in address bar, etc.) Oliver, you may already be aware of this. But if you hook in before (rather than after) ProcessPageView::pageNotFound, you could change the value of $this->config->http404PageID to whatever Page ID you wanted. Of course, you could do that anytime before (like in your init) as well. Not sure if this is helpful in this case or not but just wanted to mention it.

Sinnut is right that there is already a revisions/history module in the works. It is already somewhat functional, but I've set it aside till version 2.3 as multi language support is the focus of 2.2. The edit/preview/publish workflow is already in PW to some extent, but you can only preview when something is unpublished. Once published, you no longer have a preview. We're going to be enabling that functionality by management of separate draft and published versions of a page, and it will technically be a separate component than the revisions/history module. Behind the scenes, it will work by making an unpublished clone of the original page that overwrites the published page only when you hit 'publish'. There actually isn't anything more to it than prepending the 3 underscores. PW takes care of the rest internally. But you do have to use some care in determining which functions should be hookable. When you make a method hookable, you are telling ProcessWire to handle the function call rather than PHP (and the fast low level C code that PHP is written in). So there is more overhead in calling a hookable method than with a native PHP one (regardless of whether any hooks are attached). Methods that are called hundreds or thousands of times aren't great candidates to be hookable because it may slow execution. You mentioned a desire to make something in PageFinder hookable. Which method? I can take a look and it and see if it's a good candidate for hooks and if so I can just make it hookable in the core. Also let me know what you are trying to achieve with the hook, as I may be able to suggest alternatives too.

Just realized that TinyMCE doesn't exactly maintain paragraph-to-line relationships very well, so there was a good chance that previous regexp wasn't going to work. Also realized there really isn't any reason for us to have a "youtube:" tag, when instead the "https://www.youtube.com" could be the tag we look for. Let me know if this version works? if(strpos($page->body, '<p>https://www.youtube.com') !== false) { $replacement = '<object width="420" height="315"><param name="movie" value="$1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="$1" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>'; $page->body = preg_replace('{<p>(http://[^\s<]+)\s*</p>}', $replacement, $page->body); } echo $page->body; Bow you can just past the youtube URL in it's own paragraph (skip the "youtube:") and that's all you need to do, i.e. https://www.youtube.com/watch?v=rEKDj1OOkhI

I agree with Adam that I think it might be best to explain to them what a URL name is. A page's name in the URL is an important part of it, so it's not something you'd want them to ignore. But you will have an easy way to change it with the new LanguageSupport in 2.2. You can change just about anything. For instance, you could change the English translation of URL name to be something this particular user might prefer.

I've never heard of it meaning anything other than "for your information".

Not yet, still trying to get my IE8 virtual machine going. I'm close!

Dom, that's not something I've seen before. I'm wondering if there's something about the server environment that is causing it to pick up the wrong url/path. Can you try placing the following into one of your templates, view a page using it, and let me know what it says: <?php echo "<p>PHP version: " . phpversion() . "</p>"; echo "<p>rootURL: {$config->urls->root}</p>"; echo "<p>SCRIPT_NAME: $_SERVER[sCRIPT_NAME]</p>"; echo "<p>SCRIPT_FILENAME: $_SERVER[sCRIPT_FILENAME]</p>";

Great points Martin. I think that lightweight markup languages (LML) like Textile and Markdown are in a lot of cases better with clients. The resulting markup is so much cleaner and maintains that integrity long term. And results in reduced support burden down the road. Plus, it gets the client into thinking in semantic terms rather than trying to "design" in the rich text editor. Still, everyone seems to want rich text editors these days, so I don't fight it. But if it were up to me, we'd all be using Markdown, Textile and the like. There is a ton of overhead that goes with TinyMCE and the like, and I'm not even talking about bandwidth and speed.

We can probably just use the :after trick? http://www.positioniseverything.net/easyclearing.html

Jasper, is this something where the output would ultimately be used for the front end of the site or the admin? I usually take the Helloworld.module as my starting point. But assuming it's not ultimately intended to be an admin Process module, then I think the MarkupRSS is a fine starting point, especially given that you want to make a Configurable Module. If you use MarkupRSS, you'll want to delete everything after the init() function, up until the getModuleConfigInputfields() function, and that will give you a better skeleton to start from.

Oops, thanks for finding that Soma. I've just fixed it in the live source so that emailSubject is no longer hard coded.

Soma, this is really a beautifully designed and developed site. Well done!

At present, you can't selectively take some pages from one site and import them to another without using the API to do so. Because PW pages can contain relational page references, external files, and parent/child structures, you can't reliably copy some bits of SQL from one established site and import it on another established site. (though I don't think you could really do with this with any modern CMS). But if you don't mind working with the API and taking it step by step, you can export from one and import to another relatively easily. Another option is that you can use the API to export pages to a CSV file from one site, and then use the CSV import module on another. It sounds like you may have already figured out how to do this to some extent. If the only problem is that you can't login, then I'm guessing the user accounts were part of what you copied over. If that's the case, you'll want to make sure that the last line in your site/config.php (where it refers to 'userAuthSalt') is consistent between the two sites. Also, for the future, the Profile Export module is worth looking at: http://processwire.com/talk/index.php/topic,583.0.html

The $page->created and $page->modified properties are meant to be internal and consistent with actual page creation and modification dates in PW, so they aren't things that can be modified by the API. While you can go directly in and modify it with SQL, it's better to create your own properties using PW date fields. There's nothing that you can't do with your own fields that you can do with those internal created/modified fields. However, at present, I don't think it does any harm to modify them in SQL, but just saying that it's not a best practice.