Nico Knoll
-
Posts
1,835 -
Joined
-
Last visited
-
Days Won
21
Everything posted by Nico Knoll
-
Implement yet another way to access PW's globals
Nico Knoll replied to owzim's topic in Wishlist & Roadmap
I don't know a case where I would need it but I think it won't hurt to implement it either. -
Well I included a cache at first - but then forgot to reimplement it after using ajax. It wouldn't be that hard for my to reimplement it but would be nice to know if this module is going to be alive in the future or will be eaten by Soma's module (because Soma already use caching)
-
I think owzim is more likely planning something regular. So that ... I don't know maybe a PW table every month or something like this. I think berlin is a great place to start something like this. Maybe one day - after the first round tables were successful - we could extend this (or ship it for one time) to Cologne or Frankfurt.
-
No problem I hope this answer can help all of the other people having problems with utf8 and umlauts, too
-
Why do you use utf8_encode? Should be working without it. Or try htmlentities() Edit: Only for you a special service: The code of this: <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <?php setlocale(LC_ALL, "de_DE.UTF-8"); echo 'Using utf8_encode:<br>'; $date = utf8_encode(strftime('%d. %B %Y', 1395929985)); echo $date; echo '<br><br>Without utf8_encode:<br>'; $date = strftime('%d. %B %Y', 1395929985); echo $date; echo '<br><br>Without utf8_encode and with htmlentities():<br>'; $date = htmlentities(strftime('%d. %B %Y', 1395929985)); echo $date; ?> </body> </html> Edit 2: Here is the resulting source code: <html> <head> <meta charset="utf-8"> <title></title> </head> <body> Using utf8_encode:<br>27. März 2014<br><br>Without utf8_encode:<br>27. März 2014<br><br>Without utf8_encode and with htmlentities():<br>27. März 2014 </body> </html>
-
Maybe Soma's module could hook into processdiagnotics. Then my module would become really redundant.
-
I'm in. Already said this on twitter but I think it's better to say it here again to create a better overview
-
Well I think it's right how you did it with $event->arguments(0)->page->parent->name . It's the same solution as used here: https://processwire.com/talk/topic/2518-repeater-fields-via-api-it-has-no-parent-assigned/?p=24062 Maybe we can find a cleaner solution if you tell us a bit more about for what reason you need the parent page of the repeater and so on
-
@soma: I think you're right with not choosing "Process" for all of the submodules. Maybe "Module" would be more appropriated. The module diagnostic shows the current status of the modules (checks if there are new versions available).
-
I saw that the current version is 20 (or 0.2.0) and some updates before it was 4 (0.0.4) and I thought you may have some kind of system or logical pattern how to choose the version
-
Another question: What system do you follow for version numbers?
-
Can updating a module change template files?
Nico Knoll replied to looeee's topic in General Support
Theoretically yes. It's possible to overwrite close to everything. But I guess that the module would check if a given field is already existing and only create a new one if not. Tl;dr: It's possible but rather unlikely. -
Yes, because the part behind the questionmark (in your case "?sort=titleASC") probably disappears if you're clicking a link. So you would have to add it to the pagination link as well. Didn't read the first line
-
Ajax is working. Deactivated "autoload" stuff (don't need it). New pull request is on it's way
-
I'll take a look. There has to be an Ajax function somewhere in PW...
-
(added this to my pull request)
-
I would wrap this translating thing with html_entity_decode(). Should be possible to use normal html after that.
-
I made a pull request. I think my changes are quite good
-
Should I do module update stuff as a separate module or should it be part of the core? At least here is the code: /** * Returns a diagnostic array about installed modules and looks for updates */ protected function getModulesDiagnostics() { $defaultServiceUrl = 'http://modules.processwire.com/export-json/'; $defaultServiceKey = 'pw231'; $modulesRemoteVersions = (array)$this->session->get('ModulesRemoteVersions'); foreach($this->modules as $module) { $moduleInfo = wire('modules')->getModuleInfo($module->className()); $localVersion = $this->formatVersion($moduleInfo['version']); // check if core module $core = false; $pathParts = explode('/', str_replace($this->config->urls->root, '', $this->config->urls->{$module->className()}), 2); if($pathParts[0] == 'wire') { $core = true; } // only show installes /site/ modules if($core == false) { // if remote ersion is in session use this one otherwise load remote version from ... remote. if(!in_array($module->className(), array_keys($modulesRemoteVersions))) { $url = trim($defaultServiceUrl, '/') . "/".$module->className()."/?apikey=" . $defaultServiceKey; $http = new WireHttp(); $data = json_decode($http->get($url)); if($data->status != 'error') { $remoteVersion = $this->formatVersion($data->module_version); $modulesRemoteVersions[$module->className()] = $remoteVersion; } else { $modulesRemoteVersions[$module->className()] = $localVersion; } } $updatable = ($modulesRemoteVersions[$module->className()] > $localVersion); $updateUrl = $this->config->urls->admin.'module/?update='.$module->className(); $results[] = array( 'title' => $moduleInfo['title'].' ('.$module->className().')', 'value' => $updatable ? $this->_('Update available') : $this->_('Up to date'), 'status' => $updatable ? self::$warn : self::$ok, 'action' => $updatable ? sprintf($this->_('There is a new version available. <a href="%s">Click here to go to update page.</a>'), $updateUrl) : '', ); } } $this->session->set('ModulesRemoteVersions', $modulesRemoteVersions); return $results; } protected function formatVersion($version) { return preg_replace('/(\d)(?=\d)/', '$1.', str_pad( (string)$version, 3, '0', STR_PAD_LEFT)); }
-
--- Well maybe it's better if Soma's module would hook into your's. It already includes all the needed functions.
-
I'm not sure if hooking is really the best way. Of course it's well for extended data. But module updates should be always visible - not only if module manager is installed. I take a look and may steal something from soma's code to add this. As Proove-of-concept
-
@netcarver: Just another question: Why do you added "..." everywhere in this module?
-
But as far as I know Soma's Module Manager is not part of the core. And old modules are often a potential security risk so I think it would fit in this Diagnostic page quite well. (I think it's not a huge problem to monitor module status on different places even if there are some overlappings).
-
Mobile version is ready.
-
If it's going to be a core module maybe you could even add a "modules" section and show if there are updates for your installed modules. Maybe even with a link to the update if there is one. Shouldn't be that hard to write because module updates are included in the core since 2.3 or 2.4.
