ryan

Actually, I wasn't even thinking of TinyMCE, but you are right that would be an option. What I was thinking of was a shared assets page, and I use them on a lot of sites already. Language-specific pages could pull from those shared assets like any other page, i.e. <?php $masthead = $pages->get("/tools/shared/masthead/")->images->getRandom(1); $alt = array( 'en' => 'Masthead', 'de' => 'Impressum' ); $lang = $page->rootParent->name; echo "<img src='{$masthead->url}' alt='$alt[$lang]' />";

For security reasons, PW forces a "403 forbidden" if someone tries to directly access any PHP files in the /site/templates/ dir, as well as several other locations in PW's file system. So it's best not to put any PHP files that you need to directly access in any of ProcessWire's directories, because there's a good chance it'll block access to them. Here are a few alternatives: Option 1. Place your sendemail (and optionally phpmailer include) files somewhere outside of PW's directories. For instance, maybe you could create a dir called /form/ off your web root and place them in there. Then set your form to: action='/forms/sendemail.php' Option 2. Use your sendemail.php as a ProcessWire template. Create a page using that template, and make your form post to that page. Option 3. (the one that I use most often) Make your form post to the same page that it's on (i.e. action='./'). When you see one of your POST vars present, include your form processing script. i.e. <?php if($input->post->submit) { // process contact form include("./includes/sendemail.php"); } else { // output contact form }

$page->created …will give you the unix timestamp, or you can use PHP to format it however you want: <?php echo date("F j, Y, g:i a", $page->created); // October 10, 1974, 11:28 pm http://www.php.net/manual/en/function.date.php

PW's page cloning supports images/files too. I suppose it just depends when the cloning takes place as to whether the images are duplicated there. You never really know if an image is going to need to be language specific or not, though it's description (alt tag) would be. I tend to think it's best to follow a path of more duplication here rather than trying to squeeze out some efficiency benefits in less duplication. Either way, any kind of image or file mirroring would seem more like a luxury than a requirement, in my opinion. If I were building a multi-language site, I would probably keep some pages for shared assets (outside of the language trees) and pull shared images from there when necessary. I'd reserve the on-page image and file fields for language specific stuff, not to be cloned across trees. @Pete: Technically it's not different than any other web service for sharing content, except that it's a little more custom and deals with larger sets of data. This particular one is specific to a company intranet, so there aren't public examples I can link to. I won't get into the unique parts since it's not my own site, but can describe the general ideas common to most web services of this kind. The master server has a REST-based web service, which I just built with a template and assigned it to a page. That web service lets you query PW with selectors and it responds with JSON results containing all page data. The other web servers query the web service from a cron job calling PW's API from PHP command line scripts. They look for pages that have changed since the last query, and re-populate all the page's fields with the data parsed from the JSON. It mirrors all fieldtypes including files and page references, as well as child pages. It determines if something has been deleted by it's lack of presence in the JSON feed. If there's a page on one of the servers with a master_id that no longer appears in the feed, it moves the page to the trash and ultimately deletes it. This system deals with tens of thousands of pages, so it doesn't all happen in one request. Let me know if I can answer any more specific questions about it. Though maybe we should switch to another topic so we don't hijack this thread.

What you are describing is similar to PW1, where you would set the field's label/description information individually on a per template basis. I think there are two sides to it. First off, it's very worthwhile to be able to have one page say "Press Release Headline" in one template and another say "Full Name", but have them both refer to the same field (be that 'title', or some other field). But the flip side is that you end up with less consistency and familiarity between templates. From a developers perspective, it's also more challenging to connect fields on the front end with your usage of them in the API in your templates. Still, the pros outweigh the cons, and especially so if it reduces the number of fields you need to accomplish your site's goals. So rest assured, I totally agree with the value of it and we'll have this at some point as a module. But I've considered it more of a luxury than a requirement, so it's coming but I haven't yet penned a date to it.

Not sure if this all applicable, but I'll mention it because I think it gets into the two issues you mentioned. You may already be doing something like this. But I'll type it out just in case any of it is worthwhile. I do some cross-site syncing where pages from one PW site are duplicated on other PW sites and then mirrored every hour. The sites have different structures, so the mirrored pages have to remember where they came from. This is accomplished by maintaining a 'master_id' (integer) field on every page. That field contains the ID of the page at the originating site. So even if the page is moved in the structure, it continues to be mirrored since it's master_id will never change. If I want a given page to stop mirroring, then I just set it's master_id to 0. Perhaps in your case, keeping a master_id field containing the ID of the page it was duplicated from would ensure that it could continue to be synced regardless of where it gets moved to in the future. Since synced pages would be sharing the same template as the master, they would both have a master_id field. So one way to differentiate the master from the others would be to use a signed ID… they both have the same number, but the master has a positive and the other(s) have negative number (master_id * -1). Canceling the mirroring at either end would just mean setting it to 0. Any templates you want to mirror you would add a master_id field to in Setup > Templates. Your $pages->save() hook would monitor pages that have this field and populate it when creating a page. Likewise, they would create the corresponding page(s) (with the negative master_id) as child(ren) of any other pages that had a master_id equal to the saved page's parent_id * -1. If you didn't want the parent to be mirroring, but you wanted its children to mirror, then the master parent would have a master_id of 0, and the other corresponding parents would have a master_id of the master parent's ID * -1. I think that the default would be that any page created that has a master_id field in it's template would be assumed to be mirrored until you set it to 0. I may not understand the full scope of your needs, so correct me if I'm wrong… but wouldn't this sort of approach be a simple solution to the two issues you mentioned?

Much of this defers to the GNU v2 license. My thoughts are that people should feel free to make their own admin theme and put their logo (or their clients logo) wherever they see fit. But regardless of admin theme, I do think the software name ProcessWire, version number and copyright should always remain in the footer of the admin at least. The reason for this is that I don't ever want ProcessWire to be a burden on a client. Web sites very often outlive the relationship of the site developer to the client. I think it's important for the client to know what software and version they are using and where it came from. Without that, if some future issue surfaces, the client would be blind and ProcessWire would be a burden on them. Can you imagine white label installations of any other major open source CMS out in wild, and what a security nightmare that would be? Keeping this information in a place where the client can find it keeps everyone honest about how the software is licensed. If someone just provided a re-branded PW to a client and charged them $25k for it, I think it's important that the client knows they are paying for a service from their developer and not the software. If a company still felt strongly that they needed to remove the software name, version and copyright from the admin, then I'd want them to keep and maintain a long term support contract with us and make the GNU license really clear to the users of the software.

Awesome update! I just dragged in 6 files... beautiful! Even better now that I can just drag them anywhere in the field. Thank you for your fantastic work with this. I'm going to dig deeper into your code here soon so that I can figure out how to get this to be built-in to the WireUpload class.

Great job Pete! Very cool to see this integration, and looks like you've really done it nicely. Thanks also for posting this screencast, it was great to see this in action. As a side note, I noticed that there were no margins between the individual fields in ProcessPageEdit (in your screencast). Just wanted to check if you had changed something in PW's stylesheet to do this, or if that's the way it displays for you? If so, it's a bug, and I'd like to find out what version of Firefox? Thanks, Ryan

Thanks for finding it. It's a bug. Just fixed in the latest commit.

Very cool. Seems like a handy thing! Though also a little sad that we have to do this for IE. But that's life, and this seems like a good way to deal with it. Is there any advantage to doing this with the <html> tag as opposed to the <body> tag?

Thanks for your thorough investigation into this issue. I agree it is a strange one. If you find some way we can bypass it, I'll be glad to update PW's code. Though I don't currently have a way of testing this issue (running on different platforms). This would be tricky because the process that handles uploads is completely different from the process that handles image manipulations. ProcessWire expects a file to be part of it's file system before it starts manipulating it. So while I'm sure it's possible, it's not a straightforward thing because it would be an architectural change. I'm wary of architectural changes to support an obscure bug in Windows. Here's something I found in the user comments on the unlink documentation page at PHP.net that has me wondering: Doesn't exactly sound like a cross-platform compatible solution, but maybe a hack to make it work in Windows. If you find something like this works, let me know and we can always make it perform this action if it detects it's in Windows (or perhaps with a config option).

Pete, take a look at /wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js in the latest commit. Yesterday I added the ability for it to do single-to-multi char replacements, specific to some German characters that Soma (issue #41) found weren't translating correctly. But the same approach could be used to convert '&' to '-and-', just by adding it to the 'srch' and 'repl' arrays in there. I would go ahead and add the '-and-' in there if I could assume the language was English, so I think you are right that we may eventually need a multi-language support solution for this.

For a system that doesn't yet have multi-language support, this sounds fairly custom to me. But my experience with multi language sites is so far limited to just talking about it in this forum. I'm not sure that I understand 100% what you mean, though I do get part of it. I'd always like to keep PW as simple and open-ended as possible. I'm wary of forcing people into one approach or another, or dedicating all resources to a specific approach. We need some multi-language support in fields themselves specifically for the admin-side of things. But this isn't necessarily ideal on the front end where a multi-tree approach is more of a best practice (especially when it comes to search engine indexing, bookmarking, linking, etc.). So my hope is to ensure that the system if flexible enough to adapt and let the developer determine the best approach for their site. I'm excited about what LorGG is developing as it sounds like it streamlines the multi-tree approach.

I agree that the #3 option makes sense. Though thinking we might change the word "parent" to "parents", so that it clears all the way up the tree to the homepage. This seems simple enough. Pete those are great ideas about locating all the pages with references to the current and clearing those as well. Though I'm afraid to go there because the only way to really guarantee that a site is up-to-date is to expire the entire cache. We can track some things (like page references) but not others. So I worry about the ambiguity of any cache clearing options that involve an unknown set of pages ahead of time. Doing so may make some people think that PW may be smart enough to figure out everything that needs to be cleared. If there is one thing that causes confusion among clients, it's always caching, in my experience.… Client says: I respond "go save the homepage, or just wait an hour, it's on a cache". I've dealt with so many of these support calls in the past, that I tend to use the cache sparingly. A possible 4th option would be one that Antti mentioned earlier, which would be to provide an InputfieldPageListSelectMultiple that lets you specifically select all the pages that should be cleared. While I'd rather make it "clear pages using these templates", the truth is that clearing specific pages (rather than pages using specific templates) is quite a bit simpler to implement in the current system. Though I'm going to toy around with the current cache system sometime to see if there might be a way I can get that per-template cache clearing. Caching is always a compromise… my opinion is that most people should start with no caching, and only turn it on when they find they need it. And if they find they need it, they should take a close look at the MarkupCache too. But I'll work to expand the caching options, as I think these open a lot of doors to PW's use in high traffic sites.

Definitely major marketing value in this. This is one of those things that will be great to show in the PW 2.1 "what's new" video.

The plan is to add an "advanced" section (default collapsed) in the TinyMCE link editor where you can specify things like class name, title, target and rel. I put it on my to-do list a little while ago because I've had several occasions where I needed to add a class attribute to a link, and don't like having to go in and do it in the HTML view (and don't like telling the client to do that). I figured if I added that, then it makes sense to provide options for other <a> tag attributes, so rel will definitely be one of them. This isn't officially on the roadmap because it's a small update that won't take more than a couple hours, and will get put in whenever there is time. So now that I know there are others with a similar need, it'll likely come sooner rather than later.

Nice work! Thanks for posting. Very good use of videos and quality production throughout. What do these conditional comments mean at the top? <!--[if IE 9 ]> <html lang="en" class="no-js ie9"> <![endif]--> I hadn't seen the "no-js ie9" before (and all the others for IE), so was curious about that.

Finally got a moment here to install and test it out. What can I say, it's awesome. Love it! This is how I'll be uploading files from now on. I'm thinking this must go in the first version of 2.1. One question is if there needs to be a 'drop area'? Is it possible to just have the entire field be a drop area?

If you want your custom 'date' field to be one that can be sorted on, check the box for 'autojoin' in the field's advanced settings. That's the only technical requirement to make a page sortable by that field. Following that, you should be able to select it in your page's children tab as the default sort. Multiple sort parameters in your selector are just fine, and ProcessWire supports this as long as those fields are 'autojoin'. It also sounds like you may need to add a time component to your 'date' custom field, so that you can sort by two entries in the same day. PW supports this, but you have to include time codes in your date input format, i.e. "dd-mm-yy H:i" where "H:i" is the time component (hours and minutes). (If you need them, here are the full set of date and time codes used by PW: http://www.php.net/manual/en/function.date.php).

Thanks Doolak, that's very kind of you. That makes my day when I hear someone likes ProcessWire so much. I will do my best to make sure it keeps getting better and better.

ProcessWire doesn't attempt to do any pagination with a "limit=1", so at present, you need at least a "limit=2" in order to paginate. For the 1969 date, that's the first value a date can have in a unix timestamp, so it basically means there is no date set. I'm guessing that the "default to today's date" was added sometime after the pages with 1969 were created. Either that, or that the field was added to a template but a date wasn't set in all the pages. The default is only set when you edit a page, so you would have to edit and save a page for it to pull in that default if it didn't have it before. In your case, what you may want to do is skip over the fields that don't have a date set: if(!strpos($page->date, '1969')) { // output your date } I'm trying to think of ways to avoid this problem from the core. Perhaps I should have PW return blank, rather than a formatted date, when the timestamp value is 0.

Just watched the screencast and it's great! Now I understand what all the excitement is about. I haven't yet installed it–only a few minutes left before I have to go, but planning to install first thing tomorrow morning (or later this evening, if possible). Love the way you did the progress bars. This all seems like quite a fantastic UI option for uploading images or files. Well done!

I agree that this is probably too specific for the core. But you can achieve this pretty easily and automatically just by doing a str_replace before outputting the field. So I recommend adding something like this (below) somewhere in your template before that field is output. This will automatically add a rel='nofollow' attribute to any external links: <?php $page->body = str_replace(' href="http://', ' rel="nofollow" href="http://', $page->body);

Any time you get "Unable to complete this request because of an error", you can get more details about the error by either enabling debug mode (in site/config.php) or looking in your log file at /site/assets/logs/errors.txt. I don't see any reason why it should be erroring out, so am curious to find out more. But I did notice that one one example you referred to a "news" template and another the "news_article" template... are these two separate templates?