The form code generator plugin doesn't support file upload controls right out of the box. However, using some of the code from the files you show you should be able to get it to work with your target table and upload. The steps are outlined below and assumes you have some basic coding skills to get it working.

1. Start by creating a form that targets your desired table using the form generator plugin. If you have not seen this plugin, you can find it in our plugin section of the site. Here is a direct link: https://interactivetools.com/plugins/form-generator/
2. Copy over the folder into your site's CMSB plugin directory.
3. In CMSB admin, go to CMSB Setup >> Plugins and in the inactive plugin section you should see the form generator plugin. Activate it.
4. In CMSB admin, go to CMSB Setup >> Code Generator and click "Form Generator". There you can target your desired database table which will have the upload field on it. 
5. Once you have filled out the fields, click generate.
6. Copy the code to a new PHP file and save that file on your website (you can put the page in your root directory for now)
7. Looking at this page you will see that there is a note to developers that upload fields are not supported. That is fine. We can go back into the page and in the HTML where it says that, you can replace it with this..

<iframe src='uploadForm3_iframe.php?table=<?php echo $FORM_TABLE  ?>&amp;field=<field name here>&amp;num=<?php echo $FORM_RECORD_NUM  ?>&amp;preSaveTempId=<?php echo htmlencode($FORM_PRESAVETEMPID) ?>' height='150' width='100%' frameborder='0' scrolling='yes'>
</iframe>

You will notice that in this code there is a place you have to replace called "Field name here" where you will put the name of the field from your table. For example, if you called the field in your table "my_image" then you would use that name in the URL for the field.

Almost done...

1. Copy the uploadForm3_iframe.php into the same directory as your newly created page. 
2. At the top around line 2 you will see a path to viewer_functions.php that will need to be updated to point to your viewer_functions. If your installation of CMSB is in cmsb, and you put these files in your root web directory, you can use something like...

require_once __DIR__ . "/cmsb/lib/viewer_functions.php";

1.  Then down on lines 14/15 of uploadForm3_iframe.php you will see a set of allowed tables and allowed fields. Put in the name of your table and name of the upload field you are targeting again. You can add more tables and more fields here if you wish this script to service multiple tables and fields. This is just for security to allow the processing of targeted tables and fields. 
2. Lastly, just to clean things up, you can delete the lines that tries to include 'core_head.php' and the line down around 200 which echos the $preSaveTempId. I am guessing these are implementation specific and for debugging. 

Once you have followed these steps, you should then be able to visit your page again and see a box to upload images, select an image and submit the form to have a new record created in your table with the image uploaded. 

If you wish to upload other file types, you will need to make sure the CMSB upload field you have in your table has the added file extensions. You will see them when you modify the field.

I hope this helps! If you continue to run into problems, you can reach out to us on support and we can look at giving you a quote to hook up the fields. 

Enjoy! :)

Thanks for reaching out and asking the question. While we don't have a dedicated 2FA plugin, or plans to implement it in core as part of our road map just yet, we have built such plugins for other clients. They work in tandem with the websiteMembership plugin and so could be something we spin up rather fast for you. I also know the team has done some work with Google OAuth as well so might also be an option. I am sure if you send in a support ticket along with what your thinking, the team can give you a quote. 

Thanks! :)

Thanks for the additional information. So digging into the issue a bit I did stumble across some info saying that some docker images don't have the php.ini and may require additional steps to put one in. That in fact, and you show this, it steps through the conf.d directory for additional .ini.

When it comes to docker, this means that the php_ini_loaded_file() could very well return false while still being absolutely fine (or found a php.ini in a conf.d directory to load in). I will bring this up with Dave as we should probably make sure that the code there is more robust for cases where php_ini_loaded_file() would return false. I would certainly say it is a bug in the fact we don't account for the false value.

Thanks for reporting!

php_ini_loaded_file() could return a false if PHP can't determine if an actual PHP.ini file is being loaded. This could mean your servers are running with default values and not the values you specified in a PHP.ini file when setting up PHP. One way you could check if this is the case is to go onto your server command line and run

"php --ini" 

and see if the file path it reports actually points to the php.ini file you think it does. If they file doesn't exist, it may be running on defaults which could be problematic if you are running a production server.

You can also check phpinfo() and see what it pulls in for settings and which file it reads from. 

The problem is that if PHP is not reporting a php.ini file being loaded, it returns false to absPath which expects a string (perhaps we can make that section more robust as well) and hence the error you are seeing. 

Let us know what you find out. :)

The dateLogged field is a timestamp database field with a default of the current timestamp. You shouldn't need to set it in the code as MySQL will set it at time of insertion. Are you seeing this with all the error log entries or just certain log entries? Did it just start with your upgrade to v3.77?

Additional information may help us track down the reason. Perhaps somewhere a date is being inserted that is bad and so MySQL is setting it to null or some other value that equates to the UI showing "never". 

Note: If you have the developer console plugin enabled, you could query the error_logs table and see if there are bad values in the dateLogged table. Might offer a clue. :)

I was able to recreate what you are seeing and what is happening is that their are some defaults in the system that get overwritten by what is in the schema file on load. In the case of infoField2, there is a default of "Caption" that when it reads the schema and sees no infoField2 it will not overwrite this default "Caption" value and so it reappears. 

This will cause the problem you are seeing where if you don't remember to clear that field each time, eventually the default value makes its way back into the schema and becomes visible again. I will outline the issue to Dave and so he can put it into the next version as a fix. 

Thanks for the report!

Looking at the code you will see that $record['documents'] is an array of values and we are referencing just the first one with [0]. So if you want to see more than just the first, you can loop through the documents.

function _listRow_displayFileNameForUpload($displayValue, $tableName, $fieldname, $record) {
    // Specify the specific table and field you want to modify (replace the table name and 'documents' with your field name)
    if ($tableName === 'test_table' && $fieldname === 'documents') {
        // Check if the record as our field name and it is an array with at least one document
        if (isset($record['documents']) && is_array($record['documents']) && count($record['documents']) > 0) {
            $displayValue = '';

            // Loop through each document in the 'documents' field
            foreach ($record['documents'] as $document) {
                // Reference the field on that record and the 'filename' key
                // Add to the display value. Here I am customizing it to be a "badge" style value as well.
                $displayValue .= '<span class="badge badge-primary">' . $document['filename'] . '</span>';
            }
        }
    }
    return $displayValue;
}

Notice here that we introduced a foreach that loops through that array and for each one we are tacking it onto the $displayValue. Hopefully you see how this is working out. Again I have tested this code myself so should work fine once you make the modifications for your situation.

I hope that helps!

One thing you can try is putting the code that Dave gave you right into the WYSIWYG field. Here are the steps...

1. In CMSB, go to your target WYSIWYG field content.
2. In the toolbar look for an icon that shows "<>". Pressing this button will put you into an HTML mode.
3. At the top of the content (before anything else) put the line...

<style> @keyframes blink { 50% { visibility: hidden; }} .blink { animation: blink 1s step-start infinite; }</style>

Then wherever you want the text to blink you can wrap that content with the span tag...

<p>Normal text… <span class="blink">blinking text</span> …normal again.</p>

Notice that we wrap the text we want to blink with the span tag and its class is what is defined in the style tag at the top. Make sure you put the style at the top so that it should be defined before the blinking text. 

NOTE: If you have multiple WYSIWYG fields on a page and each one you want something to blink in, put the style tag in the first one and I believe (not tested) that you can leave it out of the others and it should work for them all. 

This solution is a bit of a workaround for special case, but a more solid solution exists by creating a custom CSS file that will need to be put into CMSB. Since you said you didn't want to do anything like that, this solution above should work fine. I have tested it myself on WYSIWYG fields on my development systems.

I hope this helps! :)

Well if you see it in the plugin list, you have done it correctly. If you look to the right of the plugin name in the list you should see either "Activate" or "Deactivate" as a link. If you see "Activate" click it to turn it on. It should then appear in the top list. If it is deactivated, it will appear in the bottom list.

The code I presented you is pretty much the entire plugin file other than the header to tell CMSB that the file is a plugin. 

I have run and tested this code before I posted, so I am sure the actual code works. Make sure you have the following set up:

1. Make sure the plugin file you created is activated and is in the active plugin section.
2. Make sure you replace the table name and the field name to reflect your table and field you want to target. In my example I used "test_table" and "documents" but yours will be different.
3. The field name is referenced in a couple places so make sure all have been replaced.

If you have done all these things and still see no change, you can always post your entire plugin file and I can take a look. If all is good I should be able to take your file, change the table and fieldname as appropriate and it should just work.

Let me know how things go. :)

The file you are trying to import, is it a file that you first exported from the table using something like the csvExport plugin? If you export it and then try to immediately import (without changing anything) do you still get the error?

Also, if you check the developer logs in CMSB, do you see any new errors related to this?

Any additional error messages you can provide from the developer logs and details about how the file you are trying to import was created can be a big help.

Thanks!

You can if you tap into the related filter hook called "listRow_displayValue". Below is an example of using this hook to alter the display value of any list table. 

Step 1. Make sure you list the column in the Section/Database Editor >> Editor Tab >> List Columns field. This will show the column for you.

Step 2. Create a plugin file where you then implement the filter hook like shown below. Here we are looking up the specific table (in this case test_table is my table name) and the field name given to the upload field (in my case it is just called 'documents')

addFilter('listRow_displayValue', '_listRow_displayFileNameForUpload', 'admins');

function _listRow_displayFileNameForUpload($displayValue, $tableName, $fieldname, $record) {
    // Specify the specific table and field you want to modify
    if ($tableName === 'test_table' && $fieldname === 'documents') {
        if (isset($record['documents'][0])) {
            // Reference the field on that record and the first document in that field
            // Then replace its display value. Here I am customizing it to be a "badge" style value as well.
            $displayValue = '<span class="badge badge-primary">' . $record['documents'][0]['filename'] . '</span>';
        }
    }
    return $displayValue;
}

Step 3. Customize the line where I am setting up the badge to be the HTML that will replace the display value. I am creating a simple span tag here. Whatever you set displayValue to be will then be displayed. For security reasons, always make sure you are in control of the content here and escape appropriately if need be (if you are doing anything more advanced).

When you display the list for this table then it will render your filename. Since we are referencing '0' it will be the filename of the first upload for the field. Additional uploads will be referenced according (1, 2, 3 etc.)

I hope this helps push you in the right direction to a solution.

I believe replacing your calculation table cell with the following should do the trick. I am assuming you just need it for the display and not in the database. 

<td align="center"><?php echo htmlencode( (intval($record['total_live_hatchlings']) / intval($record['total_number_of_eggs'])) * 100 ) ?></td>

So here we are taking each record column, converting them to integers, divide the total hatchlings by the number of eggs and multiply by 100. That will give you a floating point value. If you need to round it, there is the PHP round function you can use to do that as well. 

Hopefully this is what you were looking to do.

Thinking through it a bit more a few things you can check on your end would be to go to the MySQL Source tab in CMSB admin

/admin.php?menu=database&action=editTable&tableName=_error_log#tab_mysqlSource

Within this page you can see if the `dateLogged` field is properly set up as being `timestamp NULL DEFAULT CURRENT_TIMESTAMP`.

You can also try enabling your developer console plugin and going to

/admin.php?_pluginAction=mysqlConsole&tableName=accounts

There you can try running a query like:

SELECT num, dateLogged, error FROM ::_error_log ORDER BY num DESC LIMIT 20

This should show you the type of dates that CSMB is using and why it might be coming back as `never`. 

If you have any additional questions about this, I will be happy to elaborate further. I hope this helps! :)

Just out of clarification, are you talking about in the development log under the "Date / When" heading? Or somewhere else in the development log? Did you recently update to 3.75? Are all the development log records showing that or just some of them? Was there any kind of database update from your host do you know?

Usually when 'never' appears it means that a date time field is not in a recognizable format. There could be a host of reasons. If you are seeing it a lot, it might be worth submitting a support ticket with us to investigate further.

I am going to guess something was either updated or changed recently that may have resulted in bad dates.

Typically, you wouldn't store member_id as a separate field in the cmsb_tournament table. Instead, you should set up a foreign key (or related record) that links directly to the num field in the cmsb_member table. This approach avoids the issue of having to update two separate fields simultaneously (the member field and the member_id field in cmsb_tournament), which could easily lead to inconsistencies.

By establishing this foreign key relationship, any query on cmsb_tournament can use the link to cmsb_member to retrieve the member's details, such as first and last name, based on the ID stored in cmsb_tournament.member. This ensures that all member-related information is maintained in a single location (the cmsb_member table) and remains consistent.

Have you considered using a foreign key or related record field to reference the member in cmsb_member? :)

I think something like this should get you moving in the right direction:

<?php
  /* STEP 1: LOAD RECORDS - Copy this PHP code block near the TOP of your page */
  require_once "/system/lib/viewer_functions.php";
  
  // If you prefer to just die if the keyword search is greater than 35
  if (isset($_REQUEST['title_keyword'])) {
     if (strlen($_REQUEST['title_keyword']) > 35) {
         dieWith404('Page not found!');
     }
  }

  list($my_listRecords, $my_listMetaData) = getRecords(array(
    'tableName'   => 'my_list',
    'perPage'     => '100',
	'loadCreatedBy' => false,
  ));
?>

Here we are saying that if the value submitted by the form ('title_keyword') is set, and if greater than 35 characters, die with a 404 response.

Another option is that you could also send the user to a custom 404 page through a redirect...

<?php
  /* STEP 1: LOAD RECORDS - Copy this PHP code block near the TOP of your page */
  require_once "/system/lib/viewer_functions.php";
  
  // If you prefer to just die if the keyword search is greater than 35
  if (isset($_REQUEST['title_keyword'])) {
     if (strlen($_REQUEST['title_keyword']) > 35) {
        header("HTTP/1.0 404 Not Found");
        header("Location: /custom-404.php"); 
        exit();
     }
  }

  list($my_listRecords, $my_listMetaData) = getRecords(array(
    'tableName'   => 'my_list',
    'perPage'     => '100',
	'loadCreatedBy' => false,
  ));
?>

Let me know how that works out for you. 

WYSIWYG fields are typically piped through TinyMCE and any HTML/Code you put through it is restructured/reformatted to be proper HTML structure and not executed on the server side (this includes stripping out unrecognized tags such as PHP tags).

There are ways to get the editor to not filter out any PHP code (for instance to save it in the database) but it is advised to be very careful with this as you can easily introduce a security risk. If anyone is able to put PHP code into one of those fields and it is executed by your server, that would be bad.

Another option would be to have your code run PHP first and then put its output into the editor when it initializes. It all really depends on what you are trying to accomplish. :)

In this case the error is pretty explicit. Somewhere there is a session_start() call being made prior to the CMSB view_functions.php being included. In index.php, do you see session_start() at the top and before the viewer_function.php include code? If it is, try either deleting the session_start() (as that is being started in the viewer_functions.php include code) or moving it down after the viewer_functions.php code is being included.

If you don't see that happening, perhaps SiteLok is starting that session and it is conflicting with the viewer_functions.php session handling. One way to find this out is if the index.php page (which is generating the error) suddenly works after you disable SiteLok and then doesn't work again when you enable SiteLok that can give you the vital clue that it is SiteLok that is the issue.

Let us know how it goes! 

We are still investigating this issue and it is in our queue. I believe the error message you posted might be totally unrelated, but is something we will check out as well. 

I wasn't able to recreate the issue exactly as you are experiencing, but I did encounter issues when I tried with your statement. Your IF only has the "true" part and not a "false" part. Can you try specifying a false part to your statement and see if you get the desired results? Can you also look in your cmsb field viewer and see if the MySQL Type column has "varchar(255) STORED GENERATED" as a value? See attached screenshot (generated-column-screenshot1.png) for confirmation?

I wasn't able to see a value for this column (and was only in the schema file, not synched with the database) when not specifying the false part of the statement. As soon as I added the false condition to the statement I saw this in the field editor...

CONCAT(permalink,if(LENGTH(shadow_permalink),CONCAT("<br>-> ", shadow_permalink), 'test'))

Which became this in the schema file...

'gen_links' => array(
    'order' => 15,
    'label' => 'gen links',
    'type' => 'GeneratedColumn',
    'gcExpr' => 'CONCAT(permalink,if(LENGTH(shadow_permalink),CONCAT("<br>-> ", shadow_permalink), \'test\'))',
    'gcType' => 'STORED',
    'indexed' => '0',
  ),

And became this in the mysql source tab...

`gen_links` varchar(255) COLLATE utf8mb4_unicode_ci GENERATED ALWAYS AS (concat(`permalink`,if(length(`shadow_permalink`),concat(_utf8mb4'
-> ',`shadow_permalink`),_utf8mb4'test'))) STORED,

It also appears to be operating correctly for the generated column. Appending 'test' to the permalink if the shadow_permalink field is empty, otherwise appending the br tag and shadow_permalink if there is indeed a shadow_permalink specified.

I think specifying the false condition might be all you need to see everything sync up.

Let me know how it goes.

Just posting here to let you know that I am looking into this for you and will let you know what I find out over the next day or two. 

Thanks!

I have addressed the issues with you via email. Just let me know if you experience any other problems.

Thanks!

Besides passing just the page number in your links, you would pass along the additional filter criteria as well. Then on the page, you can used the passed criteria to query the data for the results and use that when setting up your pagination. I hope that makes sense. Since you don't pass along any of the filter data, just the page number, the query on the page doesn't know to filter the results and use that filtered data set as the basis of your pagination.

In the end you want $music_videosMetaData to be filled with the filtered results that was queried from the database using the values you passed along in the page links. For instance if you passed along a music artist name, you would pass page=2&artist=Cher so when the page loads it can use "Cher" to filter the results and then go to page 2.

Without knowing more about what fields you are dealing with, I can't provide additional code changes. I am hoping the explanation above would be enough to get you moving in the right direction. :)