Leaderboard

I think I may have replicated this. (PW 3.0.200). My suspicion is that it's related to renaming the field to 'Body' (uppercase 'B') when the field 'body' (lowercase 'b') already exists. Processwire lets you name fields with upper and lowercase characters. Here's what I did on my dev system: Create a new field 'test_content'. (The field 'content' already exists). Add 'test_content' to a template and populated several pages with data. Check the db. The table field_test_content exists containing the data just added. Attempt to rename 'test_content' to 'Content' (note uppercase C). Receive error as shown below. Check db again. The table field_test_content is no longer there. It looks as if PW correctly checks for an existing field if the case matches, but goes ahead and deletes the table if not. Subsequently, whenever I try to edit a page with a template containing that field, I now receive the same error.

I did a little more digging too. It seems as part of the field rename process, the corresponding (old) table is temporarily renamed to tmp_field_yournewname, and then tries to rename this temp table to the correct new name: field_yournewname. This second part fails because the table already exists, so I believe this throws an Exception and you would expect the admin to re-render with an error notice. (Like it does with the normal duplicate field name error). However, since the underlying field's DB table has been renamed to its _tmp version, there's another exception, showing the error. At least I think that's what's happening. DB table names are lowercase by default ($config->dbLowercaseTables is true unless overridden), so 'Body' will try to create 'field_body'. @FireWire, you might find there's a tmp_field_body table in your DB, with all your content intact. Good to know there's a Github issue opened.

There was nothing special in the setup, it's a very similar setup to what I usually use on sites. Really appreciate you looking into it and running some tests! This is it. It was the uppercase B in Body that I accidentally put into Name instead of Label that conflicted with another field named body. Really appreciate @Robin S @wbmnfktr and @iank working to figure out what happened, I don't have the time to troubleshoot right now (deadlines!) and you really helped out. If I didn't find out what happened I would be kind of uneasy about the website. Ideally I think it would be best if field names were restricted to lowercase, but that would be a big breaking change at this point. Many situations could cause this: Text intended for the Label could mistakenly be put into Name and all data is lost for that field (my case) A developer may be familiar with this bug, but not know or have forgotten that a field already exists with a name that will conflict Accidentally mistyping with a capital letter where a lowercase letter would have shown the appropriate duplicate field name error I have opened a Github issue for this bug.

Ok... so I made the move and downgraded everything down to 3.0.165 Still no data loss. Which is fine for me, yet... nothing that help's you a bit. Is there something special in your setup?

Confirmed renaming the tmp field table to the original table name solved the issue. Many thanks for your work!

I tested in 3.0.217 and when trying to rename a field to the same name as an existing field PW gave an error notice, did not change the field name, and no data was lost. So maybe it was a strange glitch, or it was an issue that was fixed between 3.0.165 and 3.0.217.

Ryan has already responded to the Github issue and will merge the fix as soon as it can be confirmed. Passing along a PW API method call he shared that can fix this in case anyone that runs into this and wants to skip working in the DB directly.. $query->exec('RENAME TABLE tmp_field_body TO field_wvprofile_body'); Thanks @ryan!

@bernhardThanks for your reply. Video was this one Process looks like this. About 100 people get an E-Mail with Url to the PW booking page and a personalized random BookingID (40 random chars) which is not guessable. This part is out of my control and lets say historical grown. The people can check for about 10 events in 2024 and subscribe to one event using their personalized bookingID. Due to data protection concerns, I am not allowed to store any personal data like E-Mail, Name etc. online. Not in PW, nor in textfiles on the server. Thats the constraints I have to fulfill. Hence I wrote a script, which creates 100 booking pages (one per person) which holds the unique bookingID and stores the subscribed eventID and last access time when the form is submitted. Every week a CSV file is created by PW which gets imported into a master Excel spreadsheet (historical grown) to check who subscribed for what event. Thats why I can‘t hide the booking form behind a PW login form per user and hence want to make the form more robust against spam bots and script kids attacks. If I would be free, I would create a different solution, with 100 login pages in the PW backend and without all the hassle of freakling around with Excel sheets at all. But I was really impressed how far I got over the weekend with my first PW installation setup on Friday afternoon last week. But I agree. It‘s important to understand the concept of PW of everything being a page with fields assigned via templates. Thats different from many other CMS I used in the past, but once you got the idea, it starts to make sense quite fast. Cheers zx80

Hey @zx80 welcome to the forum! Glad to hear that! Would be interested in how you found my video (which one btw)? I'm not sure if I understand, but it sounds like you have already found a better approach? When being new to PW there are often situations where you think far too complicated, because you have learned that things work like that or have been done like that. And in PW there is often a much easier and quicker way. Not always of course ? As I didn't really understand what exactly you are trying to do I'm also not sure why you need a console script here? Great! If you still need help or have questions it might help to give more detailed examples. If you are already happy with what you have congrats for your first steps in PW ?

Tested in a local 3.0.217 without any data loss with the same behaviour I remember before when renaming a field. If you want, I could downgrade to your version (whatever it is) and go from there. It's local and I could take a look.

Ahh! Reading this in the early morning laying in bed. Almost always start the weekend with PW blog. What I read makes me smile. A great weekend indeed! Thanks!

This week I'm happy to report that the InputfieldTinyMCE module is now released. It is currently released in the modules directory and GitHub but the plan is it will be merged into the core, likely before the end of the year. No need to wait till then though, as you can start using it today. Please consider the module in beta for the moment, though the TinyMCE library itself is in a stable state. A lot of the work that went into developing this module went into the configuration aspect. Here are a few a more details that weren't covered in last week's post: After installing the module, on the module configuration screen, you can decide whether several settings should be configurable for each field, or if you want to just configure them with the module (affecting all fields): One of things that I thought was important was to make it a lot simpler to add custom classes/styles to the editor. I always found this kind of a pain in CKEditor. So in TinyMCE, I made it so that you can just define these custom styles with the field settings using just simple CSS definitions. InputfieldTinyMCE takes care of converting to a format that TinyMCE can understand (for its menus), as well as the styles to show in the editor. For instance, I wanted to add some common Uikit text classes to a custom "Uikit" group in the Styles dropdown: And here's the result in the editor: The markup produced has the correct Uikit classes in the markup so that on the front-end of my site the output is Uikit ready. You can add 3rd party or your own custom plugins from the module settings: And then you can enable them for any field in the field editor: These are just a few interesting tidbits, but there's a lot more. Also, if you didn't see last week's blog post, that covers a lot more too. Either way, I'd encourage you to download InputfieldTinyMCE, give it a try and please let me know how it works for you. If you come across any bugs, please open an issue report. Thanks for reading and have a great weekend!

Hello @ all I want to share a new module with you, which makes the creation and validation of forms easy. Take a look at the following example of a simple contact form: // A very simple example of a contactform for demonstration purposes $form = new Form('contactform'); $gender = new Select('gender'); $gender->setLabel('Gender'); $gender->addOption('Mister', '0'); $gender->addOption('Miss', '1'); $form->add($gender); $surname = new InputText('surname'); $surname->setLabel('Surname'); $surname->setRule('required'); $form->add($surname); $name = new InputText('name'); $name->setLabel('Name'); $name->setRule('required'); $form->add($name); $email = new InputText('email'); $email->setLabel('E-Mail'); $email->setRule('required'); $form->add($email); $subject = new InputText('subject'); $subject->setLabel('Subject'); $subject->setRule('required'); $form->add($subject); $message = new Textarea('message'); $message->setLabel('Message'); $message->setRule('required'); $form->add($message); $privacy = new InputCheckbox('privacy'); $privacy->setLabel('I accept the privacy policy'); $privacy->setRule('required')->setCustomMessage('You have to accept our privacy policy'); $form->add($privacy); $button = new Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); This piece of code creates a simple contact form and validates it according to the validation rules set. Inside the isValid() method you can run your code (fe sending an email) Highlights: 30+ validation types Support for UiKit 3 and Bootstrap 5 CSS framework SPAM protection Highly customizable Hookable methods for further customization Multi-language You can download and find really extensive information on how to use at https://github.com/juergenweb/FrontendForms. Please report errors or suggestions directly in GitHub. Best regards and happy testing ? If you have downloaded the module in the past I recommend you to uninstall the module completely and install the newest version 2.1.14. There are a lot of changes in the new version, so please test carefully.

Continuing from last week's post and discussion, ProcessWire 3.0.218 decouples the modules system from the cache system. Now the modules system maintains its own internal caches (at least once you do a Modules > Refresh). It'll still use the $cache API as a backup (temporarily), but now you can safely export the database without the "caches" table, or even delete the "caches" table, if you want to. It'll get re-created as needed. In this version, work also continued on the new WireCacheInterface (and major updates in WireCache) so that we could support external modules to handle cache storage. This capability is kind of similar to how we support 3rd party WireMail and WireSessionHandler modules. The first example is WireCacheDatabase, which is the default cache storage handler for the core. And today we have a new module called WireCacheFilesystem that replaces the default WireCache database storage with a file-system based storage, once installed. It's not yet clear if there are major benefits one way or the other (cache in database vs. file system), as I've not been able to put all this new code through performance testing yet. I'd definitely be interested to hear if anyone has a chance to test things out. I expect the file system might be faster for reading caches, while the database may be faster for writing caches. At least that's what I found with a few preliminary experiments, but they haven't been very thorough, so take that with a grain of salt. I thought we needed at least 2 examples of classes implementing WireCacheInterface before we'd be ready to support potential 3rd party WireCache modules. I imagine that 3rd party modules getting into dedicated cache options independent of database or file system is where we'll start to see major performance benefits. At least for sites that use the cache heavily. That's all for this week, have a great weekend!

Good evening to all, watched a youtube video about Processwire a few days back from Bernhard Baumrock and thought I deep dive into this CMS/CMF and try to realize a new project with it. My project basically deals with the subscription to some events (10-20). Basic idea is that potential guests get an E-Mail with the Url and a random unique personalized GUID (40 chars) used to assign to free slots via a public Form without having access to the backend at all. Started with the Intermediate PW install and managed to setup an overview page showing a table with events pulled from it‘s child pages, a detailed page showing all infos for the actual event. Also managed to setup a custom form with three actions (subscribe, unsubscribe and check status of booking). For data storing I would like to create a settings page with text fields for the unique bookingID, a text field for linking a eventID to the bookingID and a datetime field to store the date of the submission. The bookingIDs will be available from start, where eventID and datetime are NULL first and get’s updated depending on the form action taken. I will have to store a table with about 100 entries (Sql rows) and 3 fields (Sql columns). Can this be realized with a repeater and the three custom fields? Should this page be a admin page, or a hidden frontend page? Are there any other options to store this values and access it via the PW API? Any hints would be highly appreciated. Cheers zx80

Sure, there are always many ways ? If I understand correctly you could also do this: <li n:foreach="$downloads as $downloadPage"> {do $downloadPage->of(true)} {include 'download-list--teaser.latte', page: $downloadPage} </li> What about adding a {do $page->of(true)} at the top of this file?

@AndZyk: Thanks for your input. Will try first with the free FrontendForms module as I am quite new to PW and do not have a lot to deal with web dev recently (more C#, Python stuff for Windows Desktop). Hence I don‘t want yet to spend the 179€ for the pro module unless I will know for sure using PW more often in the future. cheers zx80

Fantastic work! That table does exist in my DB. As for DB table names being lowercase by default, that seems to conflict with the admin UI. If the field lets you enter uppercase names, but table names default to lowercase, I think this issue is pretty much guaranteed to happen. I think that because the UI has shown that uppercase letters are accepted and it's been that way for a long time then the solution would be for $config->dbLowercaseTables to default to false. That would preserve the behavior shown in the admin and fix the issue going forward. But, I too, have started to dig deeper. I did a quick search because I was curious about case-handling in MySQL itself and if there might be additional scenarios to consider. Database case sensitivity is dependent on the filesystem of the underlying OS. Windows is not case sensitive, Unix-like systems such as Linux are case sensitive, macOS is almost always the exception to that rule where it's a Unix-like system but HFS+ is not case sensitive and APFS can optionally be (but only at the time of formatting the disk) and is not by default. Even Docker on Mac looks like it struggles with this. So I'm wondering if this is an environment issue and having $config->dbLowercaseTables is true to mitigate potential issues. Regardless though, the admin UI/name field validation should reflect the current DB casing configuration. The better option would just be to eliminate using uppercase letters for fields in the future if it would act as a sort of protection for all environments.

Thanks @bernhard for your reply. Front/back end: it's complex! In this situation, the front end template is being called in a back end context, by PageTableNext (PTN), to render a slice of a page in the shadow DOM. For this reason, I don't want to interfere with the global OF setting as that could risk messing up the operation of the admin forms. As I said, I'm experiencing OF=true for the value being rendered, but OF=false for $page->somePageRefField so I think what's happening is that the global setting will be false, but PTN is presumably setting OF=true on the page it renders, but this does not propagate down. (string) doesn't help me - I think - because the field I'm having trouble with is an image field. But it's useful to know that PW will output-format on toString(). The image field is configured to return a single image (when OF=true) as it will only ever hold one image. However if the template receives the owner of the field with OF=false, then image fields always return an PageImages object, which breaks the template. I think my options are: As I'm doing now: inside the render loop, do $old=$item->of(false); then do $item->of($old); at the end of my code. This means I definitely know that I'm dealing with an output formatted object. In my code set $pages->of(true). And reset that at the end. I feel uncomfortable about this somehow. I suppose I don't know what else it might affect, though it would be nice to do this outside of the field loop. Alternatively, for this specific case, I could reconfigure my image field to always return a PageImages. This impacts quite a few templates though. I think I'll stick with the solution (1) and accept it as a quirk of PTN.

First of all there is $page->of(false) and $pages->of(false). First is singular and sets OF for the single page object, second is plural and sets it globally. Second, even if you have OF=false on a page and you echo a field's content, then you request the string value, which will automatically request the formatted value of your field: Also if you are on the frontend and not in module development there should be OF=true by default.

If the field value is being set from a FormBuilder form field (e.g. send form submission to PW pages) then you will need to set the noTrim setting for the FormBuilder field too. Again, there is no config field for this but I expect you will be able to hook into the form rendering and/or processing and set noTrim=1. Ryan should be able to help with this in the FormBuilder subforum if you're not sure how.

I use this with/on all major or high profile projects that handle lots of data to create a backup each and every time soneone logs into the site. The space is available. And if not... log in every 4 week to delete a few backups.

InputfieldText (and other inputfield types that extend InputfieldText such as InputfieldTextarea) has a "noTrim" setting that is false by default, which is what causes leading and trailing whitespace to be trimmed out of the field value. This setting isn't included in the config options for text fields (not sure why, perhaps because it's rarely needed) but you can add a config option for it with a hook: $wire->addHookAfter('InputfieldText::getConfigInputfields', function(HookEvent $event) { /** @var InputfieldText */ $inputfield = $event->object; /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; $field = $inputfield->hasField; // Only for inputfields that are associated with a Field object if(!$field) return; // Add checkbox field to config to control noTrim setting /** @var InputfieldCheckbox $f */ $f = $event->wire()->modules->get('InputfieldCheckbox'); $f->name = 'noTrim'; $f->label = 'No trim'; $f->label2 = 'Do not trim whitespace from the field value'; $f->checked($field->noTrim); if(!$field->noTrim) $f->collapsed = Inputfield::collapsedYes; $wrapper->add($f); }); This will add a "No trim" checkbox to text fields, and if you tick the checkbox the field value won't be trimmed. Result:

This was on a production server so debug is off, no warning. I am familiar with that data loss warning and didn't see it. I've only seen that when attempting to delete a field or change its type. v3.0.165, so stable and not the latest. I was able to restore the data by pulling a table from an SQL backup and running a query to create the table and insert all of the data. Was the main text field on ~120 pages so there was a chance for a lot of catastrophic data loss. ProCache kept the content live while I restored this but it was a real not-cool moment... ProCache and Cronjob Database Backup can go a long way to save a site with no downtime. Just still really not sure if this is something everyone needs to keep an eye out for or if it was a one time glitch.

Hi, damn, data loss sucks. What PW version are you using? Do you have debug on/off? Had some similar issue yesterday but PW showed a warning that some fields/data will get lost and asked if I would like to proceed. Using the latest public release from last week, not the dev version. Have you noticed any warnings before? Cheers

If you mean in the image picker, you can try out the latest dev version here: https://github.com/BitPoet/MediaLibrary/archive/refs/heads/dev.zip

Welcome to the forums! I have three suggestions. First, when using PW, don't think about SQL unless you really, really have to – and it'll probably never be necessary! Second, when deciding how to structure data, it's usually best to start by thinking of each major item as a page, and move on to complex field types only if it would improve things (usually because it will help with human editing of data). So, for example, you might handle each booking as a page, and then use a Page Reference field to link to the relevant event. Third, if you haven't already, look in depth at selectors (very important and a great feature of PW!) for retrieving the data you need. Let us know if further help would be useful!

how can I retrieve the URL (absolute path) of an image added to a media-manager-image field of a page? Can't find the API. EDIT: never mind, I figured it out, need to loop even though it's a single image. foreach ($page->mmfield as $image) { echo $image->media->url; } right?

Hi kongondo, I just watched the video and it looks very good! I already sent some suggestions a while ago, but I wanted to repeat an important one: I have some projects where the clients have lots of PDFs with very long detailed technical names. I assume the PDFs won't have thumbnails in Media Manager, so it would be very good if one could switch the view to a really compact list view, where the filenames would not be cropped. Perhaps in this list view also some other meta data could be shown, like filesize etc. Also I would add that the filenames or image titles as shown in the video are cropped in a way it makes them nearly unreadable. So I am wondering if you could consider an option to not crop those titles or filenames at all?

Just happend on PW 3.0.163. Fixed by rebuildAll method available since 3.0.156 $pages->parents()->rebuildAll();

Regarding your first issue: and in mystyles.js: CKEDITOR.stylesSet.add( 'mystyles', [ { name: 'Warning Paragraph', element: 'p', attributes: {'class': 'uk-alert-warning', 'data-uk-alert': ''} }, { name: 'Success Paragraph', element: 'p', attributes: {'class': 'uk-alert-success', 'data-uk-alert': ''} } ]); This setup works for me in ProcessWire 3.0.62. Is it what you are looking for? Also, something like this is my config-body.js: I have not yet worked with contents.css/contents-inline.css, it is still on my todo list...