Leaderboard

It sounds like output formatting is off for the page in question. I haven't used multi-instance so I'm not sure if it's normal for pages retrieved this way to have output formatting off by default or if it's a bug. But you can turn output formatting on for your page like this: // $p is your page from the other instance $p->of(true); // Now output field values from $p

Nice to meet you all My name is Micthew, i'm from Indonesian, i am beginner in ProcessWire CMS ProcessWire CMS is great, i like to use ProcessWire CMS when i build some website. But in this Project, my client want his website have multilanguage feature, but in my country (Indonesian), English language isn't our basic language, we have our own language. So, how can i make multilanguage : Indonesian Language and English Language? 'Cause he said only 2 languages Thank you all, i hope you all can give me some enlightenment I'm apologize for my bad english language?

A very nice and clean solution! Should your needs grow from this, you might enjoy one of the following options as well: Field Descriptions Extended Process Documentation

For some reason i stopped getting notifications... Manually creating fields shows me this code: 'manual_select_field' => [ 'label' => 'Manual Select Field', 'flags' => 0, 'type' => 'FieldtypeOptions', 'label1024' => 'Manuelles Select Feld', 'inputfieldClass' => 'InputfieldSelect', 'collapsed' => 0, 'tags' => '', 'initValue' => '', 'showIf' => '', 'themeInputSize' => '', 'themeInputWidth' => '', 'themeOffset' => '', 'themeBorder' => '', 'themeColor' => '', 'columnWidth' => 100, 'required' => '', 'requiredIf' => '', 'defaultValue' => '', 'options' => [ 1 => 'VERYLOW|Very low', 2 => 'LOW|Low', ], 'optionLabels' => [ 'de' => [ 1 => 'VERYLOW|Sehr niedrig', 2 => 'LOW|Niedrig', ], ], ], When i use that in my migration code for another field (with the migrate command), the duplication effect also happens in the German field. When i only give the German labels, then i have the same effect as before. What's also interesting: When i remove the values "VERYLOW" and "LOW" from both fields, including the "|", then the duplication doesn't happen. That strange error message while refreshing is still there. I think i'll try a clean installation, just in case i messed something up. I'll look into it tomorrow.

Personally when I install a CMS I prefer to set it inside a subdirectory rather than the root folder. There are different reasons for this choice. For example you may wish to have different CMS installed in different subdirectories; or multiple copies or versions of Processwire in different subdirectories; keep separated directories for production and development; and so on. Sometimes this choice is taken also to obfuscate your CMS contents. In this forum I found some helpful hints, but I could not find a turn-key tutorial explaining the detailed steps for redirection and how to hide subfolder in urls' segments. It's pretty easy. Just let's do it step by step. We are going to create a new .htaccess file in the root folder (please note it is a new one, we will leave the .htaccess file in Processwire subfolder unchanged), where we will add the section described below. Just replace yoursite.com and yoursubfolder with ... your ones! # .htaccess in root directory # Redirect to Processwire subdirectory <IfModule mod_rewrite.c> RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteCond %{REQUEST_URI} !^/yoursubfolder/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ /yoursubfolder/$1 RewriteCond %{HTTP_HOST} ^(www.)?yoursite.com$ RewriteRule ^(/)?$ yoursubfolder/index.php [L] </IfModule> With this approach we can protect root files and subdirectories from redirection. Are we done ? Yes and no. After these modifications pages are redirected correctly, but in the browser link you will note that subfolder's name is still showing. This is not good, we want to hide it. We are just one step away. Let's open our site/config.php and add the following line at the end: /** * Set urls root to hide Processwire folder * This must be combined with .htaccess in root directory */ $config->urls->root = '/'; Do not forget to lock site/config.php after modifying it. If you prefer, instead of modifying config.php, you can place the above line in _init.php. And here it is! I hope this simple tutorial can be of help.

The terms did not change and will not change, though there will not be any updates/fixes/support. I'll write you a PM regarding the new version of RockForms

Hi @Robin S You are right. The output formatting is off if pages are pulled from another ProcessWire instance. I am not sure whether it is intentional or a bug. For me it is not intuitive to use. Gideon

Just open your PW Admin Panel -> Modules -> Install Language Support Languages Support - Fields Languages Support - Page Names Languages Support - Tabs

hi Mr. @Gideon So Thanks for accepting and replying my topic Oohh i see, but why when i install URL (Multi-language) FieldtypeURLLanguage Module, the Module has requires: LanguageSupportFields Module ? Can you explain to me about that? Thank you before Mr. Gideon

This week core updates are focused on resolving issue reports. Nearly all of the 10 commits this week resolve one issue or another. Though all are minor, so I'm not bumping the version number just yet, as I'd like to get a little more in the core before bumping the version to 3.0.202. This week I've also continued development on this WP-to-PW site conversion. On this site hundreds of pages are used to represent certain types of vacations, each with a lot of details and fields. Several pages in the site let you list, search and filter these things. When rendering a list of these (which a lot of pages do), it might list 10, 20, 100 or more of them at once on a page (which is to say, there can be a few, or there can be a lot). Each of the items has a lot of markup, compiled from about a dozen fields in each list item. They are kind of expensive to render in terms of time, so caching comes to mind. These pages aren't good candidates for full-page caches (like ProCache, etc.) since they will typically be unique according to a user's query and filters. So using the $cache API var seems like an obvious choice (or MarkupCache). But I didn't really want to spawn a new DB query for each item (as there might be hundreds), plus I had a specific need for when the cache should be reset — I needed it to re-create the cache for each rendered item whenever the cache for it was older than the last modified date of the page it represents. There's a really simple way to do this and it makes a huge difference in performance (for this case at least). Here's a quick recipe for how to make this sort of rendering very fast. But first, let's take a look at the uncached version: // find items matching query $items = $pages->find('...'); // iterate and render each item foreach($items as $item) { echo " <!-- expensive to render markup here ---> <div class='item'> <a href='$item->url'>$item->title</a> ...and so on... </div> "; } That looks simple, but what you don't see is everything that goes in the <div class="item">...</div> which is a lot more than what you see here. (If we were to take the above code literally, just outputting url and title, then there would be little point in caching.) But within each .item element more than a dozen fields are being accessed and output, including images, repeatable items, etc. It takes some time to render. When there's 100 or more of them to render at once, it literally takes 5 seconds. But after adding caching to it, now the same thing takes under 100 milliseconds. Here's the same code as above, but hundreds of times faster, thanks to a little caching: // determine where we want to store cache files for each list item $cachePath = $config->paths->cache . 'my-list-items/'; if(!is_dir($cachePath)) wireMkdir($cachePath); // find items matching query $items = $pages->find('...'); // iterate and render each item foreach($items as $item) { $file = $cachePath . "$item->id.html"; // item's cache file if(file_exists($file) && filemtime($file) > $page->modified) { // cache is newer than page's last mod time, so use the cache echo file_get_contents($file); continue; } $out = " <!-- expensive to render markup here ---> <div class='item'> <a href='$item->url'>$item->title</a> ...and so on... </div> "; echo $out; // save item to cache file so we can use it next time file_put_contents($file, $out, LOCK_EX); } This is a kind of cache that rarely needs to be completely cleared because each item in the cache stays consistent with the modification time of the page it represents. But at least during development, we'll need to occasionally clear all of the items in the cache when we make changes to the markup used for each item. So it's good to have a simple option to clear the cache. In this case, I just have it display a "clear cache" link before or after the list, and it only appears to the superuser: if($user->isSuperuser()) { if($input->get('clear')) wireRmdir($cachePath, true); echo "<a href='./?clear=1'>Clear cache</a>"; } I found this simple cache solution to be very effective and efficient on this site. I'll probably add a file() method to the $cache API var that does the same thing. But as you can see, it's hardly necessary since this sort of cache can be implemented so easily on its own, just using plain PHP file functions. Give it a try sometime if you haven't already. Thanks for reading and have a great weekend!

Sorry for my late response in general. I haven't used ProcessWire ( and therefore also PrivacyWire) in new business projects in the last time but was quiet busy with work. I think that actually is the easiest way right now. In general yes. But it depends on how you implement PrivacyWire and the 3rd-party scripts! Yes, this is possible. See this forum thread for examples. Feel free to fork, add the feature and start an PR.

Not technically a supported feature at present, but I think you can get the result you want. You'd take a query like this: $pages->find("body*=something"); and convert it to this: $pages->find("body.data{$user->language}*=something"); That should return just the pages that match the current user's language, rather than including the default language.