kongondo

Thanks @MarcoPLY. Yes, I was already aware of it but it is great of you to bring it up like this for the benefit of everyone else.

Upgrade Path: Padloper 1 to Padloper 2 I have been getting a number of enquiries regarding upgrading from Padloper 1 to 2. I would to reiterate that whilst there isn't a direct upgrade path, it is still possible to import products from Padloper 1 (or any other shop system for that matter) to Padloper 2 using either the API ($padloper->importProducts($imports);// array/json/csv) or the GUI. However, please note the following: You will have to export products from Padloper 1 yourself. No script will be provided for that. You will have to do any manual cleanup of the data as well as additions to the data yourself. Documentation will be provided about the fields required for the import into Padloper 2, e.g. Product title, description, etc, and any optional fields. Supported import formats are JSON, CSV or arrays. Importing into Padloper 2 does not have to be a one-off exercise. Import will have the option to overwrite/update/skip existing identical products. I hope this clarifies things.

Sorry, rookie mistake on my part :-). I had them both with identical titles. Corrected in 007. Hmm. That's very strange. By 'overwrite editor modal', do you mean the one where you can overwrite a field's 'original' label, description, notes, etc for a specific template? Are you able give me more details please? Which field values did you try to edit? Did the error crop up after saving or as soon as you opened the modal? ProcessWire version Thanks.

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.

Update: Blog 2.4.4 Changelog Fixed bug that caused blog settings not to save in blog admin. Thanks @Troost for reporting. Module has been updated in the modules directory.

Glad you like it! :-). You do that by passing $options to renderPosts(). I can only apologise that I've never completed the documentation for this module. Please have a look at the options here, in the method processPostsOptions(). All the options that can be passed to renderPosts() are there. For instance, 'post_date' => 1,// display post's date: 0=off,1=top(below post-headline),2=bottom(in post-foot) The string is on this line. Is it not appearing in the translation screen? I've never done translation myself so, I wouldn't know how to help beyond this. If you are still experiencing issues, maybe one of your multilingual members could help out. You caught a bug! Thanks for reporting. I've fixed it in the latest version (2.4.4). I've updated the module in the modules' directory.

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...?

My mistake sorry. It is definitely related to this identical issue reported for Media Manager ?. I'll sort it out ASAP. Thanks for reporting.

I have no idea. I never asked. I could try and find out.

Sorry I wasn't clear. Media = $page Media has one MM field. In the case of images, it is an multi image field. So $page->image_field will give you the image Media has a title field: $page->title;// title of your media If you had own fields to Media, you can access them using $page->your_field, as usual. However, we don't use the variable $page. Instead what you get is a MediaManager Object. So, Media page object is $mm. Echo $mm->id: id of the media Echo $mm->title; // this is the image field foreach($mm->media) { } Hope this makes sense.

Subscriptions (update + VIP support) are valid for 1 year. After that you can renew for a fraction of the original price. Otherwise, I don't send out update reminders but post here in the forums. If you have a valid subscription, you can use the resend download links form to get an email with the download link to the latest version (or use the link in the original email you received after purchase). For renewals, please use the renewal form. Any problems, please PM or send me an email.

Each media is a PW page, hidden in admin part of the tree. Non-supersusers never get to see them :-).

Thanks for the feedback. Was this an older version or the latest (012)?

Not at all :-). Thanks for the feedback. I value such feedback. Actually there is/was...but it is outdated. I can look into this. Meanwhile, one can always test and request a refund if they are not satisfied with the product :-). Agreed. The thing that confuses me though is that we have hundreds of people using Media Manager, for client projects, some quite big (working with Hollywood; +500K images, etc) but not a single person has ever mentioned design issues. I am not saying this translates to no issues but a I am a bit curious why no one else has raised such issues. Thanks.

Glad you got it sorted :-). If possible, please post a showcase/use case in the RM thread. I also realised I pointed you to the docs of RM and they are really outdated! Hope you were able to find your way around the setup!

Yes, everything is integrated in one install. I haven't yet decided what a 'basic shop' looks like, i.e. what to install and what to make configurable. Looking at other systems, their offerings differ quite a bit. This is a conversation I was planning to have with beta testers but we can open it up to the whole community to discuss.

I hope I didn't come across as shutting the door on the suggestions here :-). I was just pointing out a few realities. Like I said, I don't know much about marketing. It would be wise to listen to those who do :-). So, yes, I am still listening and by all means, let folks continue to chime in please.

Or you could just use a RuntimeMarkup field ? with WireHttp() and $cache. I'd never heard of SmugMug before ?. Here's a demo for how this could be done in RM. We are mimicking a ProcessWire image field by using similar markup and including Image field's JS and CSS. Please see the notes in the code. We are also caching the response for 1 hour so we don't hit SM limits. I created a free 14-day trial account for this. Here it is...I couldn't think of a better name for it ?. As you can see in the demo video, we are pulling the exact images. The code could be improved. You could get all fancy and even push changes to SM using Ajax, for instance. Please see the examples in RM docs. This code goes into the file you are rendering. <?php namespace ProcessWire; // set PW image assets $url = $config->urls->InputfieldImage; $config->styles->add($url . "InputfieldImage.css"); // @note: JS just in case you need it but in that case, you will also need Magnific, etc $config->scripts->add($url . "InputfieldImage.js"); // get cache only if it’s less than or equal to 1 hour old (3600 seconds) // @note: cache is unique for this page $cacheName = "smugmug_{$page->id}"; $images = $cache->get($cacheName, 3600); // no cache or expired, request data from smugmug if(is_null($images)) { // Get an instance of WireHttp $http = new WireHttp(); // we want JSON, so set headers accordingly $headers = array('Accept'=>'application/json'); $http->setHeaders($headers); // an example public album $url = 'https://www.smugmug.com/api/v2/album/xxxxxx!images'; $data = array('APIKey'=>'12345678900987654321');// API key $response = $http->getJSON($url, true, $data); $images = $response['Response']['AlbumImage']; // cache the response, and expire after 1 hour (3600 seconds) // @note: only caching the albmum! $cache->save($cacheName, $images, 3600); } // outer list markup for images (c & p from PW with slight modifications) $out = "<ul class='gridImages ui-helper-clearfix ui-sortable'>"; // iterate through response. // @todo: You might want to do some error checking first foreach($images as $image) { // file size to kB $fileSize = ceil($image['OriginalSize'] / 1000); $out .= " <li id='file_{$image['UploadKey']}' class='ImageOuter gridImage ui-widget'> <div class='gridImage__tooltip'> <table> <tbody> <tr> <th>Dimensions</th> <td>{$image['OriginalWidth']}x{$image['OriginalHeight']}</td> </tr> <tr> <th>Filesize</th> <td>{$fileSize} kB</td> </tr> <tr> <th>Description</th> <td><small>{$image['Title']}</small></td> </tr> </tbody> </table> </div> <div class='gridImage__overflow' style='width: 130px; height: 130px;'> <img src='{$image['ThumbnailUrl']}' alt='{$image['Caption']}' data-w='{{$image['OriginalWidth']}}}' data-h='{{$image['OriginalHeight']}}' data-original='' style='max-height: 100%; max-width: none; top: 50%; left: 50%; transform: translate3d(-50%, -50%, 0px);'> </div> <div class='gridImage__hover'> <div class='gridImage__inner'> <label for='' class='gridImage__trash'> <input class='gridImage__deletebox' type='checkbox' name='delete_images_{$image['UploadKey']}' value='1' title='Delete'> <span class='fa fa-trash-o'></span> </label> <a class='gridImage__edit' style='line-height: 130px;'> <span>Edit</span> </a> </div> </div> </li> "; } $out .= '</ul>'; $out = "<div id='my_album'>{$out}</div>"; return $out; Screenshot Video Demo

RE Branding Thank you all for the conversation so far ?. Just some quick pointers/thoughts: There are two areas of branding that have been referred to so far. The first one is what users see when they log into the backend. The second has more to do with selling the product, aka marketing. Regarding the first one, unlike the present Padloper, the name Padloper will not appear anywhere in the shop. Btw, you will be able to call your shop whatever you want - store, shop, blah blah. So, reports, taxes, etc, will all just be part of the shop. No extra shop links outside the shop itself. Regarding the second issue of marketing, I am not an expert, so I'll pause and have a listen. However, @teppo is right. The name does already have some brand value and the product 'has been selling itself', so to speak. I am not saying things cannot be improved. In addition, and I am just thinking out loud here, I don't have the stats for how many people have come to ProcessWire because of Padloper. My gut feeling is probably not that many (if any at all). On the contrary, I think most Padloper users (I am referring to devs) were already ProcessWire users and needed an eCommerce solution. Of course, we can always aspire for the former case (Padloper attracting people to ProcessWire), but that's probably a longer term discussion.

Are your tests not working? It works here as expected. When I loop through $arr, the text for item with identifier=456 is "some other text";

Once you get to know the system, you could write some scripts to match fields and copy things over. You could probably use the new Padloper API to do this, e.g. the import functionality if you need to import products.

You mean like this? Seems you missed the eligibility screen ?. The GUI is not yet complete. The details are: Specific Groups of Customers New customers (have never bought something) Returning customers (have previously bought something) Abandoned checkouts Customers from own country (will probably change this to 'from specific countries') Newsletter (customers signed up to newsletter - this may not make it in the first release though + I haven't decided whether newsletter should be part of Padloper or not or third party, etc) Specific Customers Here you will select specific customers. These will have to be registered customers

This hasn't crossed my mind but it is something worth considering now that you mention it. Let's hear what the community thinks. If the discussion gets a bit long we can move it to its own topic.

If by this you mean stuff like "10 orders placed today..." or staff to staff messaging, etc, that's already planned and partly modelled. Notifications will mainly be shown on the main landing page and on orders. I haven't started on the GUI yet, that's why there is nothing to see currently :-). Most likely this is what we'll tackle last, before beta release.

There will definitely be conflicts, I am afraid. For instance, the module Padloper.module in Padloper 1 vs Padloper 2 are two different things + ProcessWire/PHP won't allow two classes with identical names . Do you have a specific need to run both the old and new versions?