Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/02/2021 in all areas

  1. TextformatterEmoji converts named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. For instance :smile: converts to: ? This can be especially useful if your ProcessWire uses the utf8 character set rather than utf8mb4 as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Note that how the emoji appears (and sometimes whether it appears) can vary from platform to platform, and from browser to browser. Here is an alphabetical list of supported emojis and the shortcodes you can use to show them in your text. If you want to add any emojis that are not already present you can do so in the emojis.json file.
    1 point
  2. To be honest, I don't know if this is a standard processwire file. But with language files one can use it as follows: Instead of adding each string to an own variable, you can add a second parameter to all the language strings you use around in different template files or module files or where ever you need them: __('Text 1', '/path/to/your/_strings.php'); __('Text 2', '/path/to/your/_strings.php'); ... And instead of adding the '/path/to/your/_strings.php' as text all the time, I use a functions call for that. This way you do not have to include the file and can use it everywhere handled through the PW translations system, because you tell it that the current string is the same as a string in the centralized _strings.php In /site/init.php I define this function, that simply returns the path to my centralized translation file: /** * TRANSLATABLE STRINGS * Include translatable strings */ if(!function_exists('ProcessWire\mystrings')) { function mystrings() { return '/site/_strings.php'; // absolute URL or absolute filepath to the central translation file } } My _strings.php would look like this: <?php namespace ProcessWire; /** * TRANSLATABLE STRINGS * Define globally available translatable strings * * USAGE * * __('Lesen Sie mehr ...', mystrings()); * * The function mystrings() returns the textdomain of this file. * **/ ... __('Datenschutzerklärung'); __('Die Maße des Werks sind:'); __('Dieses Bild drucken!'); __('drucken'); ... __('Text 1'); __('Text 2'); ... __('Zurück zur Übersicht'); To sum up, this way I don't need to include a _strings.php and it also works every where.
    1 point
  3. Hi @adrian, I've debugged this further and the issue has nothing to do with Tracy (was just caught in the middle!), sorry. The issue persists even with Tracy disabled. It is a jQuery issue. No idea how I'll get around this. I have to load Alpine.js inline since (AFAIK) $config->scripts() does not support 'defer' which Alpine needs. Thanks.
    1 point
  4. _strings.php contains variables which are translations from one language to another (e.g. $var1 = __('Text 1')). I thought it is a standard ProcessWire file.
    1 point
  5. What does it contain, whats in the _strings.php? What does it provide? (functions, vars, ...?) Maybe another method than include_once() could be more straight forward and also works with wire-render-pattern.
    1 point
  6. Just fyi this breaks a bit if you put a description for the fieldset and also tick the box. Maybe just in the latest version of PW
    1 point
  7. @Stefanowitsch as you can see, @kongondo is working towards a summer baby. Last day of summer is the 22nd September so keep your fingers crossed. No news is good news they say.
    1 point
  8. For the benefit of anyone else wanting their module to be comptible with earlier versions of PW, I suggest you use: $tab1 = $this->wire(new InputfieldWrapper()); not $tab1 = $modules->get('InputfieldWrapper'); Also, do not use plain $tab1 = new InputfieldWrapper(); as the column widths of the contained inputfields will not work properly. Per the PW coding style guide:
    1 point
  9. I'm looking forward to using your module Bernhard. I have written an application in ProcessWire over the past year, and 3 months into development I started kicking myself for not starting from a multi-site perspective. Now with this I can see a solid workflow for migrations whilst benefiting from keeping users locked in their own instances. Having now read the docs I'm keen to try it out with a single new feature that will require several templates, fields and pages!
    1 point
  10. Had the same issue but indeed the solution works! Thanks for this!
    1 point
  11. Hi everyone. It's been a while. A little update. There has been a delay, again, unfortunately! Lockdown hit really hard. There were also a number of technical issues but these have since been resolved. Finally, a number of you (having seen the preview videos) strongly expressed the need for the Padloper UI to resemble the ProcessWire admin theme even in the alpha stage. The message I got was that this was more important to them from the get-go than having advanced Padloper features. I accepted their reasoning but this came at a cost. Padloper 2 has been re-themed to look like the ProcessWire admin. Given that we are using third-party libraries to build Padloper 2, this took a lot of time. Focus was placed on basic features only, for now, in order to expedite the first release of Padloper 2. This means that some advanced features will be missing from the first release of Padloper 2. As for a release date, I was hoping for a 'spring baby'. That won't happen. I am now working hard toward a 'summer baby'. Screenshots Have a nice and safe day.
    1 point
  12. I don't think you can prevent the output of those fields - but there is a trick you can pull to prevent them being editable (as well as hiding them using a CSS rule on the wrap classes.) If you override the preset values - but to the same strings as the preset would use anyway - then the form renders them with the disabled attribute. Like this.. <?php echo $page->comments->renderForm([ 'presets' => [ 'cite' => $user->name, 'email' => $user->email, ], ]); I haven't verified, but I believe that the comments fieldtype will replace any tampered fields in the posted form with the original preset, so this might work for you.
    1 point
  13. I am saying you can use the shop itself to manage your featured products. Conversely, you also have the flexibility of pulling anything you want from Padloper into your ProcessWire pages (for GUI edit). In such cases though, you will have to develop the Fieldtype/Inputfield yourself. Padloper will provide the API necessary for the pulling of the data. In a nutshell, I meant, you choose what is convenient for your use case :-).
    1 point
×
×
  • Create New...