ryan

Someone correct me if I'm wrong, but IE9 doesn't support the HTML5 FileAPI, which IE10 does? To drag files into the browser and have them upload using HTML5 methods, the browser has to upport FileAPI. The only modern browsers that I know of that don't currently support that are IE9 and Safari.

A default value that is displayed but not stored is really no different than having no default at all. But one might assume that they could go perform a find() or something and match pages having that default value, and you couldn't. So it introduces some confusion there. There's also the danger of the default value getting set back to the field and inadvertently saved. That's why I kind of prefer letting the developer decide when and how to implement their default value in their own code. There's no ambiguity about it. But I do still think we'll want a "populate for new fields" like Adam mentioned, for some fieldtypes. The best example is a checkbox that you want to be checked by default.

Remove the "autoload" and "singular" lines from your getModuleInfo function.

I think that much of it would be simpler to implement than with TinyMCE, as the API looks super-simple and straightforward. At the same time, I don't think this editor is anywhere near as broad in scope as TinyMCE, but it probably crosses over with much of what we like TinyMCE for. I don't think we'd want to put a lot of time into building full integration around this editor, given the ambiguous license that says it's GNU compatible but obviously isn't. But I do think it's worth some trial and experiments. Rather than have anyone buy a developer license, we'd probably just include in the instructions where to download Redactor and where to put it's files. Then if people are really liking it, we can go for the developer license to make installation a 1-shot deal. But I think we'll have to keep this 3rd party (non-core) to avoid license interference.

Ouch I thought we were in the clear with IE9. But it's not a browser I use every day (running in OS X). Can anyone else confirm the issue? I'm not at a place where I have any access to IE. But the issue does sound like one that should be fixable on our end rather than TinyMCE's (since the add image implementation is part of our own TinyMCE plugin).

Glad you were able to solve this. Sorry I'm coming to the conversation late. You would have to do the same things to support Apache's RewriteEngine in any CMS. Most CMSs use this for URLs, so it's rare to find a web host that doesn't have it enabled by default. But if you are setting up your own *AMP that's not pre-configured for web hosting, then you do have to go through the steps you just did to solve it. Many legacy CMSs (like EE for example) came from a time before Apache's Rewrite Engine was used much, and thus had dynamic variable URLs and /index.php/path/to/page style URLs. These are a little simpler if you are starting from scratch on your own server, but you'd never want to launch an actual site using this style of URLs. As a result, support for that has been left out of ProcessWire, and it requires Rewrite Engine.

Thanks for the kind words, glad that you are enjoying ProcessWire. Regarding the module, I agree that Antti's Thumbnails module is probably the best one to look at since it is the only one I know of that lets you manipulate images in the admin like this. This line above I wasn't sure about. What you are attempting to do is add a "kelvin" method to a class called "Images". But I'm not aware of any class that we have called "Images", so don't think that this hook would do anything at present. Instead, you may want to add it to the "Pageimage" class: $this->addHook('Pageimage::kelvin', $this, 'kelvin'); public function kelvin($event) { $arg1 = $event->arguments[0]; // if needed $arg2 = $event->arguments[1]; // if needed $image = $event->object; // Pageimage object you are operating on // ... } That's assuming that the module goes the route of Antti's Thumbnails module. But if it's something that continues in the direction of the posted module code example, then it probably doesn't fit as a Fieldtype. Also, all Fieldtype modules should descend from the Fieldtype core class (or one of the other Fieldtypes descending from it).

I would probably just do as you said and give them a message. You could also have the module refuse to uninstall until they remove the directory by throwing an exception: if(is_dir('/path/to/views/')) throw new WireException("Please remove your /path/to/views/ dir before uninstalling."); I have added this update to the dev branch if you want to try it out: https://github.com/ryancramerdesign/ProcessWire/commit/bd5e549bc187a91cda47330181d5481674c41003

I think this would be the way to go, solving it with terminology. However, if someone is going to have a lot of the same default value in their database, it would technically be better for them just to leave it blank and then assume the default value from the API side. That way you aren't storing a bunch of duplicate entries in the database. It also solves the issue of what to do when the needs of the default value change. Beyond the issue, this is partly why there isn't a default value in PW now, because I've always used blank to assume a default. Automatically-populated or default values seem like an easy way to store a lot of redundant/duplicate values in the database, making it very unnormalized. So while it seems useful to have default values on the surface, I think there are a lot of cases where they introduce unnecessary overhead.

That's assuming a full implementation that duplicates all that's being done with TinyMCE. But a simple implementation that uses Redactor's built-in tools for this stuff could be done more easily. Though, I don't think that ProcessPageEditImage or ProcessPageEditLink are dependent upon TinyMCE. Or, if they are, that dependency isn't necessary. So it should be possible to use these processes with other editors (maybe with a few tweaks). The stuff that's in the pwlink and pwimage plugins is primarily just a way to connect the Process modules to TinyMCE, so would just need to code something similar for Redactor. True, it's not super-simple, but I'm guessing it'd be a lot simpler using Redactor's API than it is with TinyMCE.

I agree and that's the way we'd have to do it. I think there will be some that don't understand why the old default value is still present in places after they change the field's default value, but that will just have to be the compromise.

Interesting, that FAQ answer is pretty clear. So they want us to pay $99 and then it can be included in the open source project. I'm okay with that part of it. But that still wouldn't make it GPL compatible, I don't think. That is, unless someone could then take Redactor out of ProcessWire and then use it for something else (also GPL) without paying them the $99 fee? I don't think that would be okay with the Redactor developers. Too much ambiguity for lawyers to have fun with. If we build a module out of this, it would have to stay non-core (3rd party), and not sure exactly what license could accompany it, but I'm sure there's something.

Redactor does look very nice! I was really interested till I saw the license--looks like it uses a commercial license, so not something we could build a module for or include with PW, etc., because it's not GNU compatible. I certainly understand why they would choose to license it the way they did, but it couldn't be considered as aTinyMCE/CKEditor substitute since its licensing context is so different. Still a good find though!

Yeah looks like a bug to me too. I'll take a closer look at this. While it has come up before, it doesn't look like I had put a reminder to myself in the GitHub issues yet, so just did that. Thanks for pointing it out. I'll work on a fix.

Currently you can't specify a default value for most fields in ProcessWire. However, it can be supported at the individual fieldtype level. For instance, the date/time fieldtype supports defaulting to today's date. We will likely add more thorough default value support to many fieldtypes in the future, but I'm a little worried about it because I know it will lead to some confusion... especially when you want to change the default value, and there are already old default values on pages.

I don't think it's practical for us to maintain one board per module, nor do I think any major forum software is designed to scale boards rather than topics. But I understand the desire behind the request -- longer term there will be some modules that need more than just a forum thread. In those cases, I would suggest that the module author setup their own forum or link to a GitHub support/issues page or something like that. In the modules directory, we just ask for a support/forum link. It doesn't necessarily have to be in processwire.com/talk/.

Looks cool Adam, I look forward to checking this one out!

I don't think it's a related behavior here. Ultimately $this->config and wire('config') are the same call. But $this->config gets passed through a __get() method method, so it can be interrupted if __get() gets overridden and doesn't pass control to wire() when it finds an unrecognized property. It's still a mystery to me as to why $this->config didn't work in your module.

I'm not sure how to answer just yet, but will take a look at this one when I get back next week. However, a good alternative might be to use the Language Alternate Fields (halfway down that page).

If you are running the latest commit of ProcessWire, there's not really any reason to run this module more than once. And when you start a new site today or in the future (using the latest version of PW), then there's no need to run this module ever. I think this module would only be worthwhile as a recurring maintenance task if you are running an older version of ProcessWire. The only other situation I can think of is if you had files fields on some pages and later removed the files fields, the directories would still remain as long as the page existed, and this module would remove them.

Thanks for your updates to this module, and for posting to the modules directory. My opinion is that the more you can help the user, the better, so long as it's something that can be removed in the same way during an uninstall(). If it's something that would be more tricky to uninstall, then maybe better to let the user create it so that they also have some ownership if/when it comes time to uninstall. Just to confirm, you want to have a way to prevent ProcessWire from throwing an exception when a method is called that it doesn't recognize? You could definitely override it for any given class, by extending the class and defining your own __call() method, but that will only affect calls to that particular class, and I'm thinking that's not what you want. It will be relatively simple for me to make PW's behavior (as to whether it throws an exception or not) configurable, so that may be the best bet, unless there's some way for Twig to catch the exceptions and continue normally.

Adam I'm not sure I understand the question fully, but if you want to poll for what functions are available in a given class, definitely take a look at PHP's Reflection classes (included with PHP5) as I think they may fit the bill for what you are asking. ProcessWire also uses them in a couple of instances, though for something different.

Actually I think your screenshot reveals the problem. Take a look at the "Filename is:" line: D:/wamp/www/pw-2.2/site/assets/files/1\lala_restaurant.0x100.jpg Notice how the slash right after the "1" is a backslash rather than a forward slash. Then notice that the Pagefiles path is correct (ending with a proper forward slash). Now the question is where that backslash is coming from. I'm really starting to wonder about a PHP bug here. Look at how PW constructs that filename: $filename = $this->pagefiles->path() . $basename; We already know that $this->pagefiles->path() ends with a proper slash from your screenshot. It's getting replaced somewhere. But I don't see any code between the two functions that manipulates it. I need to get XAMPP installed on my wife's laptop so I can properly debug this. Thanks for your help testing here.

I'm guessing Media Temple? That's the only place I've seen allow_url_fopen disabled. It is only a security risk with poorly written PHP code. Anything powerful is a security risk if it's coded blindly. Disabling allow_url_fopen makes a host feel more secure because they are placing extra limits on what you can do with your web hosting account. It means they don't have to have as many people looking after things (drives profit). It also means you have a disabled web account. Unless you are getting free or super-cheap hosting, I would not consider this type of intentionally-limited account unless there is an override for those that want it (like being able to specify your own php.ini to enable such things).

You can call the getChanges() method on any object in ProcessWire and it'll return a plan array of field names that changed. So what I think you are looking for is $page->getChanges(). This assumes that change tracking is enabled for the page (which it usually is). $page->setTrackChanges(true); // true to turn ON, false to turn OFF $page->resetTrackChanges(true); // clear the change log and start tracking again $changes = $page->getChanges();