fruid

I agree it's rare, and yet it's still the case. I don't know much SQL, am also not in charge of the database and the client IMO shouldn't have to learn the PW-API, as cool as it clearly is. yes indeed that's what they used to do before PW. That sounds like re-building huge parts of the site and I thought I'm almost done. What I wanted was for all fields to show more relation to other fields on the same page. Field-groups so to speak, as mentioned by @LostKobrakai Just as an example (and possibly another issue). I have a field on a template that always has a value (default-value). I have 19 pages with that template, yet only 14 rows in the field-table in the database. While I don't know why it wouldn't enter the value for 5 of those pages – like I said, different issue – I had a hard time figuring out which pages those are. What I did is to write: echo $page->id; on the allways included _main.php to see which id the page I'm looking at has. Then open all the pages manually and see which page-id is not in the said column. I'm sure there's a more pro-approach to that conclusion using the API, but for someone who doesn't use it at all, it remains a hassle. In any case, thanks @bernhard and @MoritzLost for your suggestions RockFinder3 and ListerPro respectively. I guess one of them (I reckon the latter) will be the solution and will have to replace the direct SQL-commands in the end. Appreciate all your input.

$selector = "books.category=$category, limit=24"; $books = $pages->find($selector); tried that now but it also doesn't work. I kept it simple here but I'm getting just one result: echo count($books); // returns 1 and the markup is empty. My guess is it's now counting the columns with that name, not the cells within it? (and that's without even addressing the mentioned pipe-problem.)

in my last post here I said fields, my bad, what I meant is column names inside a ProField table. I use $matches = $page->books("limit=24, $selector"); books being the name of the ProFields Table on this very page. The thing is, it works as long as I don't use a search term, so it looks to me as if passing the selector to the array works fine, except for where I use the pipe. The mentioned category=$category inside the selector is also referring to a column name inside the ProFields Table and I have no issue there. Either column_name~%=$q column_text~%=$q also return results but neither column_name|column_text~%=$q column_text|column_name~%=$q do. Thanks for help

I now renamed the two fields name and text to something more specific but still no success. See attached what I mean by "select*", it's an option field. But there's no issue with that field, just with the two text fields mentioned and the pipe.

Exactly, I get no results, not for the left nor for the right part of the pipe. column "name" of type is "Tiny Text (up to 255 chars)" column "text" is of type "Text" and column "category" is of type "Select*" The rest are no fields or columns, just additional filters passed to the server via HTML-form with get-method. Thanks for looking into this

I did some more investigation and updated the PW-version to ProcessWire 3.0.164 so that I can use the operator ~%= Now it seems to work. However, the issue persists with another page where I use ProFields-Table. $selector = "category=$category, name|text~%=$q, name^=$letter, sort=$getsort"; All the other selectors seem to work fine and search a specific column in the table but as soon as I use pipe it just wouldn't.

Then I'm afraid I might be among the said 0.5%. While I have learned the PW-API and built the entire website, the data-handling and migration of an existing old joomla-database and its maintenance was planned to be done by the client via SQL, who would browse the tables and change a lot of data at once, all, hopefully, without the need to learn the PW-API. As much as PW shows clear advantages for the developer in terms of building the website, these advantages pretty much take a backseat once the website is finished and goes live, isn't it?

please excuse my ignorance, I learned something today, will look into that. I was just wondering if for example there's any advantage in regards to the database complexity, either in using the same field on different templates or in creating a new field of the same type for each template. thanks!

I think the pipe-selector should work as OR-operator but it doesn't. It only selects the option before the pipe, not after it. if($q) { $selector = "template=article|blog_post|book, title|body|author*=$q, sort=$getsort, title^=$getletter, limit=25, has_parent!=2"; $matches = pages()->find($selector); } Any ideas?

I'm quite new to Processwire, and I struggle with the database structure. Each page has specific fields. To my understanding, most of the tables in the database, each corresponds to a field and each field is linked to another field on the same page by the page_id. That's all I can see when viewing the field: pages_id and data. It would of course come in very handy if you could view each page as a table instead, a column for each field and all the content in the cells next to one another. I doubt this issue hasn't been addressed before, it's unusual the way it is now. I now wonder if I mixed something up at the very beginning and if there's a way to change or work around this dilemma. My client is actually quite educated on databases and would enter the content rather via SQL than via PW-admin-backend. Thanks for help!

thanks! that did it

I had to update uikit to vesion 3.5.5. to get a certain functionality working. (set 'draggable:false' for carousel). I replaced the folders: wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/css/ wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/ It works as intended in the frontend, however the css in the admin-panel is now broken. any ideas?

@horst yes, that did it! All good now. Danke vielmals!

@horst Followed all your advice, deleted the .zip and .json files in those /assets/files/ folders, checked the "overwrite existing files" as suggested for the mentioned fields. Now I at least can upload the german language package to the default language entry. I deleted all the files within the secondary language (now called english). However, the frontend still /de/ in the URL for the english site and nothing for the default language german (which is fine). How to change that? The page contents and custom fields are mixed up as well (I might just swap that manually since it's not that big of a site). Thanks so far! EDIT: now I deleted the secondary language because I thought re-installing might fix the issue, also since english doesn't require any files to work. But now it doesn't work in the frontend, all links to default language.

getting closer to the issue I think… I renamed the default language to deutsch/german, deleted all the json files in there. But I can't upload the german .json files nor the complete .zip file to this language. I'm getting errors: Refused file wire …… .json because it is already on the file system and owned by a different field. I even deleted the other secondary language, first only the json strings in there, now the entire language package. Still can't upload. Thanks for help!