Leaderboard

I get paid by the hours so... oh wait. ? Good to hear it worked for you! ?

@bernhard Do you sleep sometimes?

+1 I did something similar recently, which was surely easier than learning a system I was not really interested in. My trick was to inject the "old record ids" of the old system into its markup (so I only had to understand a little bit its templating), afterwards complete page contents were grabbed and were saved into PW's CKEditor fields and from then on I performed some careful planning and PW template/field works – based on the required relations – and lastly I used php-html-parser to turn the static CKEditor field markups into relations.

It seems that the website is very simple in its structure: lists/details structure.. maybe even with the ProcessBlog module and using categories you can make the whole site. If I had to do it, I would do the following process without having to study another platform or make new code: - I would use a scrapper software on the current site and export the data to a csv file with the fields and names I want. - I would create the templates in PW for the parent listing page / child detail page for each data model or use only one for all with tags/categories, depend on your idea - I would use the ImportPagesCSV module to create all pages in only one step All this you can do without having the html+css design implemented. I think that having the idea of fields and templates, this would not take me more than 4 hours of work. If you don't have access to a scrapper software, there are some extensions for chrome that can help you, or you can make a small code and use https://github.com/paquettg/php-html-parser. The idea with this is to avoid understanding CodeIgniter or the database. I have done this before for marketing affiliate pages = 100% Guaranteed ?

Is your include file namespaced? If not, throw new \ProcessWire\PageNotFoundException(); should do the trick. Or adding "namespace ProcessWire;" at the top, obviously.

Carefully and well planed. Parts of it could be migrated via API I guess and some parts need to changed manually. It all depends on several details we don't know, yet. Based on the details you provided... somewhere between a few days and a year. Plus the design part. How much books, movies, events, etc. need to be migrated? How many templates are needed? How ... ? What ... ? Who ... ? Hard to say actually. We don't know anything about the site, the data, the functionality. You should at least understand whats happening in the code itself. As you you didn't mention any eCommerce stuff or bookmarking or recommendation features there seems to be not that much of functionality in the code and therefore I guess it will be only be common template logic and maybe some data management. The hardest part will possibly be the content and data migration. As soon as those are in ProcessWire it should be a piece of cake.

How about this: <?php $p = $pages->findOne(1241); if ($p->id) : ?> <a href="<?php echo $p->url() ?>"><?php echo $p->title() ?></a> <?php endif; ?> Perhaps it's only a minor optimization, but it saves it returning any page object if the page isn't published. Be sure to read the docs on findOne() vs get() to understand fully, but basically find() and findOne() won't return unpublished pages unless to specifically request them to, but get() will ignore unpublished and hidden statuses and always return a page if everything else matches.

Now you can join any finder to any column of another finder. That's quite powerful but might also get complicated or slow... It's especially handy when you want to use RockFinder2 as datasource of a RockGrid, because RockGrid does not support the new concept of relations that where introduced to RockTabulator https://github.com/BernhardBaumrock/RockFinder2/commit/8c6b66ad3dda68de9c1008078420f13a034250bf

@bernhard's post gives you the clue - it's to do with PW's built-in caching. $page->children() is a method that queries the database. You want to minimise the number of requests to the database because going to the DB is a lot slower than working with objects in memory. In your code you call $page->children() five times, so the expectation is that this would mean five trips to the DB... except that PW tries to help you out and caches the results to avoid unnecessary DB queries. But the exact workings of this caching are undocumented (as far as I know) and so I'd say it's best practice not to rely on it. It would be better to consciously minimise the DB requests in your code - it would make things clearer (i.e. avoid the confusion you're getting from the behind-the-scenes caching) and it's a good habit to get into for when you're working with other PHP projects that might not cache DB query results like PW does. You could rewrite your code like this: $layout->setTemplate('sidebar'); $selector = [ 'template' => 'product', 'sort' => 'title', 'categories' => page('id'), 'limit' => 9 ]; // Just get the children from the DB once // I assume you need all the children at some point later in the code because you dump page()->children() in your example. // If you don't need all the children then just get the categories directly with page()->children('template=category') $children = page()->children(); // Get the categories from the children PageArray (happens in memory) $categories = $children->find('template=category'); // If there are any categories then modify $selector if($categories->count) { $categories->add(page()); $selector['categories'] = $categories; } bd($children); bd($categories); And this might be getting into the zone of micro-optimisation but you could consider if you actually need full Page objects in a PageArray or if you only need the IDs (reduces the memory footprint): $category_ids = page()->children('template=category', ['findIDs' => 1]);; if(count($category_ids)) { $category_ids[] = page()->id; $selector['categories'] = $category_ids; }

Currently I stick to 3.0.138, looks like that is the last DEV version safe to update to.

Thank you, Adrian, now everything works as expected, also in fields of type TextAreas!

d($page->children()->count); // 7 $foo = $pages->get(1); $page->children()->add($foo); d($page->children()->count); // 8 d($page->children('id>2000')->count); // 3 $page->children('id>2000')->add($foo); d($page->children('id>2000')->count); // 4 $pages->uncacheAll(); d($page->children('id>2000')->count); // 3

I've been working with CodeIgniter for over 10 years, and although the general framework structure is predictable and documented, the custom code and database layout that has been developed with it could be... anything! You don't really have to learn it, but being aware of how it works might be useful in extracting the bits you need. I think these two documentation pages will be most helpful at this stage: https://codeigniter.com/user_guide/overview/appflow.html https://codeigniter.com/user_guide/overview/mvc.html As a rough guide, the URL patterns (/foo/bar) of a CodeIgniter app usually map directly to controllers. These should be in the application/controllers directory, and each file in here is a class. The example URL route of /foo/bar would call the bar() function in the Foo.php controller. Within the controller, it should (might!) call some 'models' - responsible for database interaction - and pass the result data into the 'views'. The views are responsible for transforming the data and results into HTML code that is sent to the browser, so this is likely where the main page layout should be, along with the different code for producing the different lists and detail pages. These live in the application/views folder. By default, there's no templating language or library used (like Twig) - the views are just mixed HTML and PHP, like ProcessWire, so should hopefuly be easy enough to follow. In terms of the database, you will need to look at how the current one is set up. With any luck, you could probably map each database table (books, movies, events) into PW templates of the same name, and set up PW fields that correspond to the columns in the database tables. After that, you would need to address any relationships or links between the tables or records, and decide on which PW structure will be best. For example, parent/child pages, Page reference fields, or creating a tagging/categories setup. If there's any budget for the project, I have some time over the coming weeks and would be happy to help you in the right direction if you think it would be useful ? Craig.

Ok - good call on the namespacing. Can confirm the following combo of using wire404Exception() instead of PageNotFoundException() and namespacing works as follow: throw new \ProcessWire\wire404Exception(); Thanks @wbmnfktr and @BitPoet - got there in there end!

The same error is being discussed in this thread where throwing a 404 exception in an include file throws an exception (well, a different one). In that thread it seems that there are different scenarios that can trigger this. What I'd suggest right now is to install the Tracy module if you haven't yet to give you a better look at what's happening.

The 3.0.140 brought some issues with 3rd party modules and I try to avoid the DEV version at the moment for that reason. Therefore this was just a guess but maybe the DEV version also affects core features like this. Try the latest Master (3.0.123) if possible. If that's the fix we have found the suspect. By now your code snippet seems fine to me - at least the modified (other if statements and Wire404Exception) version works as expected here.

So... I just played with it a bit. Does NOT work: throw new PageNotFoundException(); Does Work: throw new Wire404Exception(); Tested it on a ProcessWire 3.0.133 installation. Are you maybe running the DEV 3.0.140 version?

Sorry for keeping you in suspense... but crazily I can confirm this works! Thanks for your help ?

Hi @xportde - sorry about that. I have reverted those changes and taken a different approach to what I was trying to fix. FieldsetPage fields now work as expected, but there is still a problem with the individual fields under a textareas field, but I don't think that is related to the version of this module - I just don't think the Textareas module supports setting "entityEncodeText" to false, which is how this module allows html in the description. If I am correct in this assumption, then it is something Ryan will need to fix. Let me know your thoughts.

$page->closest() might be the slightly better option (or might not): https://processwire.com/api/ref/page/closest/

Couldn't you use this, assuming all offices, eg HUMAN RESOURCES have a template names "office" $page->parents('template=office'); Actually you might want "parent" instead of "parents" to make it easier in this case.

In the last few weeks... or almost months... I worked on a project for a restaurant. Sad to say that the company behind the restaurant went out of business before the project could be finished - or was paid or the website ever saw the light of day. As there is kind of a lot of work in it... but yet a lot of customization... I decided to create a site profile of it and make it public as ProcessWire Barebone Site Profile. Right now I'm stripping out every client detail and finish some functions and details that were planned a few weeks back so you can build right on top of it, if you like or want. Maybe it's only a playground for someone or an inspiration for how to f**k up data-mangement... but hey... better than a ZIP file on a backup drive. ? As the project was and is super tailor-made to that client, it may not work for a lot of restaurants out there, but nonetheless I don't want miss the opportunity to offer a foundation for upcoming restaurant projects you may face. The project had a huge focus on dishes, beer and wine variations so those templates are kind of feature-rich. You might want to rip out some of it as most restaurants don't focus that much on those details. Important details I want to be honest and clear about: this profile does NOT include a highly polished and usable frontend as the design is paid and therefore can't be made public the frontend will be a collection of re-usable snippets to show every possible detail of each page, item and whatever the whole site profile will be without any support - future updates aren't planned right now the site profile will be released in single-language setup only (english) existing translations (as seen in parts of the screenshots) will be changed to english existing data, for example dishes, will be replaced with demo content if you, one of your clients or anyone else wants to use this profile - feel free to do so Pro Modules were already stripped out of it only public modules were used and are included with the profile itself the full module list will soon be published on Github the full README will soon be published on Github the full LICENSE will soon be published on Github So... yes... that's just a short preview of an upcoming site profile. As mentioned before, the site profile will most likely never ever receive any future updates, so it will be available on Github only. It's not planned to publish this as a full featured site profile, yet. More details, screenshots and the site profile itself (of course) will be available soon. Questions? Please feel free to ask. Github Repository: https://github.com/webmanufaktur/pwbrestaurant

Try adding the classes in alphabetical order. { name: 'Left Aligned Photo', element: 'img', attributes: { 'class': 'float-md-left img-fluid' } }, { name: 'Right Aligned Photo', element: 'img', attributes: { 'class': 'float-md-right img-fluid' } }, { name: 'Centered Photo', element: 'img', attributes: { 'class': 'img-fluid w-100' } },

One of my client's website is running on Nginx : https://ricardo-vargas.com It works, but I think a better approach in most cases is to run Nginx as a reversed proxy with Apache serving the files, like I did for my other client: https://www.brightline.org. You get the benefits of easier configuration and a better performance (compared to only run Apache).

Hello, Nice! If I have the choice I prefer to use a program like FileZilla for (S)FTP. I still have to try FreeFileSync (that I'm using for computer backups) for (S)FTP synchronization, but it seems easier to set up (and use) for Windows or Mac OS X than for Linux. You could perhaps at least lower your folders' permissions to 755 (instead of 775, like it's the case for assets/ and templates/). Perhaps quickly check your (sub-)folders' and ("sub-")files' permissions (even outside site/). Have a nice weekend!

Hi, 755 for folders and 644 for files (with FileZilla, for example, you can easily do it - recursively). But you can/could lower the permissions for some files like site/config.php, .htaccess, index.php, ready.php, etc., depending on your hosting environment, as long as it works. See also https://processwire.com/docs/security/file-permissions/ Perhaps you should empty your site/assets/cache/ folder. You can also look at the results in Google for the following request: site:processwire.com/talk 'failed to open stream: Permission denied' warning Edit: verify the site/assets/ folder permissions as well as the permissions of all its (sub-)folders and ("sub-")files. (Perhaps, also try refreshing the modules cache.)

Well, the admin is built for that purpose to add and edit pages. Every user that has a login is able to see the admin, even if he can't edit anything and if he knows the url. Although you could add hooks to check for roles to redirect out of the admin in case. I didn't say use the module but look at it how it's done, it's also done using API (as everything in PW), so you would need that same codes anyway. I don't see any problems doing your own frontend forms based on a templates fields. But depending on the fields you need, it's not as easy as simply rendering the fields with a form wrapper and you're done (for the reasons mentioned). Jquery UI, inputfields css and scripts and the $config->js would also be needed for them, and some of them would be in the $config->scripts, $config->styles when you render fields on a page. I've never tried to rebuild the backend for the frontend, and always try to use some shortcut link on the pages for them to edit or create pages using a simple link with url to the right admin screen. If I combine that with &modal=1 and fancybox modal they don't even need to go to the backend. <a class="fancybox" href="/processwire/page/edit/?id=1123&modal=1">edit page</a> <a class="fancybox" href="/processwire/page/add/?parent_id=1022&modal=1">add page</a> That's in cases sufficient to give a simple frontend editing capability with 2-3 lines of code.