Leaderboard

Hi @fruid, I understand your concerns. The db structure can look quite complex, especially if you are used to working with db tables and SQL select ... from ... etc; Teppo explained the reason for this structure. The great thing about this structure is that you get an abstraction layer that makes all the PW awesomeness possible. It transforms all the custom fields and data in the database into PHP page objects that can be used for easy and effortless markup generation. I'm talking about the great pw api ? echo $page->title; echo $page->headline; echo $page->image->size(200,200)->url; Display all that in multiple languages? Same code ? I think that's really genius! Are there downsides of this approach? Yes, as always. For example it is not easy for PW to do a "SELECT * FROM table_xy" to get a list of thousands of rows of data. That's because the magic of transforming the complex db structure into an easy to understand and use API has some costs. It needs to load all rows of data into memory and therefore this get's slow when working with lots of data. PW handles this by applying pagination wherever possible, so that it only loads chunks of data and stays fast. But still there might be situations where you simply need a good old "SELECT * FROM ..." and "foreach($pages as $page) $rows[] = [$page->title, $page->headline, ...]" is no option. That was quite a long introduction and explanation why I built RockFinder3 ? So at least the PULL part of your request is already doable ? What about the PUSH part (meaning updating data in the DB, doing "UPDATE ... , INSERT INTO ...")? First, you can still use native SQL commands on PW, it's quite easy: $result = $this->database->query("SELECT * FROM pages LIMIT 5"); var_dump($result->fetchAll(\PDO::FETCH_OBJ)); The problem is, that updating data can get quite complex because you need to update several tables, several fields, several languages... That's why such operations should really be done via API. That's of course a totally different approach if you are used to working with SQL commands, but it is the best option in 99,5% of the cases. There's a topic about that where I showed my findings: For the remaining 0,5%: You see, it can be quite easy. Is it a good idea? 99,5% no, because you don't get all the security features of PW that ensure that data is sanitized before storage etc. And you don't get the power of hooks. Updating pages via API will still trigger saveReady() and saved() hooks while direct SQL updates will not. Hope that helps ?

[SOLVED] found a fix myself I followed: https://medium.com/@ajtech.mubasheer/setup-https-in-xampp-for-localhost-bc3d01393f31 to allow https as localhost for my xampp setup and I can now do api calls to https:// ?

What do you guys think of changing that to Vertikal spiegeln Horizontal spiegeln Beides spiegeln 90° drehen (rechts) 90° drehen (links) 180° drehen S&W Sepia Actually I don't understand why we have the options for 270° rotation at all? -270 = +90, so why does it show up??

One more addition to this: The API is, in fact, one of the biggest advantages of ProcessWire. While the preferred term is "content management framework", one may as well think of it as an ORM of sorts. ProcessWire was never designed for direct database access, and that's the whole point: it's meant to (mostly) abstract the database layer away so that both developers and content editors can (as much as possible) avoid the complexities and inherent risks of dealing with SQL queries. I must say that I don't agree at all with your point about ProcessWire's advantages taking a backseat once the website is finished. I get where you're coming with this, but I'd assume that we can both still agree that it's extremely rare for a client to actually prefer SQL over a GUI — let alone them being competent and meticulous enough to produce data that fulfils all expectations we as developers might have. Obviously we come from different backgrounds and thus have different expectations. If I would've suggested to any of the clients I've ever worked with a platform that requires them to use SQL, that would've been a disaster ?

@fruid I don't really understand your use-case. You say your client is going to use SQL to update the database, does that mean they are going to write raw SQL queries in front of a terminal? That seems like a really inefficient way to go about content creation, especially since you have to make sure your data fits within the constraints defined in the template and field settings. Despite that, you can still do that, you just have to add a couple of JOINs and be careful with your WHERE clauses. Each field table comes with a foreign key corresponding to the page ID. If your client is really some kind of SQL wizard who prefers the power of raw SQL for data migration over the limited interfaces puny mortals have to use, what's stopping them? Or do you mean "the client is going to log into phpMyAdmin / Adminer / MySQL Workbench / ... and insert data through that interface"? In that case, you're not really using SQL anyway, you're just using an interface that's closer to the database, that *may* be slightly more efficient to use for batch creation / updates if you really know what you're doing. If that's what your client wants – well, that's an interface you can build for them! Something like a batch update module that lists pages and allows you to edit them inline. In fact, such a module exists already: Lister Pro comes with inline editing for multiple fields at once. This gives you a convenient interface to update many pages at once and still stay within one backend and have all the input / constraint validation apply to your edits. Best of both worlds ? By the way, if you've ever tried to manually find something in a Drupal 8 database, you will like ProcessWire's database structure MUCH more ...

Each field may belong to more than one template, and each template has a different set of fields. Current structure works well with that concept, makes it possible to connect (or disconnect) fields with/from templates with ease, makes it unlikely for a single table to grow to giant proportions (thus making all queries against it slower), and also allows fetching/searching/saving the exact data that ProcessWire needs to fulfil a specific request. So yes — there are advantages to current structure. It's also a very fundamental part of ProcessWire, so changing it is not possible without major changes to the core ? It has been. If you'd like to read a bit more on it, I'd suggest doing a google search for something like "processwire database structure". You'll find a lot of existing content on this topic ? Your point of view is not unheard of for newcomers but trust me, there are valid reasons why the database architecture is what it is. Much of it is due to the fact that ProcessWire — unlike some competing platforms, I might add — was designed with custom data structures (custom fields) in mind from the ground-up. Some other systems (WordPress, for one) have a much simpler database structure, but that's because they weren't originally intended for the same kind of use as ProcessWire. In the context of ProcessWire this would be a bad idea: First of all the Admin is a ready-to-use tool for managing content, and I highly doubt that anyone will really have easier time managing the content with raw SQL. It can be fun and/or if you've had to do that a lot in the past you may be used to it, but still: ask them to give the Admin a try and I bet that this idea will go away in no time. If you manually update the rows in the database, most of what ProcessWire's fields do will be completely skipped. This includes validation, filtering, and sanitization; things that are there to help you build sites with valid and well formed data. Without these features you will run into trouble eventually, it's just a matter of time. ProcessWire does internal cleanups and such using hooks, and those will not get triggered if you update the data manually in the database. This means that you'll likely be left with broken data, missing pieces here and there, and so on. Some fields (take Repeaters for an example) will also be very difficult to update manually via database. Finally, while we're on the topic of hooks: they are a major feature in ProcessWire, used by both core and third party (module) code — and, once you get used to it, probably your own code as well — and again if you don't go through the "official channels" (API or Admin) you'll loose this benefit altogether.

It would be fantastic if we could set different configurations for CKEditor fields based on template or user roles. Like described on https://weekly.pw/issue/14/ under "More CKEditor upgrades", we can use config files in /site/modules/InputfieldCKEditor/ to store settings per field. E.g. for the body field this would be /site/modules/InputfieldCKEditor/config-body.js. Maybe this logic could be extended to something like /site/modules/InputfieldCKEditor/config--field-body--template-home--role-mycustomrole.js. I was coming over from Joomla to PW couple of years ago and there we had an excellent CKEditor integration called JCE where you could define settings per user role etc. Maybe I am wrong but up to now we need to create additional fields if we need editor config settings per template. If there already is a way to do that I'd be happy to know.

The ecumenical city pilgrim trail in Villingen, Germany is a small trail through the city where you can visit churches and other places of interest. This Progressive Web App is a small website to guide visitors through these places and give additional informations. You can install it on your smartphone or tablet and walk the trail with it. app.stadtpilgerweg-villingen.de Features: Interactive Map Progressive Web App Interactive Map Before entering the map you get a little tutorial where you can choose between two routes, the standard trail or a more accessible trail. You can track your position on the map and click on the markers. Each marker is a view with additional information to the place. The views can contain texts, quotes, images or a chat element. The map was realized with Leaflet and styled with Mapbox. Progressive Web App The website can be installed as Progressive Web App on your smartphone or tablet for a better experience. The PWA remembers the last visited view and has no unnecessary browser navigation. It can also partly work offline and caches almost everything. The PWA was realized with the help of Workbox. Modules used: Repeater Matrix ProCache Map Marker (Google Maps) Sitemap ProcessWire Upgrade TOTP two-factor authentification Tracy Debugger Regards, Andreas

Apart from working with ProcessWire, my other area of work is SQL databases, where I tend to have nearly all application logic contained in the database through views, stored procedures, user defined functions, triggers etc, so I understand how coming to ProcessWire can take some getting used to. If you simply want to import data from an existing system, then there's no problem to mix SQL queries in PHP and calls to the ProcessWire API to read data from an existing database using PHP's PDO or ODBC abstraction layers and then store fields to ProcessWire fields. I've done this myself before importing data from another system, and it's not overly difficult. Here's a bit of code I wrote a few years ago to import some data from another system into ProcessWire. Obviously the SQL will vary depending on what system you're importing from, and how you've named your ProcessWire fields will be different. This is old code, and untested, although I think it worked at the time. Having the Tracy Debugger module installed is a must have, as it provides a PHP console with code completion for the ProcessWire API, so that you can run ad-hoc bits of PHP code to do stuff like importing data without having to write a module or embed it in a template if it's just one off code that will only be run once. $webpressiondb = new PDO('mysql:host=127.0.0.1;dbname=mol_webpression', $user, $pass); $sql = "SELECT {$site}_docs.docid, {$site}_docs.parentid,custhead, subindex, title, keywords, author, {$site}_docs.modified, created, wbdesc, name, content, template, folder FROM {$site}_docs INNER JOIN {$site}_pages ON "; $sql .= " {$site}_docs.docid = {$site}_pages.docid ORDER BY {$site}_docs.subindex"; $wbdocs = $webpressiondb->query($sql)->fetchAll(); foreach ($wbdocs as $record) { //Need to allow for old records with no title. if (preg_match("/[a-zA-Z0-9]/i", $record['name'])) { print '<h1>' . $record['title'] . '</h1>'; $pwpage = new page(); $pwpage->parent = $pages->get($parent); $pwpage->template = $templates->get("rosina"); $pwpage->title = $record['name']; $pwpage->text3 = $record['title']; $pwpage->text1 = $record['wbdesc']; $pwpage->keywords = $record['keywords']; $pwpage->textHtml1 = $record['content']; $pwpage->wid = $record['docid']; $pwpage->wparent = $record['parentid']; $pwpage->worder = $record['subindex']; $pwpage->wcreated = $record['created']; $pwpage->wmodified = $record['modified']; $pwpage->custhead = $record['custhead']; $pwpage->save(); } } If you have cases where you really need traditional SQL tables with multiple fields in ProcessWire, you can create your own custom fieldtypes to do this, but you need to think carefully about whether you need this. The ProcessWire approach can be slow at bulk inserts, as each field results in a database INSERT statement, however retrieving data, especially if you don't need all fields is fast as it doesn't need to load fields in a query if you don't use them. If you're going to be doing a lot of multiple field inserts on an ongoing basis, and you're also going to want to retrieve most or all of the fields when you read the data, creating a custom fieldtype that's a traditional SQL table might give you performance advantage, but to date, I've generally found I've been able to work within ProcessWire's way of doing things.

$selector = "category=$category, name|text~%=$q, name^=$letter, sort=$getsort"; I must say that I'm a bit confused about all this so might've completely misunderstood your point, but just to clarify: "name" and "text" were table column names, not fields on the page? And you're passing this selector to $pages->find() or pages()->find()? If so, you would need to specify them as subfields: "table_field_name.name|table_field_name.text~%=$q, table_field_name.name^=$letter". The point is that now you're referring to the "name" and "text" fields of the page, not the "name" and "text" columns of a specific table field.

Hi Ivan, Yes, you're right and I'm doing it like this now but I'm looking for a way to add/remove fields without having to adapt the ready.php. The available fields will change occasionally. Thanks! Added: If one chooses to not access-control the toggles, adrians great RestrictTabView module is an option.

This should be possible to do with a hook. Look here for inspiration. Or just search for something like "hook admin inputfield show" (preferably, in Google)

This is not the whole picture. Simple fields might only have a single `data` column, but complex ones might have many more. Also multi-language support does work by adding `data_{lang}` columns to those field tables. Though I can see the argument for having template (or more correctly fieldgroup) based tables, where columns of fields would be merged into an single table.

Please explain, what is unusual? You have a data that is structured in an unusual manner or you think ProcessWire's database structure is unusual? If the latter, then many here will beg to differ ? Do you mean a page or module where you can view a page's data in this manner? Like in a spreadsheet? Or, do you mean a database that resembles a spreadsheet in its structure? If the latter, that's akin to a flat file database. ProcessWire uses a relational database. This model is not unusual at all :-). I don't understand this bit. What is the dilemna?