Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/01/2021 in all areas

  1. This module implements the website live chat service from tawk.to. Actually the module doesn't have to do much. It just need to inserted a few lines of JavaScript just before the closing body tag </body> on each side. However, the module offers additional options to display the widget only on certain pages. Create an account Visit https://www.tawk.to and create an account. It's free! At some point you will reach a page where you can copy the required JavaScript-code. Open the module settings and paste the JavaScript-code into the field as shown below. Click "Submit" and that's all. Open the module settings The settings for this module are located int the menu Modules=>Configure=>LiveChatTawkTo.
    4 points
  2. ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)
    1 point
  3. I've got some core updates in progress but nothing major committed yet, so we'll save that for next week. But I wanted to briefly tell you about a module I'm working on here, which I plan to eventually put in core. I built it for some needs I've had here, but it will first be released in ProDrafts (so ProDrafts may start using its API), and in ProDevTools too, since it is also a developer tool. It's a snapshot versioning system for pages, but more of an API tool at this stage, kind of like the $pages API var, but for snapshots/versions of pages. It lets you create a snapshot of any page, including its fields and files (including core fields, ProFields, 3rd party fields, repeaters, nested repeaters, table fields with a million rows, etc.). The snapshots can be restored at any later time. Snapshots may also be restored to a different page, such as a new or existing page. In this manner, a module like ProDrafts may be able to use it to manage draft versions even better than it currently can, or at least that's the plan. Though since it's an API tool, my hope is that when/if it winds up in the core, others may be able to use it for stuff we've not thought of yet too. The module is a little different than my previous attempts (like what's in ProDrafts now) in that it does most of its work directly at the database level (and file system level, where applicable), which enables it work without needing to know much about the Fieldtype. Currently it is fully functional, but I have a few less common cases to work out before it's ready for release. Once installed, every page includes a Snapshots fieldset, which can be located in the settings tab of the page editor, or a separate tab in the page editor (configurable). When installed, every page has one, so long as the user has the appropriate permissions. There's a screenshot of what it looks like in the page editor below, but it is very simple at this stage, basically just enough for testing purposes. Every snapshot has a name that is unique on the page. You can overwrite a snapshot just by saving a snapshot with the same name on the same page. So you could for instance have a hook that creates a snapshot named "undo" right before a page is saved (in a Pages::saveReady hook), and in that way a module could add a basic undo capability to the page editor. This is just a simple example though. Thanks for reading, have a great weekend!
    1 point
  4. Hey @Pete... do you have an idea when we will have the reputation count back? The more I use the forum now, the more I somehow want it back as fast as possible. It's probably weird but... it was such a great indicator for a lot of things here. And no... it's not about my silly amount of reputation points.
    1 point
  5. Hey @LuisM... just a short feedback on this. I'm really happy you would take your time to guide me and probably anyone else trough this setup and what's possible with it. I already talked to @bernhard in the past several times in regards to his module as I was super interested how all that works. I'm still impressed what he does with that setup. I really really love those kinds of setups, workflows and automations... yet... the initial setup of RockMigration is already way larger and more complex than any of my projects. My projects (look at muskaat.de) are most of the time super simple and straight forward. They do what they need to do... sometimes more complex, sometimes only a few more files, and most of the time only a DEV and LIVE stage. Nothing I'd need such a setup for. Even though I really am a Spielkind (someone that loves to play around with all possible options). Still... I know and understand the benefits of those setups with RockMigrations - and your addition to it - and what they could and can do. As I'm most of the time the one and only developer for now... Git is perfectly fine for any workflow I can imagine. I'm missing two or three developers on my side and maybe a few more stages, like dev / qa / testing / preprod / live, within my projects to really benefit from your and @bernhard's modules. Yet... I really appreciate all the things you both and several others here build to make ProcessWire even more awesome for whoever.
    1 point
  6. @jacmaes Wicked, glad it sorted it for you too. I'll file it now
    1 point
  7. @horst This is a Pageimage object. $photo->mediaField; This is a Pageimages object. https://mediamanager.kongondo.com/documentation/frontend-output-of-media-manager-fields/media-manager-objects/
    1 point
  8. Hi @Goca and welcome to PW ? My learnings from 2018: Don't use Repeaters for such a use case!! ? Agreed. Pages are great! They are the most important part of PW, they are robust, versatile, scale well and everything will work with pages while not everything will work with repeaters or repeater matrix. Take RockMigrations or RockFinder or findRaw as examples... To be honest I don't know. But what I usually do is leave the title field there and use it for whatever I need (and I always need anything). That could be a unique ID of that page that could be used as some simple password protection or you could use it to concatenate data from two other fields or to create a better readable label that is simply shown in the page tree. You can simply set the field to locked or hidden and populate it via saveReady hook. Maybe 10 lines of code. No mess. No danger. And ideally some other benefits. If you are building your own dashboards and lists I'd even consider structuring your page tree more like traditional database systems: - schools - modules - quizes - students I can't prove that by good arguments now and I know too little about your exact system but for me putting too much business logic into the page tree did more harm than good. Hope that helps a little ? You are already asking good questions ?
    1 point
  9. SORTED: So I changed item's to be the first query which featured then works off and now the pagination renders and works.
    1 point
  10. I thought about building that out from the start but wanted to focus on getting the core of the module working first in a way that matched the way ProcessWire's multi-language setup works where there is a primary language and secondary languages. Including the general translation tool in the top menubar where any text can be translated from/to any language was a short term solution for that limitation. Once Fluency is able to mature and all of the bugs fleshed out then revisiting that would be an option.
    1 point
  11. @horst when you said you would write a tutorial I did not expect a short reference manual! Thank you heaps. @wbmnfktr, yes, I eventually found my way here - life delayed my return. This looks awesome and I'm looking forward to using it. At the moment it reveals that I am a better photographer than coder... I have encountered an error at the beginning of step 4. I have tried to tweak the code to reflect my fields and setup, but keep getting an error. I'm testing on my NAS and my setup uses MediaManager and has photo as the photo/image field. Thus I have the following: The following error is thrown: In my current template, using MediaManager, the following produces the expected output: What am I'm missing or doing wrong?
    1 point
  12. @FireWire Do you think you can bring an update to module to translate from secondary language to main language? Eg: Site Main lang is DE and sec lang is EN , but the article writer writes the text in english and the client would be able to translate from EN to DE (main language)
    1 point
  13. #wrap_Inputfield_enabledSubmodules .InputfieldCheckboxesStacked input:checked+span:before
    1 point
  14. @alexm Thanks for sorting this out. I've just run into the exact same thing, with "marzo" (March in Spanish) as this is my locale. Could you please file a Github issue?
    1 point
  15. I see… so maybe $pages->getRaw() is the right thing for you? $protein_url = $pages->getRaw("template=protein, title='$search_input'", "url"); https://processwire.com/api/ref/pages/get-raw/
    1 point
  16. I have a different opinion from @cryostar here. If you need this content to be easily searched, I would say it's better to keep the pages. As for the title, that link is a good read and there are other possible approaches, particularly with the use of hooks (don't have time to go through them now), but consider renaming the title field to "identifier" in those templates and leave it at that. This will greatly simplify your coding and will give editors a chance to add words that are not in the question but might be useful for searching later, it will also keep things tighter and more readable in the pages tree.
    1 point
  17. Ok got it. There needs to be a 5th parameter passed of 1 so that the day selected is the first of the month otherwise it's getting a day that doesn't exist and skips over onto the next month. strftime($monthFormat, mktime(0, 0, 0, $n, 1))
    1 point
  18. Thanks @BillH! Using hooks is actually on top of my head though I was just wondering if there are other straightforward solutions that don't require code. If anyone has a requirement like I do that should make certain fields read-only when they are populated, here's how I did it (saved under ready.php): $wire->addHookBefore('Page::loaded', function(HookEvent $event){ $_page = $event->object; if($this->page->process !== 'ProcessPageEdit') return; //Run only if you're on the admin page editor if('specifictemplate' != $_page->template) return; //If only you want to lock it for certain fields if(!$_page->thatfield) return; //This is a Page Reference that returns false if there is no value $thatfield = $_page->getField('thatfield'); $thatfield->collapsed = Inputfield::collapsedNoLocked; });
    1 point
  19. Done — https://processwire.com/talk/topic/25815-custom-notes/. Moved the two posts introducing Custom Notes and placed them in the Modules forum section instead of module development (it's a proper module after all), hope that's fine ?
    1 point
  20. I'm posting this as an update to an earlier post created by @Hari KT: https://processwire.com/talk/topic/4958-composer-support-for-processwire/. Though that approach still (kind of) works (as does the one detailed in https://github.com/wireframe-framework/processwire-composer-installer), thanks to @d'Hinnisdaël there's now a better alternative: the official composer/installers project ? An example repository implementing the things detailed in this post: GitHub repository: https://github.com/teppokoivula/HelloWorld Packagist entry: https://packagist.org/packages/teppokoivula/hello-world As a module author, how do I make my module installable via Composer? 1) Add a composer.json file to your module's directory. Here's an example: { "name": "vendor-name/module-name", "type": "processwire-module", "license": "MIT", "extra": { "installer-name": "ModuleName" }, "require": { "composer/installers": "~1.0" } } The composer.json file explained: "name" consists of two parts: your vendor (author) name, and the name of the package (module). These can (but don't have to) be the same as your GitHub or BitBucket user and repository names. Please note that this value should be all lowercase! That's the syntax expected by both Packagist and Composer. "type" should be "processwire-module". You may have seen "pw-module" used by other packages; that's the value used by third party installers, you don't need to worry about that now. "license" should specify the license your module is published under. See Composer help for expected syntax. It's technically fine to leave this out, but it's always a good idea to let users know how they're allowed to use your code. "installer-name" under "extra" should specify the expected directory name for your module. Usually this is the same as your module's name. If you leave this out, the package part of the "name" value will be used instead (which may be just fine, though I'd recommend always filling in this value). "require" includes Composer dependencies of your module. The key part here is "composer/installers" — without this Composer won't know that your module requires said installer, and it may not be installable at all, so be sure to add this row. 2) Submit your project to Packagist: https://packagist.org/packages/submit. You will need an account for this step. It's free and very easy to register, and you can automatically connect it with your GitHub account. Connecting with GitHub also makes it easier to auto-update package versions from GitHub repository. 3) Recommended but not absolutely necessary: add tags to your module's Git repository. It's recommended that when you push a new version of your module to GitHub or BitBucket, you also add a matching tag: if you push version 0.0.3 (or version "3", following the old school ProcessWire version number format), you should also add tag 0.0.3 (or "v0.0.3" if you want to be verbose) to GitHub/BitBucket. (This step is not strictly speaking necessary, but it does make things easier for users installing your module, and makes much easier to track which version of the module is currently installed via Composer. It requires additional step when publishing a new version of the module, but please consider doing it anyway!) 4) Also recommended but not absolutely necessary: configure Packagist to auto-update based on GitHub/BitBucket. Follow the instructions here: https://packagist.org/about#how-to-update-packages. This step ensures that once you push a new version of your module, Packagist automatically updates stored information without you logging in and hitting the "update" button manually. (This step may not be necessary if you've already allowed Packagist access to your GitHub account.) ... and that's it. Congratulations, your module is now installable via Composer! As a module user, how do install a module via Composer? Go to your site's root directory and type on the command-line "composer install vendor-name/module-name". You can look up the correct details from Packagist, or the module author may have included them in the support forum thread. Obviously this only works for those modules that have implemented Composer installer support as outlined in this tutorial. Note: if you're using a "non-standard" directory structure for ProcessWire — you've moved the root of the project outside the public web root, or something along those lines — check out the custom install paths part of the composer/installers README. The "installer-paths" setting allows you to manually specify a custom install path for the "processwire-module" package type.
    1 point
  21. @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
    1 point
  22. $pages->getPageFinder()->find(new Selectors($selector), array('returnQuery' => true))->getQuery(); I seem to recall teppo posting a less verbose version of this, but I cannot find it currently.
    1 point
  23. OK, the solution "I've" come up with (err, Soma and Ryan came up with ) is a hybrid of some of Soma's code and Ryan's: if($page->id == 1232 && $id = (int) $input->urlSegment1) { // 1232 is a page with the URL /p/ $redirect = $pages->get("id=$id"); if($redirect->id && $redirect->viewable()) { $session->redirect($redirect->url); } else { //throw new Wire404Exception(); $session->redirect($pages->get($config->http404PageID)->url); } } This is now complete and solves the short-links referred to in the opening post of this thread. I might see if I can make this into a Module. I don't know if it is a good candidate for being a Module and I don't know if I will be able to work out how to do it and I don't know when I'll get to try (just a few don't know's then ) but maybe I'll do it! Meantime, thanks again to everyone who commented, cheers, -Alan
    1 point
  24. Ah so you're trying to have an id permalink to pages (shortcut). I'm not sure if this woud help but this is how I would solve it. Normally you would setup your tree to have pages that will be in the navigation, and set pages not in navigation to hidden. From there it would just be a simple check to see if the page (id) requested is not hidden. 
 if(!$pages->get($id)->isHidden()) $session->redirect($pages->get($id)->url); else $session->redirect($pages->get($config->http404PageID)->url); Or you could add a field (checkbox) "not_permalink", and give that to templates you need. You could use it for single pages, or just the parent of a branch. So all children pages will either be shown or not. 
 if(!$pages->get($id)->parents->has("not_permalink=1") || $pages->get($id)->not_permalink == 0) $session->redirect($pages->get($id)->url); else $session->redirect($pages->get($config->http404PageID)->url); It depend a lot how you setup you page tree and how you make them appear in your navigation, but I'm sure you'll find a very simple solution. I think it can be as simple as a 2 line code and no module would be required.
    1 point
×
×
  • Create New...