Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/12/2019 in all areas

  1. Hi Louis, 1- In the form, change the name of the input : <!-- from --> <input type="file" id="preview-name" name="preview-name"> <!-- to --> <input type="file" id="preview_name" name="preview_name"> 2- In your JS code, use FormData() and add the contentType prop to the $.ajax call (that's the key here) : $('#submit-preview').click(function(e) { e.preventDefault(); title = $("#preview").val(); image = $('input[name=preview_name]').prop('files')[0]; // modified form_data = new FormData(); // added form_data.append('preview_name', image); // added form_data.append('title', title); // added console.log(title); console.log(image); $.ajax({ type: 'POST', data: form_data, url: '/development/upload-preview/', contentType : false, // added processData : false, // added success: function(data) { console.log("Woo"); }, error: function(xhr, ajaxOptions, thrownError) { alert(xhr.responseText); } }); }); 3- The ajax template file look good. The main reason that WireUpload doesn't work here, is because it couldn't find the right field name (form input name) : $u = new WireUpload('preview_image');
    4 points
  2. Repeater Images Adds options to modify Repeater fields to make them convenient for "page-per-image" usage. Using a page-per-image approach allows for additional fields to be associated with each image, to record things such as photographer, date, license, links, etc. When Repeater Images is enabled for a Repeater field the module changes the appearance of the Repeater inputfield to be similar (but not identical) to an Images field. The collapsed view shows a thumbnail for each Repeater item, and items can be expanded for field editing. Screencast Installation Install the Repeater Images module. Setup Create an image field to use in the Repeater field. Recommended settings for the image field are "Maximum files allowed" set to 1 and "Formatted value" set to "Single item (null if empty)". Create a Repeater field. Add the image field to the Repeater. If you want additional fields in the Repeater create and add these also. Repeater Images configuration Tick the "Activate Repeater Images for this Repeater field" checkbox. In the "Image field within Repeater" dropdown select the single image field. You must save the Repeater field settings to see any newly added Image fields in the dropdown. Adjust the image thumbnail height if you want (unlike the core Images field there is no slider to change thumbnail height within Page Edit). Note: the depth option for Repeater fields is not compatible with the Repeater Images module. Image uploads feature There is a checkbox to activate image uploads. This feature allows users to quickly and easily add images to the Repeater Images field by uploading them to an adjacent "upload" field. To use this feature you must add the image field selected in the Repeater Images config to the template of the page containing the Repeater Images field - immediately above or below the Repeater Images field would be a good position. It's recommended to set the label for this field in template context to "Upload images" or similar, and set the visibility of the field to "Closed" so that it takes up less room when it's not being used. Note that when you drag images to a closed Images field it will automatically open. You don't need to worry about the "Maximum files allowed" setting because the Repeater Images module overrides this for the upload field. New Repeater items will be created from the images uploaded to the upload field when the page is saved. The user can add descriptions and tags to the images while they are still in the upload field and these will be retained in the Repeater items. Images are automatically deleted from the upload field when the page is saved. Tips The "Use accordion mode?" option in the Repeater field settings is useful for keeping the inputfield compact, with only one image item open for editing at a time. The "Repeater item labels" setting determines what is shown in the thumbnail overlay on hover. Example for an image field named "image": {image.basename} ({image.width}x{image.height}) https://github.com/Toutouwai/RepeaterImages https://modules.processwire.com/modules/repeater-images/
    3 points
  3. I understand thats it's crucial to save bandwith. That's why we have webP now, finally. But there is one line in PagefileExtra.php that delivers the normal image url instead of the webp version, if the webp filesize is larger. In my case and I think on other sites too this is an unwanted behaviour, as quality and colors are different if you compare a jpg and a webp image. To illustrate this I attached this image, where you can see that the first three products which are being delivered as JPGs because the filesize is smaller are really different looking than the next 3 which are in webp format , especially in the logo area. This is somewhat hard to see here, but on my development site it looks really bad and is a showstopper for me to use webp. What I ask for is an option to skip the filesize check and maybe the option to enter a treshold value when to use the smaller image. I created a github issue "make the fallback optional if pagefile->url is smaller than webp" EDIT: This is already possible if you use following code: //_init.php // output webp version for all $image->url() calls, skip SVG's if($page->template != 'admin') { $wire->addHookAfter('Pageimage::url', function($event) { static $n = 0; if(++$n === 1) { if (strstr($event->object->filename, '.svg') === false){ $event->return = $event->object->webp()->url(false); } } $n--; }); }
    3 points
  4. Only thing I want to mention is that you do expose some date from the PW backend to the public that you might not want to expose, eg ProcessWire.config.urls.admin: It's not critical, but it's also not necessary, so you might be better off using your own implementation of that principle: https://processwire.com/talk/topic/14077-config-js-only-working-when-logged-in/?do=findComment&comment=126552 I think that is easier than unsetting/masking the admin url property in the js object (because that would have to be done on the server side).
    2 points
  5. Thank you so much for the help you gave! Bernhard helped me through Skype and TeamViewer and solved the issue. I have and had some issues with MAMP. He also gave me some pointers of how to use RockGrid and best practises etc. Worth every €!!! I recommend to use RockGrid if you need to list and edit data. I also recommend to contact Bernhard and buy some support if you want to quickly learn how to use RockGrid! ?
    2 points
  6. Tip: How to "rename" an image field when the name you want to rename it to already exists I ran into a situation when I had two single-file image fields. Let's call them A and B. I didn't like the field name of 'A' and I wanted to give it a new name of 'B', but that field name was already being used in OTHER templates and had content populated. Therefore we need a clever way to rename A into B. With non-image fields this isn't a problem, but with an image field, there's files involved, so it gets a little more complicated. Admin Actions can handle this using the "Copy Content to Other Field" action. Set Source to 'A' and Destination to 'B'. The way it seems to be programmed is that it won't actually make a copy of the file (which is good because I don't want to duplicate the image), but instead it seems to copy the name of the file to the destination image field. Once the action has been run, if you view the a page using the template you applied to the action to, you will see that the image exists in both fields. DO NOT TOUCH THEM because whether you delete from A or B, it will delete in both fields. So now to complete this renaming, edit your template file and remove field "A". It will remove the field, but it will NOT remove the image, which is good. The end result is you now have image field 'B' with the contents from 'A', without having had to duplicate the image (meaning any references to that image will still be intact and not 404) and without ProcessWire having deleted the image when you removed "A" from your template. ?
    2 points
  7. thank you guys, especially @Soma, helped me a lot! i totally forgot i had to inject the variable on my own in frontend. when i was logged in it was present because i use frontendediting and there it gets injected automatically. totally makes sense i took a slightly different approach with my own js variable: // template <?php echo $modules->get('PwFullCalendar')->render(array( 'editable' => $page->editable(), )); ?> // module public function render($options = array()) { // get settings $settings = array_merge($this->settings, $options); extract($settings); // push settings to javascript $out = '<script>var fullcalsettings = ' . json_encode($settings) . ';</script>';
    2 points
  8. This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder— https://processwire.com/blog/posts/webp-images-and-more/
    1 point
  9. I don't think this is good design. You can do it, but there are better ways. Do your different scenes have different scripts or just different variables but using the same script? If the latter, what you can do is store the unique properties of the scenes in the text field. A common approach is to use JSON with key:value pairs. You would then pass those to your script. There are two approaches to pass the data to your script; using $config->js() or echo'ing the JS variable in your template file. Please see these threads for more details: If you scenes have completely different scripts, you can either handle that in your JS code, if this scene then this, if that scene then that. Alternatively, you can have one template for all scenes that includes different other files based on the scene.
    1 point
  10. You can use sort() on WireArray derived objects : $search_options = $templates->get("catalog_item")->fields->sort("label"); // or sort("-label")
    1 point
  11. you could try something like: $search_options = $templates->get("project")->fields; $fieldNames = array(); foreach($search_options as $so) { $fieldNames[] = $so->name; } sort($fieldNames); afaik, $search_options is an object, not an array.
    1 point
  12. You have officially saved my sanity flydev! Thank you so much. I had stared at/fiddled with this all day yesterday to no avail.
    1 point
  13. Just want to add for anyone reading this post, that while in the admin this cannot be done, it is doable via code. By putting something like this into init.php,: $templates->get('home')->filename = $config->paths->templates . 'views/home/home.php'; it is possible to store a template file wherever you want. Read more about this in this topic: https://processwire.com/talk/topic/2676-configuring-template-path/
    1 point
  14. Welcome to the forum ? Maybe this solves your problem. If there are multiple paginations or API calls, you must also set the "start=0" selector so that other page arrays are not paginated. See under "Are there any side effects?".
    1 point
  15. I don't have a multi-language installation to test on but it should be possible. You'll have to work out the best way to use conditionals to construct your selector but the default language selector would look like... $result = $pages->find("repeater_element.body%=foo"); ...and the non-default language selector would look like... $result = $pages->find("repeater_element=[body.data{$user->language}%=foo]");
    1 point
  16. Maybe OT: I have been thinking of using Dart or TypeScript to write my JS for me ?. Vanilla JS can be a pain at times. Using Dart or TypeScript, I can write in familiar OOP style (yes, I know about ES6, but that's another story) and have them transpile the code into JS. For small projects it's probably not worth the hassle, but the strongly typed nature of Dart or TypeScript alone is compelling reason enough to steer away from vanilla JS if I can. OK, I'll now crawl back under my rock...?
    1 point
  17. ANOTHER UPDATE SnipWires Taxes (VAT) configurator is ready! I added a new custom Fieldtype FieldtypeSnipWireTaxSelector based on an idea of @BitPoet - thanks for that! Also I created a full featured repeater for module config editor including drag&drop handling. Have a look at the animated GIF below. The taxes you configure here will be available as select option list in product page editor. The first tax in the configured list will be used a s the default tax in the custom field.
    1 point
  18. Hello There Fellow PW lovers. I wanted to share this code that i created to post tweets to the Twitter API in an upcomming project i am working on. And i Thought that everyone could have some use for it. I am using Composer to load the TwitterOAuth PHP library for working with the Twitter API in this code example. Also you need to create an App and have your own API keys ready, you can do that here: https://developer.twitter.com/en/apps The code posts a string and uploads media to be used with the tweet. For the TwitterOAuth methods information see the link above. Note: The paths to the media needs to be local for TwitterOAuth to pick them up and upload them. See this link for filesize limits and other info on media attachements. https://developer.twitter.com/en/docs/media/upload-media/overview <?PHP /* TwitterOAuth API via Composer https://twitteroauth.com/ */ include('vendor/autoload.php'); /* define the classes */ use Abraham\TwitterOAuth\TwitterOAuth; function postTweetUpdate($str = '', $mediaArray = null) { /* Twitter OAuth keys Create your App and find your API keys here: https://developer.twitter.com/en/apps */ $consumer_key = ''; $consumer_secret = ''; $access_token = ''; $access_token_secret = ''; /* init API */ $connection = new TwitterOAuth($consumer_key, $consumer_secret, $access_token, $access_token_secret); if(is_array($mediaArray)) { $mediaIDS = array(); /* Up to 4 media objects can be uploaded. https://developer.twitter.com/en/docs/media/upload-media/overview */ foreach($mediaArray AS $key => $media_path) { /* Upload media to twitter API and get media ID back */ $mediaOBJ = $connection->upload('media/upload', ['media' => $media_path]); /* push uploaded media ID to array */ array_push($mediaIDS, $mediaOBJ->media_id_string); } /* create comma delimited list of media ID:s */ $mediaIDstr = implode(',', $mediaIDS); } /* API params */ $arrayCfg['status'] = $str; $arrayCfg['media_ids'] = $mediaIDstr; /* Make POST request to Twitter API https://developer.twitter.com/en/docs/tweets/post-and-engage/api-reference/post-statuses-update */ $statuses = $connection->post("statuses/update", $arrayCfg); /* return payload */ return $statuses; } ?> <?PHP /* string to Post */ $str = 'Test Tweet... ' . PHP_EOL; $str .= '#mytweet' . PHP_EOL; $str .= 'http://www.mywebsite.com' . PHP_EOL; $str .= '' . hash('sha1', mt_rand(0, 1000000)); /* media to upload */ $mediaToUpload[] = 'images/my_image.jpg'; /* make request to Twitter API */ $payLoad = postTweetUpdate($str, $mediaToUpload); ?> <h3>Debug</h3> <pre><?PHP print_r($payLoad); ?></pre> I have the Debug part because its handy to see what is returned from the Twitter API.
    1 point
  19. ProCache, ProFields (Matrix), ProLister
    1 point
  20. ProFields (especially Matrix Field) and ProCache.
    1 point
  21. First of all... ProCache. It compiles my SCSS and JS files to small and handy assets. It combines multiple CSS/JS files if necessary. Awesome if you use Premium Templates and don't want to mess around with all of its assets. And it minifies HTML, creates static copies of all your pages and therefore produces all in all really fast sites even on cheaper hosting solutions. BUT... you have to be careful if you handle custom-made forms or any real-data-interaction. ProCache bypasses almost every PHP request so handling user input and things like won't work on ProCache-enabled pages. Second... FormBuilder. It handles 90% of all my necessary use cases of contact forms or any other kind of form my clients or I need. It works pretty well with ProCache - but you have to use the iFrame option then but that's another story. In summary: this form-builder tool can make things quite easy but customizations are sometimes a good amount of work. Replacing one of the includes frameworks, like Bootstrap and UIKIT, can be replaced and you can even use vanilla CSS for it but you have to invest some time here as well. Third... RepeaterMatrix (ProFields). You can create almost every modern (aka lapa.ninja featured) design with it and create your very own page builder tool-kit with it BUT... you have to dig deep into how everything works. It's a tool to built bigger tools. I use it for a very long time now and I guess I used only about 20% of its full potential. Last but not least... every other module from the ProFields collection. There is so much in it and you really should take a closer look at the provided screencasts to imagine what they can do. So... feel free to ask if you need details on one or the other modules.
    1 point
  22. You already said it, it depends... I never go without ListerPro because listing, editing, searching and filtering is so easy, even for inexperienced editors. Since I hate doing forms by myself I use FormBuilder in almost every project. From the ProFields package Table and Multiplier (some of them unfortunately not multilanguage capable)
    1 point
  23. This is how I've done it, hooks to the rescue. Clean. $this->addHookProperty('Language::code', function(HookEvent $event) { $lang = $event->object; $event->return = $lang->name === 'default' ? 'en' : $lang->name; }); So now you can access it as a property of languages. $user->language->code;
    1 point
  24. Hey Thomas, Thanks for this module, looks really interesting, and I'm looking forward to giving it a go. Just a quick comment on this part of the README: I think that a configurable endpoint name would definitely be a worthwhile option – or if that turns out to be difficult, perhaps you might want to consider something slightly more descriptive, such as /rest-api/ or something? To be completely honest I'm being a bit selfish here: I've got the bad habit of using /api/ for any site-specific API implementations I might need, and that would pose an issue for this particular module ? Reminds me of the "two hard things in computer science" thing. This thread already covers both: cache (well, token...) invalidation and naming things ?
    1 point
  25. hi macrura! nice to see the progress. i hope nobody gets me wrong but i still think that going with native pw modules (fields) could have some real benefits. i try to explain what i mean and how i came to that opinion... my first impression when i saw your screenshot was, "very nice". i then asked myself how easy that could be built with a process module and InputfieldMarkup... The dashboard example would be quite easy, consisting of only 3 fields with some markup. but still it would need some coding, of course - and that might be a little more work and a little more time needed than your quick ckeditor solution. but still i'm confessed that working with native pw fields is much cleaner than hacking around with hanna codes and several nested tags inside a ckeditor field. that feels like i get thrown back to my old joomla days where we had only this one huge content field and had to do all the magic with messing around with tags and replacements and so on i hope you get what i'm trying to say. btw: i was thinking if i'm messing up your thread with my post, but as it is a preview thread i think discussion should be welcome now my idea that could combine both worlds: first i thought, "why not using some InputfieldMarkup for the content instead of the whole Process?". you are creating a process page that renders one field of a selected documentation page. i thought, what if we had some fields on that page where we can select the content that gets rendered. then i thought we already have this kind of fields: InputfieldRuntimemarkup. So we would need a quick and easy way to arrange those fields! We already have it: The template editor. I'm using ProcessPageEdit all around my CRM application and it works well for presenting data. It has a clean interface and all you need for arranging your content (fieldsets, tabs, toggles etc - i already mentioned that in my post above). So what if we showed the ProcessPageEdit of the documentations page directly to the user? Admins could modify content quickly and easily and for users we could set the visibility to "locked". this would result in something like that: ckeditor fields would get rendered as HTML, image fields would get rendered as gallery and we could do whatever we want with RuntimeMarkup fields. We would have all the built-in pw magic, we would have a consistant styling (for all admin themes, not only for the one your stylesheets are optimized) and many other benefits. what do you think?
    1 point
  26. I looked into this and one of the limitations that their website does not say is that this API is not available to anyone purchasing access from the U.S. This basically is a dealbreaker for a lot of people and the implementation would mean it's limited to a very small number of people. Modules essentially would only be useful to someone that can purchase using billing addresses in the EU. I briefly considered some sort of credit card fraud... but passed haha. I was really interested in DeepL and went to sign up for the API to get access to it and only found out that I couldn't buy access to it when I went to enter my CC information. Very disappointing that they did not say this anywhere on their website (I checked). I spoke with them this week so the information is up to date on this finding. I sent an email to their staff and they said they are working on making it available outside of the EU but that it isn't due to "tax reasons". They didn't give any sort of timeline so until some point in the future this would only be available to users there. Big bummer.
    0 points
×
×
  • Create New...