Leaderboard

The company I work for in central Connecticut, Solution Innovators, is looking to hire a programmer with ProcessWire experience to join our small but growing team. We've been working with PW since 2012 and have numerous marketing sites and web applications built on it. Strong PHP skills are a must, with experience building object oriented systems and organizing and documenting code in a clean, maintainable and reusable fashion (like the ProcessWire core). Skills in Vue.js, javascript, jQuery, html, and css are a plus. DM me for more information!

Supposedly this dude is rebuilding it ? Ok seriously, trying hard, but my time is also limited right now, I almost have the UI rebuilt in Alpine, just need to wrap my head around the Fieldtype interface. But I'd say it's still at like 20% - 30% I am trying to get a run at it asap to build the bare minimum, without the Markup modules, which I also need anyway lol

It seems that, as @kongondo notes, there's an issue with the findRaw() syntax, at least with the array-type syntax and page-reference fields. However, the dot syntax seems to work. So I think the following will give you what you need: $items = $pages->findRaw("template=template-news, select_region=austria, limit=2, objects=1", ["select_countries.id", "select_countries.title"]); Or slightly simpler, as the keys of the returned array of page references are the page ids: $items = $pages->findRaw("template=template-news, select_region=austria, limit=2, objects=1", ["select_countries.title"]); I've submitted an issue regarding the other syntax: https://github.com/processwire/processwire-issues/issues/1563

Sorry about that. I'll try to update with some more information asap.

@thetuningspoon, Thanks for posting this. If possible, please edit your post and address points #1 - 3 as relevant as per the job posting guidelines: E.g. remote working, US-based, similar time zone, etc ?. Thanks!

Hi @Gideon So, I will prepare something, but it's mostly taking advantage of the Repeating fields.

Triasima, a portfolio management company, asked the agency Contractuelle to revamp its web image. Spiria was the contractor for the site integration. While seemingly straightforward, there were a few challenges ahead, including managing three distinct regions that shared a lot of content: Canada, the United States and the Rest of the World. Two of these regions were assigned a sub-domain (us. and world.). We did not need a multi-site module. Within each region, the visitor has to choose a type of investment profile. One of these profiles could only be selected by the Canadian region. Each profile shares some content but is identified by colour. In short, a small puzzle solved with very little code and CSS. We made extensive use of field repeaters to create a nice administration interface. We have designed "presentation scenarios" that allow the administrator to set up pages as they wish. Only the header and footer are fixed. https://triasima.com

Hello, We have been audited by a security firm regarding a new website in Processwire. The client is a financial firm and insurance companies are becoming increasingly wary of the vulnerabilities that certain libraries represent. The report mentions the two obsolete jQuery libraries that ProcessWire uses for the admin part. Although the visitor or potential hackers are not aware of the use of these libraries (and the report does indicate that the site is secure), the report still mentions a moderate risk when it comes to the administration of the site. In short, the following libraries are requested to be updated to remove these vulnerabilities. .../wire/modules/Jquery/JqueryUI/JqueryUI.js .../wire/modules/Jquery/JqueryCore/JqueryCore.js It might be time to upgrade on this side. Is it possible to do this without causing problems in the administration of the site? I can do my own tests, but I would still like to know the reasons why this is not up to date.

@benbyf still in very early progress and I don't see how it would help with the front week view. The original module did have some rendering modules attached but those are the last priority in this refactor.

The files you work with will always be on your local machine. And I see no foolishness here :) Working inside the container itself (using the shell script in the Devilbox directory) shouldn't be needed so no worries there. Some recommendations (and me thinking out loud)- If you're getting a 500 error with a page title before failure then PHP is booting properly. I would start with ProcessWire's logs first in case it's able to catch that error when it executes. Could be more info there. Double check that $config->debug is set to true in config.php to see if you can squeeze out any more information from your 500. Check your .env config to make sure you're running either PHP 7.4 or 8.0 (depending on your PW version) just in case Devilbox's defaults to PHP 8.1 which PW isn't fully compatible with yet AFAIK. I think it might do that IIRC. Knock out those items and we can troubleshoot from there if it doesn't fix the problem.

You can do a find() but with a limit of 1. This will be just as efficient as findOne(), the only thing is that it will return a PageArray so use first() to get the item as a Page. $results = $pages->find("template=template-news, sort=created, limit=1, start=1"); if($results->count) { $title = $results->first()->title; }

Nice! Very awesome seeing the concept worked on and a great contribution to the ecosystem. Working with time bends my brain, you have my respect and admiration haha. Looking forward to seeing your work. Haven't used Alpine yet personally but it looks fantastic.

@teppo I completely agree. Thank you for your important addition. In situations where the search section is not a essential part of the UX of a site/project (with only low budget for this part), it is possibly o.k. to use just one approach. Still combining client- and server validation is to prefer in most cases.

@sebi @Jukka Sorry I cannot help with pro cache. But caching with memcache or even flat files might be a start? This is not tested at all but just to outline the idea: public static function getUser($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']); $response = new \StdClass(); $user = wire('users')->get($data->id); if(!$user->id) throw new \Exception('User not found', 404); $response->id = $user->id; $response->name = $user->name; // cache in a file $cache_file_name = hash('sha256', $data->id); $cache_path = "cache_path/$cache_file_name"; if(!is_file($cache_path)){ // the cache file does not exist let's add it file_put_contents( $cache_path, json_encode($response) ); } else { // the cache exists, let's read it and return the data $response = file_get_contents($cache_path); return $response; } // the cache does not exist let's return it form the std class return $response; } Of course it would be MUCH better to use ProCache or memcache. @sebi Have you tested multilanguage? I wonder what would be the best option. A) To have namend routes like /api/test/ /apit/en/test that map to the same function, which checks for the /en/ part or B) handle the language switch by a get ver /api/test/ /apit/test?lang=en that controlls the language?

Hi. Not tested but should work $this->wire()->addHookAfter('LanguagesPageFieldValue::getStringValue', function ($event) { $value = $event->return; $languagesPageFieldValue = $event->object; $languages = $this->wire()->languages; $userLanguageID = $this->wire()->user->language->id; $chineseLanguageID = $languages->get('chinese')->id; $newFallbackLanguageID = $languages->get('english')->id; if($userLanguageID === $chineseLanguageID && !$languagesPageFieldValue->getLanguageValue($chineseLanguageID)) { $value = $languagesPageFieldValue->getLanguageValue($newFallbackLanguageID); if(!strlen($value)) { $value = $languagesPageFieldValue->getDefaultValue(); } }; $event->return = $value; });