Leaderboard

A bit off-topic, but while typecasting an empty array to boolean does indeed result in false, "empty($array)" has its benefits. It's slightly more verbose, but it also won't cause a notice if $array hasn't been defined yet, and it's arguably more obvious (leading to better readability). Relying on typecasting can sometimes result in obscure issues, as well as make the code ever so slightly harder to decipher. Using "count" to check if an array is empty is a common mistake. Even if in most cases the actual performance difference is too small to really matter, there's no reason to do this ??

It would happen to any fieldtype since filter() and not() methods are destructive. On the first call the $fields array ($productTemplate->fields) would contain all fields, after applying filter it would contain only filtered fields. On the second call of your function $productTemplate->fields does not returns all fields but only filtered fields ('FieldtypeText', 'FieldtypeTextLanguage', 'FieldtypePageTitle' and 'FieldtypePageTitleLanguage') and FieldtypePage is not among them. Use find() instead of filter() as it returns a new WireArray, this might work: if ($allowedFieldTypes) $fields = $fields->find('type=' . implode('|', $allowedFieldTypes));

If you want to test it, you will have to use the branch jsonvalue from github.

This week we’ll take a look at LoginRegisterPro — a new module that provides an all-in-one, self contained module for providing new user registration, secure logins, profile editing, and more. It does this all in a manner that is reliable, efficient, comprehensive and secure. As we continue preparing the ProcessWire core dev branch to become our new master, I've been trying to stay hands-off on new feature additions there as much as possible (till the new master is out), and instead focusing on finishing up modules I've had in development. Last time I told you about the UserActivity module, and this time we’ll look at LoginRegisterPro, which is another module dealing with users; though significantly larger in scale/scope. LoginRegisterPro is a module I've been working on for more than a year, and finally this month have it ready to share. While I don't have it available for download today I do expect to have a beta release as soon as early next week. Read this week’s post for more details— https://processwire.com/blog/posts/login-register-pro/

Hello All, This is just simple thought of mine over a simple a WordPress work I had to take recently. I am just discussing how I felt about WordPress is falling apart on the Content Management. My Article is here P:S :- My blog is still uses WordPress ?

You can have a look at my relatively new help videos module. Relevant code starts here. All the basics for creating fields and templates and pages are there. Should be easy to build upon. The uninstalling part goes in the ___uninstall() method. You basically need to keep track about what you installed (e.g. save this info to your module config data) and then remove that stuff.

Sad to see you go, but this seems like a reasonable conclusion in your case ? Regarding your issue – I've never come across anything exactly similar myself. Since we're talking about the default multi-language site profile, there's very little data to load, so my initial guess would be that the request, or perhaps the PHP process, gets stuck somewhere. In the case of PHP the file compiler (core feature originally intended to ease migration from 2.x to 3.x) comes to mind – though that probably shouldn't be the case here – while disk based sessions could be another. Of course the database connection could also be the bottleneck, but if you're sure that it's configured properly, then I have no idea how it could be that slow. MySQL slow query log could help in ruling this issue out though. If you still want to debug this further, you might want to give database sessions a try (they can be enabled by installing the Sessions / ProcessSessionDB module, which is bundled with the core package), and just in case specifically disable the file compiler by setting $config->moduleCompile and $config->templateCompile to false in /site/config.php. I have no recent experience with Windows, so not sure if something there could cause the slowdown. That being said, I do know that others are running ProcessWire on Windows, so that alone shouldn't be a problem, unless it's some rather obscure configuration issue there. If other systems are working as expected then a configuration issue sounds less likely. While WordPress admittedly caters for a number of really unlikely borderline cases (including the use of the deprecated mysql PHP extension), Laravel working as expected probably means that the environment itself is properly set up.

cool! Image picking has been an issue with SettingsFactory... so this will be great ?. I'll check it out and do some testing asap!

Sure... tell more about you, your company, your sites, your needs... and there will be plenty of talented ProcessWire developers that like to help you.

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.

@gmclelland here are screenshots of my use case and solution with the medialibrary module and the imagepicker module: This is very nice solution. The site owner likes it. She can select completly visual. No distracting informations around. Just the icons. :)

My take if($page->parents->has($section)) ... if($section->find("id=$page")->count()) ... // direct parent-child if($section->children("id=$page")->count()) ... if($page->parent === $section) ...