Macrura

Not that I know of; But this forum has heaps of code examples. Writing an export script would assume a decent knowledge of the PW API, and a certain basic level of PHP. If you are willing to invest some money, then you could simply purchase ListerPro, and then use the ListerPro Page Action: Export pages to CSV file "This action enables you to export all pages matching your ListerPro query to a CSV/spreadsheet compatible file."

i already replied to that question

Correct, ProFields Page Table is the one that comes for free with PW. Profields Table is not the same thing.

That's for ProFields Table, but the OP appears to have this info stored in a Page Table. As far as I'm aware there is no way to export the data in a Page Table without writing a custom script.

I noticed that there is an option to "Open Home/View site in new tab (topnav)", and i have that checked. But when i select the menu item called "View Site" in the top nav, it doesn't open in a new window. So i wanted to report that as a possible bug. This is on UIKit admin theme. Also it would be cool if we could have an option for view links on the page list open in a new tab, if that isn't already an option somewhere that i missed...

The usual way that I would do it is to create a service URL* on the 2nd website, which returns JSON to the ajax request, if you're going to load the comment markup and form via ajax. Alternately you could use an iframe, so the 2nd website would have an output template to render the comments thread and form; this could be a single template/page with get params; I don't see any benefit or reason to use multi-site / multi-instance (but maybe i'm missing something), unless it makes managing comments for an article easier; but you could also create a field in the comments site that pulls in the title or other info from the main install, using a service page on the main install, returning JSON response; In terms of the service "page" or URL - there are some new api features that will allow you to have a service URL without having to actually create a page as an endpoint. https://processwire.com/blog/posts/pw-3.0.173/

I think it's a good idea and plan – plus if your main site is cached with something like procache, you could load user comments via ajax from the subdomain "user" site. I'd probably do it the same way as you; It's sort of like making your own version of a commenting platform which is integrated into the site, like Disqus or something. And if eventually at some point you had a huge user base, you could run the entire subdomain on a different server.

There should be examples of fieldsets defined in the samples folder, but using PHP. I don't think you can do fieldsets fro JSON defined settings, but the tabs fieldsets example shows "Advanced Settings" which are each in a fieldset.

@gebeer My assumption is that most people use URL fields to store external URLs. So we don't have any way of preventing these external sites from using commas or encoded commas in their URLs; If the URL field is supposed to store this external URL, then it should not modify the URL because then the link to that external site won't work, so the field is kind of useless at that point. The only reason i can think of for sanitizing that %2c would be for security of the database; but in that case there should be some way of reconstructing the original URL so that it doesn't result in a 404 to the original URL.

thanks @Robin S for going deep on this; yeah, i'll have to head over to GH and inquire...

you must have some bug or other issue; $page->getUnformatted('date_field'); always returns a unix timestamp. All datetime fields are stored in the DB as datetime which is not unix timestamp (it is Y-m-d H:i:s), but that database value is converted to the unix timestamp for the unformatted value of a datetime field; You can see this in the sleepValue and wakeupValue for the fieldtype, which converts it like this: return is_int($value) ? date('Y-m-d H:i:s', $value) : '';

This is a strange issue, there is a URL that has an encoded comma in it (%2c) and if you paste this URL into a URL field (standard field, or a URL field within a profields Table), that is converted to a comma. The issue is that the URL no longer works, so you can't use something like the AOS URL checker, and on the output of the URL, it won't work. I had to do a string replace of the comma back to the %2c to make the links on the front end work; But seems like a hack, and wondering what the issue is and if there is a standard way to handle it. The URL in question is this: https://www.carlfischer.com/o4361-masters+of+our+day%2c+volume+i.html

I found the easiest way to get the styling for selectize was to remove the uk-input class. $('.AdminThemeUikit #Inputfield_tags').removeClass('uk-input'); Also, as an update, the new tags functionality for fields & templates does indeed conflict with the module – the result is a JS error which prevents any editing of templates or fields. Anyone using the "Selectize Template and Field Tags" and using the latest dev version, will need to uninstall that module for now, to prevent this error. I don't see any setting to disable the core text tags inputfield on the tags inputfield, on templates & fields. The only thing i can think of is to somehow destroy the selectize instance that the core is creating, and then the module can do it's usual init; But for now I haven't been able to figure out how to get that selectize instance to destroy it. Edit: In case anyone is reading this, i just pushed a temporary fix to the module which should prevent the JS errors and the consequent inability to edit templates or fields.

I'm happy that Selectize.js is getting used more in the core. I should add that we've had the ability to use Selectize.js for page references (multi & single), image tags, and template & field tags since 2016. https://processwire.com/modules/inputfield-selectize/ https://processwire.com/modules/selectize-image-tags/ https://processwire.com/modules/selectize-template-field-tags/ Also if using the module for template & field tags, it tracks all of the tags in the system and provides a selectable list. And it has the option to selectize the icons as well, making it easy to search for icons for any field or template by entering the name of the icon. I've been extensively using all of these modules on all sites. And the inputfield has the additional benefit of allowing custom content for the selectable options as well as the selected options (separately configurable), meaning you can display various fields, icons, or even images on the selectable options. As Selectize.js has been more and more integrated with the core (for example with image tags), the modules have adapted. The Page Inputfields (single, multi) use the core selectize which has the benefit of being customized to work better with the admin. I'll have to see how the module interacts with the the template & field tagging. I think the best option is to allow admins to enable or disable the core init of the template & field tags, so that the module version can continue working, but I haven't tested the latest dev so don't know if it is an option.

Thanks @bernhard & @adrian for the alternatives. I actually use ACF on a lot of sites as part of my standard setup; I think this subdomain thing on MacOS can be solved. I'll give AOS loading a try on a setup and see how it compares to ACF...

Hi Martijn, That's great to hear! Sorry for bringing up this old module, but thanks for the reply. I'll see if i can dig into the code and make it work...

Not sure why this is happening, but I can't use the latest version on Mac OS, local development (i can only use the 0.8.7). The module doesn't seem to understand the paths - i can't actually add dependencies, even though I know i'm adding the correct path, i even copied all of the dependency files into the ACF folder and it still report that it can't find the file and it won't add the dependency. Relative to ACF folder also can't use something like ./ to get to templates. If i put in the root relative path, the module outputs the wrong url to the file, it puts the subdomain twice. here is an example, on localhost, the root URL is http://localhost:8888/ and the subdomain is processwire_test1 the root relative url is presumably "/processwire_test1/site/templates/libraries/path-to-some-file.js" but the module outputs this: processwire_test1/processwire_test1/site/templates/libraries/path-to-some-file.js

I don't think "$file->url" is correct. You need to put in the complete server path to the file. you need to use this instead: $file->filename() https://processwire.com/api/ref/pagefile/filename/

The TextformatterSoundmanager https://processwire.com/modules/textformatter-soundmanager/ works well for embedding audio files, but uses shortcodes. This module is a good choice for simple things where you wouldn't need a playlist or control the skin etc, like you can do with SM2 module. You could also skin the audio element using something like plyr.io, which is a nice replacement for the default player. MediaElement.js also works in a similar way. I can see using this module for quick and simple applications though.

Just chiming in - I don't have a solution in terms of why the sessions are not clearing when you visit the Setup -> Sessions, but for me, going to Setup -> Sessions does clear the old sessions. The first time I realized this was an issue was seeing the number of records in the sessions table; once i cleared those, the database shed something like 50-100MB. I also read some of the other solution (involving the ini_set) and this didn't work - it seemed to make the site basically tank, and run really slow. ... and i guess my point was that this sessions not clearing in the DB is still an open issue, at this time..

This should do it.

@cstevensjr, this started on Wednesday of this week when Dreamhost made some bizarre unilateral ModSecurity setting that broke every ProcessWire site's ability to upload images or files. You have to open a support ticket and tell them to change the ModSec setting for every domain on your account to allow the CMS to work. They should be able to check their logs and know what to change, but you also might have to go back and forth with them and test it. I exchanged probably 10 emails with them on Wednesday while they repeatedly tweaked the ruleset until i was able to upload again. Last night i had to send them a list of ~20 sites that they had to adjust the ruleset for and they replied today that it is now done, but only time will tell if I start to receive complaints from site owners that they can't upload. This is certainly disappointing behavior from Dreamhost, and they should make amends. Hopefully they are going to learn a hard lesson once they get an avalanche of support complaints about this. By the way, you can easily tell what the problem is, if you upload while viewing the network panel. You'll see probably a 418 error and when you view the response you'll see Internal Server Error. 418 is the DH response for anything related to ModSec. In addition you can go into the server logs and open the log file (which may be pretty huge by now) and see the mod sec errors.

cool idea

Cool, thanks for the fast fix!

these are errors in the vendor library, which is PW core, so nothing i can do to fix it; Only possibility is that your JS in the field settings has an error. I'm not getting any console errors with any pages running selectize inputfields, or any image fields using tags (which also use the PW core selectize.js).