ryan

Joss–you are the man! You just made my day. I completely missed this before (I have Flash disabled). I came back to this thread to revisit some music links that people are posting. Thankfully one of Soma's messages here made me start to wonder if I was missing something. I'm completely floored you made a ProcessWire song, that's just awesome– Thank you for doing that, I love it!

Is 'timestamp' a field in your system, or one that you are assigning purely for runtime use?

Nico, I don't think that you can catch an include like that. You probably have to set a custom PHP error handler to capture it. It sounds like what you are getting is ProcessWire's error handler.

I don't think this error is coming from the Concatenate fieldtype, because it does not deal with the file system. I'm also not familiar with what a ".frm" file is? It sounds like there must be some other 3rd party module installed that is triggering this error, but I don't recognize the error or filename format. What modules do you have installed that might be manipulating files?

I think it's good to initially develop things in an isolated environment so that there aren't too many factors to consider. Especially with something fairly complex, as this sounds. So that's why I was thinking building it front-end and getting it working is a good way to get started. And once you've got that, converting it to another environment (like an Inputfield) becomes simpler. Yes, a Fieldtype can give an Inputfield a copy of the $page being edited. But as for "live" changes, you'd have to use Javascript, just like anywhere else. Modules are easy -- just a matter of filling in the required components. It's the other stuff you are talking about that sounds more complex. But if you want to learn more about module development, have a look at the /site/modules/Helloworld.module file. This wiki page on module creation is also a good intro: http://wiki.processwire.com/index.php/Module_Creation

There's also good old wget with the recursive option: wget -r http://domain.com

Horst, do you need to modify imageType and filename, or just need read access to them? The best way to handle this is with getters/setters, which I can add to the class. But just wanted to make sure I understood the need.

Thanks Antti. I merged your pull request. All seems to be working well after a brief test. Not sure why, but the 'Source' option still doesn't work in inline mode, even though they apparently fixed that in 4.1. The problem is it isn't semantic. It's one of those things that technically belongs with a site's styles rather than in the RTE. I'm hesitant to have anything non-semantic in our default set. This could be a good idea for the future, so I'll make note of it. But the scope of it would stretch beyond just the CKEditor module, so this is something I'd like to revisit later.

In the latest commit to the ProcessWire dev branch, the LanguageSupportPageNames module now supports setting the homepage name for any of the languages. It should work exactly like how you guys requested. For example, if you set the Spanish homepage name to be "es", then from that point forward, all URLs for Spanish are preceded by an "/es/". Likewise, if you access any path preceded by an "/es/" then the user's language is set to Spanish. If you access the homepage "/" then the default language is set. If you access the Spanish homepage at "/es/" then you get the Spanish version of the homepage. Lets say that you set your "default" language homepage name to be "en". In this case, all default language pages become preceded with "/en/", except for the homepage itself… I wanted to avoid having two URLs that render the same exact thing. Use of this homepage "name" is completely optional. You could choose to not use it for your default language, and then use it for other languages, or you could choose to not use it for any, or you could choose to use it for all. Basically, I think it'll accommodate just about anything you could want to do in that respect. Let me know if you guys get a chance to test it and if you run into any snags or other ideas.

Let me know if you discover any solutions for this, and I'll look at it too. It sounds like otherwise the 4.1 update is a good idea. Definitely. CodeMirror is great. The only reason we don't have it standard in TinyMCE is because of the language pack issue. Maybe that's not an issue in the CKEditor verssion--I will try it out. Much of this just depends on how they are configured. Both editors have an endless amount of settings related to pasting text. Currently I don't think we've got the right paste settings in CKEditor, just because it's generating a lot of inline styles in the process, for some reason that I haven't yet figured out. So this is something I could use help with finding. I think this isn't ideal either, because headlines, lists, links, bold/italic, also get lost in that type of paste. These are things you'd usually want to keep (or at least, I would). For instance, if I'm copying/pasting from one editor to another, or even moving text within the same editor, I don't want to lose this stuff. It's already there. If you know the anchor you want to link to, highlight the text you want to link, click the Link button, and type in the anchor name preceded by a "#", like "#myanchor". I think the big picture is that they are equals. But when you get down to little things, some may prefer one over the other. When in inline mode, it's using the admin theme's stylesheets rather than CKEditor's. I'm overriding a lot of things from the admin theme to make them more consistent with CKEditor's defaults in inline mode, via the InputfieldCKEditor.css file. But I don't think I've covered anything specific to tables yet, and probably need to.

The PageLinkAbstractor module will abstract those URLs to something that will work regardless of where you place it. Though I'm actually looking to make the PageLinkAbstractor module useless, by having the core take care of this abstraction instead. That way we don't have to search/replace when going from our development site subdirectory to production site at root (search/replace is what I do on the DB dump file when migrating a site). There has been one instance on I site I developed where I needed values from $config in one of my textarea fields. The way I solved it was to place something like the following at the top of my first include file (in that case, it was _init.php): // these are just examples of tag replacements I've used // but they could be anything... $replacements = array( '{config.urls.root}' => $config->urls->root, '{config.urls.templates}' => $config->urls->templates, '{url}' => $page->url, '{id}' => $page->id, ); // perform the tag-to-value replacements $page->body = str_replace(array_keys($replacements), array_values($replacements), $page->body);

ZipArchive does seem to be pretty widely adopted now. It wasn't when that existing ZIP code was originally written. I've been meaning to change it over to ZipArchive, but just haven't gotten around to it. It's on my to-do list.

Thanks Teppo, I will add this for sure.

Glad to see another Model-M keyboard user around here. I collect them. Right now typing on a white label Model-M mini from 1991. Thanks for the sketch, that helped to see, and I think I understand now. I think that your system could translate to pages quite nicely, but you aren't going to get that visual "grid" unless you either: 1) write your own Inputfield; or 2) build this feature on the front-end of your site (rather than the admin). Using a Repeater would be another way to accomplish this, but you'd have to be willing to re-envision the system using the inputs that come with ProcessWire. If I were building something like this, and needed that grid, I would probably go ahead and build it as a front-end thing, and map to pages, using API code.

I didn't realize they were stopping with modx revo? What will their product be then?

Sure. Though it's a little problematic because in order to be complete, every single page in the site would have to be visited and have a cache file generated for it. It's certainly possible to do on your own, assuming you can easily visit every page in your site (i.e. it's not too big). But if I build it as a "feature", then it has to be scalable to very large situations… not sure I'm up for that.

Probably so, I agree. Though stepping back to the idea of unpublished users: they don't really have a purpose other than short-term, between page edits. When you create a user, it doesn't give you the opportunity to "Save and Keep Unpublished". So the only way that an unpublished user exists is in-between the time that you create a user on the screen asking for the name, and the time that you save the user after entering their email address, etc. Or if you create the user, and don't finish.

With multi-language page names, the beginning "en" or "de" segment (as examples) aren't technically necessary, as the language can be determined from the page names alone. But I understand it may still be desirable, so I'll be looking for ways to handle that. But as for $page->rootParent, you'd probably want $page->parents()->eq(2) instead. Also Page::rootParent is hookable. Though I don't really want people to have to think about these things. This could be done by adding checkbox or page reference fields to check which languages you want to be included in any given children() or find() results, etc., and then making use of it in your selectors. If that became desirable as a core feature, we'd probably implement it in some way similar, behind the scenes. I will probably have to set it up to override the user's language settings when the page names module is installed.

Be sure to grab the latest, as I updated many things this morning. I haven't noticed this level of difference yet between TinyMCE and CKEditor. But if this becomes a common feeling among ProcessWire users, then we could always switch out the core default from TinyMCE to CKEditor. Though I would like to maintain them both either way. I noticed CKEditor doesn't seem happy to paste text without inserting a bunch of style attributes into it... which is annoying. But I'm sure there's a way to configure that out of there, just haven't figured out how yet. The current dev version of CKEditor does support allowed content rules in a manner similar to TinyMCE, but the stable version [that we are using] apparently does not (?).

CKEditor for ProcessWire CKEditor is a web text editor like TinyMCE. This module can be used anywhere TinyMCE can be used in ProcessWire and it is generally considered one of the best web text editors out there. TinyMCE and CKEditor have always been the two big leaders of web text editors, and they've been equals for many years. Though lately it seems like CKEditor might be a little ahead of TinyMCE in some areas, so I thought we should give people the option of using CKEditor with ProcessWire. CKEditor has a nice inline mode that is desirable in the page editor when you may have lots of rich text inputs. The reason for this is that the page editor loads a lot faster. If you have this need, this would be one reason why you might want to use CKEditor over TinyMCE. Some also prefer CKEditor for other reasons. For instance, @apeisa prefers the table controls in CKEditor to TinyMCE's. Here are a few notes about this module: You already know CKEditor–it's what this forum is using. Though the version included with ProcessWire's module is significantly newer. It is currently beta test. You are advised to test thoroughly before using it in production. You may very well run into bugs, in which case please let me know so that I can fix. It is tested and confirmed compatible with both repeaters and multi-language support. It is now fully hooked into our link and image systems, like TinyMCE. Thanks to Antti for helping with the image plugin. If you want to use the inline mode, you'll need to install the HTML Purifier module first. The toolbar is fully configurable. It is multi-language ready and all text in the module is translatable. Like with TinyMCE, the module optionally supports definition of custom plugins and content.css file. How to install Copy all the files from this module into: /site/modules/InputfieldCKEditor/ Login to your admin and go to Modules > Check for new modules. Click install for InputfieldCKEditor. Now go to Setup > Fields and locate a textarea field that you want to use CKEditor (or create a new textarea field). When editing the settings for a textarea field, click the Details tab. Change the Inputfield Type to CKEditor and save. While still editing the field settings, click to the Input tab for CKEditor-specific settings you may optionally configure. Download ProcessWire Modules page: http://modules.processwire.com/modules/inputfield-ckeditor/ GitHub Repo: https://github.com/ryancramerdesign/InputfieldCKEditor Screenshots Screenshot of regular mode: Screenshot of inline mode, combined with multi-language fields:

The project you are doing does sound like a good fit for PW. I'm not sure I totally understand what a slot-picker is, so it might help to see a screenshot of what you are trying to achieve. But if it's something you will ultimately relate to pages, then need only make an Inputfield module that extends something like InputfieldSelectMultiple. If it's something where you want to handle the data storage separately, then you'll need to make both a Fieldtype and related Inputfield module. But give us some more details on this slot-picker (screenshot, if possible) and we can take it from there.

When the cache is fully populated, you could do this. You could literally take everything in the /site/assets/ProCache/ dir, move it to the root on another web server and it would function statically. You would also need to have your other static assets copied over too, which I think would be limited to these dirs: /site/assets/files/* /site/assets/templates/styles/* /site/assets/templates/scripts/*

Thanks for confirming. A fix has been pushed for this.

Adding this to your .htaccess file might do the trick too: AddDefaultCharset UTF-8 Make sure your document is also specifying a <meta charset>.

Please send a cold keg of Unibroue La Fin Du Monde, and I'll have my tap ready. Just kidding, but that's one of my top 3 beers and has been for a long time. Canadians know how to make some damn fine beer, that's for sure. Luckily it's easy to get around here. A good thing, because Georgia has some kind of laws about shipping beer (to protect the poor beer/wine distributors).