ryan

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.

Wow, looks like we're about to go exponential on that graph there. The singularity is near!

The 404 page is a system page, so it's a special type of page that has a predefined purpose in the system. It's best to leave it where it is and work with it. What I would suggest is creating a new template and assigning that to the 404 existing page. That template should display a "page not found" message in multiple languages. But if you wanted to take it further, you could detect language was at the beginning of the URL (via PHP's $_SERVER['REQUEST_URI']) and output a language specific version, or pull in another language-specific 404 page and echo $otherPage->render(); Since there are multiple routes you could take here, from very simple to more complex, this may be something worth leaving to the individual installations to handle on their own according to their needs.

formmailer, try this: #CommentForm_text { width: 75%; }

No problem–this has been added to the issue queue at GitHub.

That preview looks awesome. I can't seem to get it to work here though (FF7). I'm getting a JS error "event is not defined" on this line in InputfieldCropImage.js: if( event.type === 'mouseover' ) {

Check your file permissions, I'm guessing that Apache can't read the new /wire/ directory. Also make sure that the entire /wire/ structure is there. The error that you are getting is a result of PW not being able to find or open this file: /wire/modules/Process/ProcessPageView.module

That's correct that the majority of the installation is all done by the installer. Here are the current install directions from the readme file (below). If anyone's found lack of clarity here, maybe it would make sense to repeat them in more places (it can't hurt anyway). INSTALLATION FROM ZIP 1. Unzip the ProcessWire installation file to the location where you want it installed on your web server. 2. Load the location that you unzipped (or uploaded) the files to in your web browser. This will initiate the ProcessWire installer. The installer will guide you through the rest of the installation. INSTALLATION FROM GIT 1. Git clone ProcessWire to the place where you want to install it. 2. Load the location where you installed ProcessWire into your browser. This will initiate the ProcessWire installer. The installer will guide you through the rest of the installation.

To save module config data, put the data you want to save in an array and then call the $modules API var with the saveModuleConfigData function. <?php $data = array( 'something' => 'Well hello there', 'something_else' => 1234, ); $module = 'ModuleClassName'; // can also be instance of module wire('modules')->saveModuleConfigData($module, $data); ProcessWire will automatically set the keys from your configData to the module when it loads, so you don't have to do anything else. As a result, your module could call upon a value like $this->something; and the value would be there. Or if you want, you can add a setConfigData(array $data) function to your module, and it will set the config data to that instead (when the module is loaded). Though I rarely do this. To retrieve a module's config data from another module or elsewhere in the API, you can also use $modules->getModuleConfigData('ModuleClassName'); Use it like this: <?php $data = wire('modules')->getModuleConfigData('ModuleClassName'); echo $data['something']; // displays 'Well hello there' The $data would be the same array that you set in the first example.

This line failed to load a user: $u = $users->get($uid); User ID 40 doesn't exist in the system because anytime PW returns a NullPage that means it didn't find what you were looking for. The best way to check if you got a NullPage is to see if the returned has an ID. So your last section of code should be something like this: if ($u->id && $u->hasRole($role)){ ...stuff } Btw, ID 40 is the default ID for the 'guest' user account, so it would be unusual if that really is the ID of the user and it didn't load.