matjazp

I think that Adrian fixed that in the latest version of Tracy, if I remember correctly...

I think that function wireInstanceOf() is not available in 3.0.42. Upgrade to the latest master.

What do you mean by "windows machine with no ACL"?

Ryan fixed it already...

Would you mind testing my fix https://github.com/processwire/processwire-issues/issues/480#issuecomment-372398223

Please check the width classes applied to inputfields, it looks like all non 100% fields get uk-width-4-5@m

@Christophe count() warning is coming from php 7.2, but you won't get this warning if you upgrade to the latest dev and you can keep php 7.2. Not sure why you get array to string conversion notice...

Downgrade php, install the latest dev or wait a week or so for the next master.

It's doable with datepicker https://stackoverflow.com/questions/2208480/jquery-ui-datepicker-to-show-month-year-only but I don't know how one could "hook" to datepicker inputfield and pass some more options (at least onClose callback). I'm sure js gurus can help here ...

@kongondoWould this work? Just a workaround, until Ryan fix it... $rootPath = "F:/vhosts/sandpit.dev"; $sitePath = "site-mediamanager"; $url = "http://mediamanager.sandpit.local/"; $cfg = Processwire::buildConfig($rootPath, $url, array("siteDir" => $sitePath)); $site = new ProcessWire($cfg);

Yeah. As / is prepended to the $rootPath. Maybe you could rename site-mediamanager to sitemediamanager and also modify .htacces to reflect that change? But this is a hacky approach. Ryan must fix that, shouldn't be a problem (and also the realpath() where path contains ..)

I don't use multi-instance support but looking at the code it's a bug for me. The culprit is here: $parts = explode('/', $rootPath); Since windows path doesn't start with a slash, $parts is different on nix and windows. Temporary detour (until Ryan fix it) could be using / as the first character in the path: $path = "/F:/vhosts/sandpit.dev/site-mediamanager"; // OR // $path = "\\F:\\vhosts\\sandpit.dev\\site-mediamanager" I'm not sure what impact would that have later on...

Didn't try the module, but what happens with the data when the module is uninstalled?

I'm at work right now so can't help you much, but please try CodeMirror editor (in module settings) instead of monaco editor.

Not directly related, just in case if you rename the fieldset: https://github.com/ryancramerdesign/ProcessWire/issues/1854

@flydev: my fix not working for you?

You are right. I forgot true as the second parameter

Can you elaborate how you tested? Maybe I'm doing something wrong, staring at the monitor for the whole day ...

It has do with slashes/backslashes. Wanze is using realpath() function which on windows returns path with backslashes, while WireFileTools->mkdir() assume forward slashes and thus fails to create folder. The solution is simple, something like this in FieldtypeSecureFile.module after line 83: if(DIRECTORY_SEPARATOR != '/') $storageLocation = str_replace(DIRECTORY_SEPARATOR, '/', $storageLocation); or if(DIRECTORY_SEPARATOR != '/') $path = str_replace(DIRECTORY_SEPARATOR, '/', $path); in WireFileTools.php in mkDir() method. I don't know who is "responsible" to deal with that: developer or ProcessWire, so I'm not sure if this is something Ryan should know. Also, mkDir() method does not create directory structure on windows, even if you specify true for the `$recursive` argument.

Hm, I get "destinationPath is empty or does not exist" error, coming from InputfieldFile... I'm baffled how could it work on unix and mac?

Hm, I don't think this is specific to Windows environment since php copy() doesn't create the folder structure. I think pagefile expect that folder is already there. While your mods fix the issue I'm surprised that this isn't spotted by someone before (note: I haven't tried FieldTypeSecureFile).

See the explanation at https://processwire.com/blog/posts/hello-pw3/#new-github-repositories If Ryan would only be the manager, he would be bored, I think. He just loves to code We've had this sort of conversation multiple times. I believe we all would love to help but we just don't exactly know how.

I agree. Those small modules, included in the core modules, would not bring any overhead, on contrary, it would reduce the total number of hooking and autoload modules. I don't know, Ryan is the only one who could provide the answer. There is feature request for this https://github.com/processwire/processwire-requests/issues/136. In this post (Roadmap for 2016) https://processwire.com/blog/posts/happy-new-year-heres-a-roadmap-for-processwire-in-2016/ Ryan said: "One of the goals with 3.x is to make the core smaller rather than larger. Consistent with this, we'll be evaluating all the currently bundled core modules and determining which ones no longer belong in the core." Maybe this is the reason?

https://github.com/processwire/processwire-issues/issues/475

I agree. While I do like new features, I like even more fixing the old issues and making PW stable. Those minor things and issues that are open for days/months/years make me/us creating and maintaining workarounds, like extra css/js files, using "small" modules, putting hooks in ready.php and you never know when and how these mods will affect the next release. When some time ago new repositories for PW was made (issues/requests) I hoped this will make PW issues solving more consistent (with the help of PW members, I think lostkobrakai and isellsoap), but it looks like nothing much has changed. As Ryan said: "The focus often depends on what resources are available in any given week, and what the most immediate needs are for current projects and clients." I understand that but still... I would love that too. Let's stop requesting new features so Ryan could focus on making the stable release.