Leaderboard

A rather large update today for this language pack. Including a lot of new modules, some new Pro modules. And core translations for the 3.0.133 dev version. As usual, the translations is not complete. And some typos might exist.

Yeah, @Robin S is mostly correct. The array approach seems like a good idea, but it will end up biting you in many cases. For ease of readability and building up complex selectors, I do build them with a regular php array and then simply implode the array with a comma to get the string selector. This is now my goto approach for any complex dynamic selectors.

@buster808 Can you please use the code blocks provided by the forum instead of copy pasting directly from your editor into the post. It's really hard to read the way they're right now.

PS, here's the thread @Robin S was referring to:

That sounds weird but... the good new are... it's probably not a server issue. ? Just a few questions to understand things better. Has your user superuser rights/privileges? What's your username? Admin? Check your access roles in Access > Users. Are all pages affected or only some pages? (you said some pages don't update) what can be changed? what can't be changed? what have pages with/without changes you can/can't save in common? templates? fields? What can/can't be changed? Do you get any error messages? What do they say? Do you see any changes in the backend? After saving a page: can you see and any new timestamps in Settings (tab) > Info?

https://github.com/processwire/processwire/pulls There are still pull requests from 2016... Please @ryan could you take a look at the PR repository just like you did with the issues over the last weeks? There are many simple ones that really just need to be merged (like https://github.com/processwire/processwire/pull/143/commits/80aa0ac2e6383b32a4d0a932d5bec78a8fb5bf14 ). It's really frustrating if one tries to contribute and this contributions just seem to be ignored ?

We recently rebuilt the Architekturführer Köln (architectural guide Cologne) as a mobile-first JavaScript web app, powered by VueJS in the frontend and ProcessWire in the backend. Concept, design and implementation by schwarzdesign! The Architekturführer Köln is a guidebook and now a web application about architectural highlights in Cologne, Germany. It contains detailled information about around 100 objects (architectural landmarks) in Cologne. The web app offers multiple ways to search through all available objects, including: An interactive live map A list of object near the user's location Filtering based on architect, district and category Favourites saved by the user The frontend is written entirely in JavaScript, with the data coming from a ProcessWire-powered API-first backend. Frontend The app is built with the Vue framework and compiled with Webpack 4. As a learning exercise and for greater customizability we opted to not use Vue CLI, and instead wrote our own Webpack config with individually defined dependencies. The site is a SPA (Single Page Application), which means all internal links are intercepted by the Vue app and the corresponding routes (pages) are generated by the framework directly in the browser, using data retrieved from the API. It's also a PWA (Progressive Web App), the main feature of which is that you can install it to your home screen on your phone and launch it from there like a regular app. It also includes a service worker which catches requests to the API and returns cached responses when the network is not available. The Architekturführer is supposed to be taken with you on a walk through the city, and will keep working even if you are completely offline. Notable mentions from the tech stack: Vue Vue Router for the SPA functionality VueX for state management and storage / caching of the data returned through the API Leaflet (with Mapbox tiles) for the interactive maps Webpack 4 for compilation of the app into a single distributable Babel for transpilation of ES6+ SASS & PostCSS with Autoprefixer as a convenience for SASS in SFCs Google Workbox to generate the service worker instead of writing lots of boilerplate code Bootstrap 4 is barely used here, but we still included it's reboot and grid system Backend The ProcessWire backend is API-only, there are no server-side rendered templates, which means the only PHP template is the one used for the API. For this API, we used a single content type (template) with a couple of pre-defined endpoints (url segments); most importantly we built entdpoints to get a list of all objects (either including the full data, or only the data necessary to show teaser tiles), as well as individual objects and taxonomies. The API template which acts as a controller contains all the necessary switches and selectors to serve the correct response in <100 lines of code. Since we wanted some flexibility regarding the format in which different fields were transmitted over the api, we wrote a function to extract arbitrary page fields from ProcessWire pages and return them as serializable standard objects. There's also a function that takes a Pageimage object, creates multiple variants in different sizes and returns an object containing their base path and an array of variants (identified by their basename and width). We use that one to generate responsive images in the frontend. Check out the code for both functions in this gist. We used native ProcessWire data wherever possible, so as to not duplicate that work in the frontend app. For example: Page names from the backend translate to URLs in the frontend in the form of route parameters for the Vue Router Page IDs from ProcessWire are included in the API responses, we use those to identify objects across the app, for example to store the user's favourites, and as render keys for object lists Taxonomies have their own API endpoints, and objects contain their taxonomies only as IDs (in the same way ProcessWire uses Page References) Finally, the raw JSON data is cached using the cache API and this handy trick by @LostKobrakai to store raw JSON strings over the cache API. Screenshots

Please try this version, check the box under advanced options. AutoSmush.zip

Firefox has some nice features while debugging grid layouts. At least they feel more solid than those in Chrome. I use Opera once in a while but only for very basic tasks. Somehow it feels clunky and slow. While Chrome was my daily driver for a long time I recently started using the Brave browser for casual browsing. For now I tried to unsubscribe again and added those mails to the Spam list in Gmail. Maybe this helps.

I have never used that module, but I guess it should be: $content .= $modules->MarkupSocialShareButtons->render();

I don't get any letters, but I had deleted my FF-Sync Account because I got doomed by their expired Cert for AddOns. First it deleted my local AddOns and then "uploaded" it to my Sync-Account, what in fact deleted all AddOns there too. For me it was the drop that broke the camel's back. I switched to Opera and there are now only two points of 20+ left which I haven't solved to my satisfaction in Opera yet. In some regards Opera even is a better tool then FF. I really liked it after two weeks using. It seems that this has caused, among other things, a great loss of trust or resentment, which may have led to reduced user numbers. I still use the FF to test websites in the FF, but for nothing else.

Also take a look at the JS console, maybe you'll spot errors there, while editing / saving a page.

Actually all of the above, but yes, the Tracy dump is a key part of it - so much easier to see which parts are being added to the selector this way. I do also sometimes modify parts by key, but I also just find my code looks cleaner that concatenating a string with commas at the end of each one, plus you don't have to worry about a possible trailing comma.

Just my opinion: I'm not sure there's much advantage to doing that - selector arrays seem more trouble than they are worth. When you start needing things like OR groups and nested selectors (which you inevitably do) the array syntax gets quite verbose and frankly less readable than the string syntax (especially if you are already familiar with the string syntax). I can't locate the topic now but I remember @adrian working with selector arrays for a while and I think he ended up reverting back to selector strings because there were too many issues/hassles with the array syntax. Maybe he will correct me on that.

There are a few things that came up in my mind right now. First I thought it looked like a failed git/SVN merge of some kind but afterwards it looked liked a failed upload from FileZilla. At least they both look pretty similar somehow. As you stated that there are more instances of other sites and CMSs on that hosting you might want to try to set up different users for different sites. I guess you are using a US hosting company such as DreamH*st, H*stgator or Blueh*st, *2, or another 3.99/month mass-hosting ... I had several similar issues with these companies in the past - but to their rescue - they offer different users on a account to separate installations/instances of different sites. TL;DR: what @teppo and @louisstephens say seems to be the case... someone got somehow access to that hosting. Maybe even through a nifty trick in W*rdPress.

@elabx Have you tried something like this? $selector = [ [ 'field' => 'template', 'value' => ['transaccion', 'pago'], 'operator' => '=', ], [ 'field' => 'pago_entit', 'value' => $user, 'operator' => '=', 'or' => 'test', ], [ 'field' => 'transaccion_representante_cliente', 'value' => $user, 'operator' => '=', 'or' => 'test' ], [ 'field' => 'sort', 'value' => '-created', ], [ 'field' => 'status', 'operator' => '<', 'value' => Page::statusTrash, ] ]; Not sure that is it even the right direction as it produces such selector dump: template=transaccion|pago, test@title=(41), test@email=(41), sort=-created, status<8192

I just switched over to VSCode (Insiders) a couple weeks ago now that it integrates with WSL using the new extensions. Version Lens seems useful if using NPM: https://marketplace.visualstudio.com/items?itemName=pflannery.vscode-versionlens "Shows package version information for npm, jspm, bower, dub and dotnet core in the Visual Studio Code editor."

I guess if Zapier is an option send a copy of the POST request to a Zapier endpoint (with FormBuilder even easier) and then plug in a Mautic step that adds it as a contact.

@charger If you're looking at the JS in Chrome inspector, you'll see , le = new ue("https://architekturfuehrer.koeln/api/v".concat(ae.API_VERSION, "/"),{ objects: { path: "objects" }, object: { path: "objects/{identifier}" }, taxonomies: { path: "taxonomies" }, walks: { path: "walks" }, pages: { path: "pages" } }) , he = new ue("https://architekturfuehrer.koeln/",{ magazin: { path: "magazine/results.json" } }); These are simply JSON that store all the necessary infos, e.g. https://architekturfuehrer.koeln/api/v1/objects See the OP under "Backend", 1st paragraph.

@schwarzdesign I’m sorry, but I think I wasn’t specific enough. How does your router.js look like? ? As you say the routing is handled by Vue. However, I wonder how Vue knows about the routes that exist. Do you manually add the routes to router.js? Or do you grab existing routes via API and then include them in the Vue router config?

I just published another update that makes full use of the Add to Home Screen functionality in Chrome (though the app is installable in Android Chrome, Android Firefox, iOS Safari and regular Chrome). In particular, there's a new page that explains how to install the PWA on different devices, with a button that triggers the system dialogue for installing the PWA on supported browsers (only Chrome at the moment). This was a bit difficult to implement since there's little common ground between browsers in this regard at the moment, so let me know if you find any bugs or other errors! @charger ProcessWire only handles specific paths, everything else is routed to the frontend app and handled by the router. A normal ProcessWire installation uses the .htaccess rules to redirect all requests to it's index.php file. Meanwhile, the Vue SPA uses one single index.html as it's entry point and performs all further routing inside the visitor's browser. Since I want most visitors and paths to go to the frontend app, I modified the .htaccess file ProcessWire comes with to only forward specific routes to ProcessWire, and route all other requests to the Vue app: # .htaccess # Requests to the root domain without a path should go to the Vue app (index.html) instead of ProcessWire (index.php) DirectoryIndex index.html index.php index.htm # This additional RewriteCond comes right before the main RewriteRule from ProcessWire # It lets ProcessWire handle only calls to specific paths (in this case, the admin url (/cms), the API endpoint and the sitemap which is generated server-side) RewriteCond %{REQUEST_URI} (^|/)(api|cms|sitemap) RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # Everything else is routed to index.html, so the Vue app will receive the request and the vue-router can show the appropriate page # Redirect index.html to / RewriteRule ^index\.html$ / [L,R=301] # Redirect everything else to the app FallbackResource /index.html

With ProcessWire you don't generally want to perform your own SQL queries. It's possible, but generally I'd consider that a bad practice. If your content is stored as ProcessWire objects (basically Pages), you should always use the Selector engine for that sort of stuff. Not only does this provide the benefits of a great API (such as $pages->find('template=mailbox, owner=[some_user_field=whatever_value]') or $pages->get('parent=some-parent, name=page-name')->setAndSave('field', 'value')), there's also zero chance of accidentally running into nasty SQL injection vulnerabilities. Of course you can always create custom database tables and perform queries on them using the $database API variable (which is essentially a wrapper for PHP's own PDO class), but in such cases the content won't be editable within ProcessWire's admin, so you're missing a pretty important benefit there. Another alternative would be using RockFinder, which kind of provides the best of both worlds: easy to use syntax for queries combined with the performance of raw SQL and lightweight PHP arrays/objects. So, long story short: if you want a nice GUI and an easy-to-use API for managing your content, ProcessWire is a great choice. If you ultimately just want to use your custom database tables, write a few SQL clauses to update a few rows here and there, and there's no need for a web based interface for managing said items – then perhaps you should just build it from scratch (or use something like Laravel instead).

v0.2.1 released. This is a fairly major update in that there has been quite a bit of refactoring. Please be alert for and report any issues. ProcessWire >= v3.0.0 is now required. This release adds a new hookable HannaCodeDialog::buildForm() method that lets you build the dialog form in the hook rather than setting inputfield options as pseudo-attributes in the Hanna Code tag settings. From the readme... Build entire dialog form in a hook You can hook after HannaCodeDialog::buildForm to add inputfields to the dialog form. You can define options for the inputfields when you add them. Using a hook like this can be useful if you prefer to configure inputfield type/options/descriptions/notes in your IDE rather than as extra attributes in the Hanna tag settings. It's also useful if you want to use inputfield settings such as showIf. When you add the inputfields you must set both the name and the id of the inputfield to match the attribute name. You only need to set an inputfield value in the hook if you want to force the value - otherwise the current values from the tag are automatically applied. To use this hook you only have to define the essential attributes (the "fields" for the tag) in the Hanna Code settings and then all the other inputfield settings can be set in the hook. Example buildForm() hook The Hanna Code attributes defined for tag "meal" (a default value is defined for "vegetables"): vegetables=Carrot meat cooking_style comments The hook code in /site/ready.php: $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // Other arguments if you need them /* @var Page $edited_page */ $edited_page = $event->arguments(1); // The page open in Page Edit $current_attributes = $event->arguments(2); // The current attribute values $default_attributes = $event->arguments(3); // The default attribute values // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; if($tag_name === 'meal') { $modules = $event->wire('modules'); /* @var InputfieldCheckboxes $f */ $f = $modules->InputfieldCheckboxes; $f->name = 'vegetables'; // Set name to match attribute $f->id = 'vegetables'; // Set id to match attribute $f->label = 'Vegetables'; $f->description = 'Please select some vegetables.'; $f->notes = "If you don't eat your vegetables you can't have any pudding."; $f->addOptions(['Carrot', 'Cabbage', 'Celery'], false); $form->add($f); /* @var InputfieldRadios $f */ $f = $modules->InputfieldRadios; $f->name = 'meat'; $f->id = 'meat'; $f->label = 'Meat'; $f->addOptions(['Pork', 'Beef', 'Chicken', 'Lamb'], false); $form->add($f); /* @var InputfieldSelect $f */ $f = $modules->InputfieldSelect; $f->name = 'cooking_style'; $f->id = 'cooking_style'; $f->label = 'How would you like it cooked?'; $f->addOptions(['Fried', 'Boiled', 'Baked'], false); $form->add($f); /* @var InputfieldText $f */ $f = $modules->InputfieldText; $f->name = 'comments'; $f->id = 'comments'; $f->label = 'Comments for the chef'; $f->showIf = 'cooking_style=Fried'; $form->add($f); } });

I dont think I have it down yet. I really think a page builder needs to live update while you change fields to be competitive with things like DIVI and Beaverbuilder and Elementor. This is what I am working on with vue. I am just looping through all fields attached to the page and making vue form fields that have 2 way databinding. So when you type new text in, it changes as you type. Or if you hit center text, it centers it instantly. I am using the REST API plugin to push the page data back to the database when you hit save. I plan on releasing the site profile to the community when I am done. It should be better than the above wordpress solutions as they are very hack solutions. You can not, for example, add any element inside a tab module or an accordian. You can only type manual code into their rich text. With mine, I can add a grid with columns or really anything inside anything.

I realised that after I posted. Unfortunately, I can't seem to delete posts .... so sorry about that Amigo