kongondo

Thanks for the clarification. I don't know how SettingsFactory works. However, I doubt it accesses your field's database schema. I would imagine it will only be interested in the data you return in ___wakeupValue(). In addition, I don't know how SettingsFactory fetches the data, i.e. automatically or via an API called by the developer. Is it not possible for devs to convert what is returned in FIP to JSON/text for use in SettingsFactory? Alternatively, if you wish to return JSON values, you can do that in ___wakeupValue() but store your respective data sets (pageid and filename) in separate columns without the need for that extra column. It's not a deal breaker in FIP but you really want to avoid data redundancy in your database. Maybe if I understood better how SettingsFactory works I'd be able to give a better-informed response.

This is already integrated. Each country (most countries!) has its own locale data (currency symbol, tax rate, provincial/territorial taxes if applicable, tax names, decimal symbol, etc). Tax rates can be overridden per country (and per territory if applicable). This is a frontend issue which you will need to integrate yourself using ProcessWire $language API and your method of detecting customers location (taking into account the various pros and cons of each). This is about shipping zones. It is already built in but you will have to set up the zones yourself including: The shipping countries (and territories if applicable) Shipping rates in that zone, whether they are flat- or price- or quantity- or weight-based Whether you are using shipping classes (e.g. light goods, fragile products, hazardous, bulky, etc) As well as shipping methods (e.g. normal, express, next day, Post Office, etc). Specifying a maximum shipping fee (if you wish) as well as shipping handling fee (optional) Etc The above allow a lot of control straight out of the box. This is about a 3rd-party software. You will have to do the integration yourself using Padloper 2 API (for inventory). Probably not practical in your case, but please note that in Padloper 2 you can manually create an order (or using the API).

@gebeer What exactly are you storing in this JSON column? I've just had a quick look and it seems you only store pageid and the filename (which you also store separately in the their respective columns). Am I missing something?

Thanks!

Update: Menu Builder 0.2.6 Changelog Added the properties numChildren, totalChildren and showMoreText for use with getMenuItems(). Added option maximum_children_per_parent to limit the maximum number of (included) children a menu item can return. Thanks @derelektrischemoench for inspiration/request. Fixed CSS issue that affected menu items' trash cans in the backend. Thanks @duncan. Refactored code to improve efficiency. In dev branch only for testing. I have also updated the docs, especially around getMenuItems(). @derelektrischemoench, See this gist for an example recursive menu builder function that uses maximum_children_per_parent and showMore. OK, breaktime over, back to Padloper! :-).

Hi @derelektrischemoench. I'll post an update later today. Thanks.

?

Ah I see. I mistakenly thought you wanted to do a comparison. Yes, it does work. I was just wondering if it is a new PHP 7 feature or a PHP quirk. I am just used to count(array) or empty(array) Btw, did you see my edit above? The filter works fine for me with FieldtypePage check.

Not an answer to your question. Is this a typo here or your actual code? // assignment operator and not comparison operator if ($productTemplate = $this->wire('templates')->get(MarkupSnipWire::snipcartProductTemplate)) {} In addition, isn't this meant to be a non-empty array check? Did PHP 7 change this type of check? if ($allowedFieldTypes) Edit Tested and filtering works fine for me with 'FieldtypePage'

Glad you got it sorted.

Hi @brdje. First, welcome to the forums! I am glad you are finding the blog module useful. You are right. A massive oversight on my part! I will work on this as soon as I get a bit of time, which might not be soon, I am afraid. Since posts are just pages, you could just use PW API directly to access each blog field and let PW deal with the fetching of the value in the current language. For instance (rough example): $posts = $pages->find("template=blog-post,limit=20"); $out = ""; foreach($posts as $post) { $out .= "<h2>{$post->title}</h2>"; $out .= $post->blog_body; $thumb = $post->blog_images->first()->width(250); $out .= "<img src='{$thumb->url}'>"; $out .= '<hr>'; } echo $out; It's not ideal, but it should get you started, meanwhile.

Oops, sorry, totally slipped my mind! I'll have a look ?.

Aah. I see what is happening. It isn't strange, actually, but working as expected. When output formatting is off, the value of an image or file field is always a WireArray irrespective of the field's maximum files allowed or the setting in formatted value. There is a note on the field. Please see the screenshot on this post. The reason you didn't need first() in the frontend is because output formatting is on there. In the backend, where your rtm external file is called, output formatting is off, hence the need for first(). You can test this by using TracyDebugger to dump the results of the image field in both your external rtm file and in the template file used in the frontend. You should see the backend dump returning Pageimages and the frontend one Pageimage as illustrated below. bd(get_class($page->image)); Backend dump Frontend dump

Hard to tell without seeing some code. Maybe you image field is set to contain multiple images. In that case $image->url may not work. Could we see some code please. Please note that it is advisable to use the option Render PHP file(s) instead.

That's right. However, Padloper 2 also uses custom Fieldtypes and custom (non-PW) tables where it makes better (technical) sense to do so.

Thanks. I only noticed this yesterday but have not had time to fix it.

Not sure this would work in your case but have you considered Image Marker?

Hi @k07n. Yes, I am OK, thanks ?. I do have some good news but cannot share it now. There was a bit of a rethink about the GUI/UX but we are making some great progress. Hi @Mikie I am not sure what you mean by custom data store. Currently everything will live in the site DB (i.e. accessible via ProcessWire's $database). I'd like to hear more about your line of thinking, thanks. All, sorry it's been a while since the last update. Rest assured that we are working on this as fast as we possibly can with great enthusiasm and motivation without sacrificing quality ?.

Hi @MilenKo. Apologies for the late response. I am not sure what you mean by block title. However, this count() will not work: echo "This menu has: " . count($cat_menu); as $menu->render() returns a string. PHP will return 1 (a boolean) but if you had Tracy Debugger it would throw an error about using count() on a non-iterable variable. If you need to know the number of items you can use the method getMenuItems() introduced here and documented here. You can use the method to either return menu items as a an normal PHP array or as a WireArray. In the examples outlined in the first link above, you can use getMenuItems() with a custom recursive function to render your menu however you wish. In your case though, you can just use it to check number of items. For example: $mb = $modules->get('MarkupMenuBuilder'); // menu items as PHP Array $menuItemsAsArray = $mb->getMenuItems(1108, 1, $options);// param 2 = 1: return array echo 'Number of Menu Items (count($menuItemsAsArray)): ' . count($menuItemsAsArray); // menu items as WireArray Object $menuItemsAsObject = $mb->getMenuItems(1108, 2, $options);// param 2 = 2: return WireArray (the default) echo 'Number of Menu Items ($menuItemsAsObject->count): ' . $menuItemsAsObject->count; In case you just want to know if a menu item is not empty, you can simply check if the return value of $cat_menu is a string. For example: // Render the menu by title $cat_menu = $menu->render(1108, $options); if(is_string( $cat_menu)) { echo $cat_menu; } This, however, will not give you the count as explained above. You'd need getMenuItems() for that. In case you want to know if a menu item is a parent/has children, etc, you can use the WireArray option of getMenuItems() as shown above and use ProcessWire WireArray methods to filter items. For instance: $someChildItems = $menuItemsAsObject->find("parentID=2"); // OR $someParents = $menuItemsAsObject->find("isParent=1"); I hope this helps.

OK. However, my point was that multisite option #1 works with subdomains as well ?. Yes but to some extent No. Let me explain: Core Modules (e.g. AdminThemeUikit) will be physically shared between the sites since they live under wire/modules. By physical is meant the module files. However, optional core modules such as AdminThemeUiKit can be installed in some site-* but not others. Since site-* each have their own databases, site-a might have AdminThemeUikit installed whereas site-b might not. Install just means a reference to the installed module in a site's database. Custom modules, i.e. those that live in site-*/modules are not physically shared. Unless you are using symbolic links (which can be problematic!) each site-* will have its own modules folder. This means site-a/modules can have SomeModule and site-b/modules can also have the identical or same SomeModule. Of course, their respective databases will have references to their respective SomeModule. So, back to your problem. Did you physically copy AdminThemeUiKit to both your site/modules and site-stirnweiss/modules? This is in addition to the core copy in wire/modules/AdminTheme. If you did so, that is wholly unnecessary. If the answer is no, then you are experiencing a different problem, maybe a server configuration issue. It's hard to tell without more information about the 500 errors (apache logs, ProcessWire error logs, etc.

Subdomains work fine for me. Maybe you are a having a 'www' issue? Does this not work? sub.mydomain.de

Hi @nurkka. Sorry for the late response. I have been away. This is an excellent suggestion! I'll have a think on how to best implement it but theoretically, it is doable. Another great suggestion! I would have to rethink the GUI a bit since tabs (Filter: Icons, Filter:Photos, etc) would quickly become unwieldy. On a related note, I have been planning to refactor the items shown in the Inputfield Selector (the filters) as there are a number of things not directly relevant to Media Manager that would confuse editors. For instance, the Inputfield shows non-Media Manager fields, items like Path/URL, etc. I am planning to work on your suggestions and the refactoring in the next update. I might call on you for a bit of testing before release, if that's OK. Thanks.

That's what @elabx said! :-) ?? Good to see you (again) as always ?.

@elabx was right :-) Here't two ways in addition to @dragan's above: Method 1: Call Hanna inside your function function SomeFunction(){ $out ="<div>"; // hanna in here $hanna = wire('modules')->get('TextformatterHannaCode');// @note: wire! $out .= $hanna->render("[[hello]]"); $out .="</div>"; return $out; } $out = SomeFunction(); echo $out; Method 2: Pass your function an argument/parameter with Hanna rendered output $hanna = $modules->get('TextformatterHannaCode'); $hannaString = $hanna->render("[[hello]]"); function SomeFunction2($string){ $out ="<div>"; // hanna in here $out .= $string; $out .="</div>"; return $out; } $out = SomeFunction2($hannaString); echo $out;

Great! I am glad it got resolved!