dotnetic

Hey @adrian. The first problem was with CORS as I tried to query the modules-export directly, as you did in your example. I am using something similar to $http->getJSON(). The disadvantage is that it is inserted into the HTML and not loaded dynamically which is harder to debug. AJAX requests can be shown in the console. As with everything each method has it advantages and disadvantages and is a matter of choice. Now I dropped the AJAX approach and list the modules JSON right in the HTML/JavaScript.

I am slowly progressing, because I struggled with loading the JSON via AJAX in conjunction with vue.js (which I sadly did not managed yet). And had to get used to vue.js a little bit more. There is a lot of old markup that needs to be refactored, but the module is already working. I optimized and prioritized which information should be shown, and what is additional information, which will be shown with a specific action like clicking a link or hovering over the card. Don't know it excactly yet. Here you can see which module is installed or not installed and have options to install it. Support for quick uninstalling/deactivating modules is coming soon. And in this screenshot you see how it looks if a module can be updated. The layout is still work in progress and not finished yet. Still deciding on icons, colors, etc.

@kongondo Performance is important, even if you visit the modules section not very often. In my case I often need to install or uninstall modules during development of my sites. This might not apply to all sites or the average site, but hey, if we can be fast, why shouldn't we?

@Pete It would also be nice to have a URL that just returns a timestamp/date when the static/cached module JSON file was last updated. If we have that, we could check if we have to download the module JSON again, or can use the locally cached version. And it should be separate from the module JSON, because the download would be much smaller.

What exactly is the output? Do you get error messages?

Hey @bernhard I try to show only pages that are published. But right now my query shows all entries. I tried to use a filter, but it doesn't work. How can I get only published pages? <?php $stellen = new RockFinder("template=stelle", ['title', 'stellekosten', 'kostenproclick', 'mitarbeiterid', 'created', 'bookmark','status']); $stellen->filter(function ($row) { $page = $this->wire->pages->get($row->id); return $page->isUnpublished(); }); return $stellen->getSQL();

@neophron Please open another thread for this, because it has almost nothing to do with the german language pack and is more a general PHP question. However I will try to give you advice in the right direction. For locales to work, they have to be existent on the system. You can get a list of all installed locales on Linux if you run `locales -a` in a shell. The name of a locale depends on the OS and which derivate you are using. So for german for example the locales name could be one of the following: $loc_de = setlocale(LC_ALL, 'de_DE@euro', 'de_DE', 'deu_deu'); or it might even be `de_DE.UTF8`or something else. @bernhard: strftime is dependent on the locale, so it won't work if the correct locale isn't set. Here is a little script I wrote that shows you the preferred locale on your system. However, there might be locales missing like in my german example. So please run `locale -a ` in a shell to see whats the correct locale name. <?php echo '<h1>test for locales</h1>'; /* try different possible locale names for english GB as of PHP 4.3.0 */ echo '<p>'; $loc_en = setlocale(LC_ALL, 'english_gbr', 'english_britain', 'english_england', 'english_great britain', 'english_uk', 'english_united kingdom', 'english_united-kingdom'); echo "Preferred locale for english GB on this system is '$loc_en'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); echo '<p>'; $loc_fr = setlocale(LC_ALL, "fr_FR", "fra", "fr_FR.UTF8", "French_France"); echo "Preferred locale for France on this system is '$loc_fr'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); /* try different possible locale names for english USA as of PHP 4.3.0 */ echo '<p>'; $loc_enusa = setlocale(LC_ALL, 'english_usa', 'english_america', 'english_united states', 'english_united-states', 'english_us'); echo "Preferred locale for english USA on this system is '$loc_enusa'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); /* try different possible locale names for german as of PHP 4.3.0 */ echo '<p>'; $loc_de = setlocale(LC_ALL, 'de_DE@euro', 'de_DE', 'deu_deu'); echo "Preferred locale for german on this system is '$loc_de'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); /* try different possible locale names for spanish as of PHP 4.3.0 */ echo '<p>'; $loc_es = setlocale(LC_ALL, 'esp_esp', 'esp_spain', 'spanish_esp', 'spanish_spain'); echo "Preferred locale for spanish on this system is '$loc_es'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); /* try different possible locale names for dutch as of PHP 4.3.0 */ echo '<p>'; $loc_nl = setlocale(LC_ALL, 'nld_nld'); echo "Preferred locale for dutch on this system is '$loc_nl'"; echo '<br/>' . strftime("%A %d %B %Y", mktime(0, 0, 0, 12, 22, 1978)); function smarty_modifier_number_format( $string, $decimals = 2 ) { $locale = localeconv(); // setlocale( LC_NUMERIC, null ); $string = str_replace(',', '.', $string); $thousand_separator = ( $locale['thousands_sep'] == '' ) ? '.' : $locale['thousands_sep']; $decimal_separator = $locale['decimal_point']; return @utf8_encode(number_format( $string, $decimals, $decimal_separator, $thousand_separator )); } echo "<br>"; echo smarty_modifier_number_format('12,90 g'); After finding the correct locale you have to write it into the "C" setting in ProcessWire like described here https://processwire.com/talk/topic/15691-warning-about-server-locale-after-update-from-3052-3053-help/?do=findComment&amp;comment=155654

Hey Bernhard, that is how the data is output, however a little modification is needed, as there is some metadata. But if you use the items array, you have exactly what you want. Take a look at the data on http://modules.processwire.com/export-json/?apikey=pw223&amp;limit=500 and throw the result into a json formatter like https://jsonformatter.curiousconcept.com/

Yeah, same data that it is now.

Hey @adrian I have read that comment, and think this should be done. Waiting for feedback from @Pete and or @ryan if they can implement it soon.

@neophron Date formatting can be set directly in the fields settings. It has nothing to do with the german language pack.

Right now I am working on filtering, but customers are nagging me about getting their sites done, so this module needs a little bit more time. Hope to find some time in the next days.

@neophron You might also have a look at my blog article "Warum ProcessWire die beste Wahl für Ihre Website ist (nicht immer, aber in den meisten Fällen)" or a case study of the website of P. Jentschura, which is also based on ProcessWire.

The reason why I would need data all modules is, that I want to filter and search the entries on the frontend side, instead of making a new AJAX request, because it is much faster. There are advantages and disadvantages with frontend only filtering, but with backend filtering also. I think frontend filtering is the best way for quick searching and filtering. That is also how I do it on https://www.p-jentschura.com/de/produkte/

@bernhard An extra field for a Readme would be an ideal solution, but then every author has to update his modules information in the modules directory. So there might be many modules without a readme, because they are not maintained anymore. The module overcomes this, and tries to get the needed information automatically. So maybe code from this module can be reused for my module. Have to look into this.

Thanks for the kudos, Bernhard ?

Is @Nvim any good?

@Robin S Good idea. Would be an enhancement.

Yes, it would ideal to serve a JSON file with info for all modules. But thats a lot of information, so it would be good for the module installer to define, which fields should be queried, so the JSON file is minimal. As I partied until now, I think I am not going to work on the module today. Have to get a lil bit of sleep tonight, ehm, day, because I didn't sleep last night. I am hoping for an answer from @ryan about the limit for the JSON file.

Hey @GynTonyc. Welcome to our community and to ProcessWire. There is a reason why we have chosen PW as our framework/CMS of choice. You already know why. If you have more questions don't be afraid to ask.

Multiple sites are possible with Laragon, but if you use the same database in your site/config.php, well you have the same data in both installations.

normally the backend login url is /processwire and not processwire/login /. Did you tell your browser to accept the certificate anyways? Then it should work. Else do you have access to the files via FTP? Then you can insert following code into a template file to echo the admin url: echo wire('config')->urls->admin;

check your .htacces file. Is mod_rewrite enabled? are other urls working fine?

@adrian I am developing it as a module for now, but at a later point will replace ProcessModule with my code. For getting the JSON data I used code from Somas Module Manager, which seems to get only the 350 items you mentioned ? We have to think of a way, to get them in batches, or @ryan has to change the limit. I did not thought about the complications yet when the limit is higher. I got filtering working, but not in the way I want. Some things turn out to be more complicated than I thought. Anyways, here's a lil teaser for you guys ?

There is an option to hide certain categories from listing, this could also be made configurable via module settings, but this is not my priority right now.