ryan

While they can't be included in an actual language pack (which is meant for translating the static text in PHP files), they can be exported as SQL dumps. The profile export module was written before multi-lang features existed in ProcessWire, and I need to update it to support it. But it should be fine to create your own SQL dump with translated field names, etc., and import that (via mysqli client, phpmyadmin, etc.) when needed.

It's worth mentioning that wire('input') or wire('any API variable') would in fact work everywhere. So if you only needed to remember one way of accessing API variables, that one would be the most portable.

Selectors have to have a defined value after the operator. There is no defined value in "modified>created", as those are two fields. You can go straight to SQL to accomplish this one: $pageIDs = array(); $result = $db->query("SELECT id FROM pages WHERE modified>created"); while($row = $result->fetch_row()) $pageIDs[] = $row[0]; $pageArray = $pages->getById($pageIDs); // $pageArray contains what you want

At the top, I'm thinking you want to add something to avoid acting on pages that aren't of your defined type. Something like this: if(!$page->template != 'project') return; Because this is a single-page reference field (from what I can tell above), I don't think this line would work: $page->project_status->remove(1157); That's calling the remove() method of $page, which just unset a value. Since the page likely doesn't have a variable named "1157", the line above essentially does nothing. What you would want to do instead is set project_status to be a blank value, or another page. $page->project_status = null; // this $page->project_status = $pages->get('some other page'); // or this

Sounds like a typo, is that would only work on an image field set to contain a max of 1 image. Where did you find it?

Since you are using the PageEditPerUser module, I'm thinking you'd want to edit that one rather than Page Edit. Another alternative is that you could just setup alternate templates, since access is managed there by default. But if you go the PageEditPerUser route, you'd want to modify it to hook into "Page::addable" in addition to the existing Page::editable. The "Page::addable" hook works in basically the same way as the editable one. If you want to see the default logic built into it, the Page::addable function can be found in: /wire/modules/PagePermissions.module

Thanks Michael, I have updated it to have the Sourcedialog plugin and that seems to work nicely. It is now the default option when creating new CKEditor fields. If you've already got CKEditor installed, you'll need to make a couple replacements in your "Setup > Fields > [field] > input" tab. In the "CKEditor Toolbar" field, replace "Source" with "Sourcedialog". For "extra plugins" replace "codemirror" with "sourcedialog" (or just add sourcedialog if codemirror isn't there).

Some additional updates posted to the LanguageSupportPageNames module. Previously you could only define multi-language page names after the page already existed. Now you can define them when you are adding the page. See screenshot.

Didn't realize that Chrome supported in-editor resizing. That's new. It didn't used to. Thanks for finding it and for the PR, I'll check into this here this week.

It looks okay to me. I would double check that $timestamp is an integer (which PW wants if you set it as a literal unix timestamp), so you may want to typecast it: $timestamp = (int) $timestamp; PW will happy take a string or integer, but if it's a string, it assumes it has to run it through strtotime() first. Whereas if you give it an integer, it knows it's a unix timestamp and doesn't attempt to translate it.

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?