The folks at vimeo do not place the same restrictions upon content that YouTube does, and you can simply place the vimeo url for the video in your code and enjoy excellent streaming video that is scaled to the user's available bandwidth.

There might be various uses for it to be separate login. When enabled, the two login sessions are completely separate. You can be logged into CMSB and separately be logged into the front end as a different user. Maybe you are a CMSB admin doing some work in the back-end as an admin, but you want to login to the front-end as a normal user to see what they see. When set to false the CMSB user and the front-end use the same login space.

The practical effect of setting it to false is that if you log into CMSB admin, you'd also appear logged in on the website front-end. Of course it doesn't mean that a websiteMembership user could access the CMSB back-end because there are still permission checks etc. in place.

Hopefully that makes sense. :)

I guess I have been misunderstanding the setting itself. For what purpose do folks use the "true" setting of  $GLOBALS['WSM_SEPARATE_LOGIN'] ?

Are you still seeing this error or did you get it resolved? Did you recently upgrade to 3.82 and it stopped working or is this suddenly happening? What version of websiteMemberhip are you using?

If it is still happening, and your version of websiteMembership is not the most recent, try upgrading it if you can. That usually resolves the issues. If that does not solve the issue, you can certainly look in the error logs for errors and give it to us as part of opening a support ticket. 

Usually when upgrading CMSB, a few plugins need to be upgraded as well. 

Thanks!

When you say that you have separate logins, I am assuming you have set the WSM_SEPARATE_LOGIN global variable in websiteMembership.php to "true". This means that logging into CMSB is going to be a separate login than trying to login to pages that are protected by websiteMembership.

Your code there is testing for the websiteMembership login "CURRENT_USER" and if not, redirects them to the login page. 

From what I am understand as to what you are saying, the user logs into CMSB as an admin, clicks a link which takes them to that page protected by websiteMembership. There it sees that CURRENT_USER is not set, so immediately redirects the user to the login page. Because the user has logged into CMSB doesn't mean they skip login for the page protected by websiteMembership (when using separate logins).

Am I understanding the process you are going through here? If not, any further clarification would help.

Thanks!

Users of the backend login to perform their admin duties, one of which involves selecting a menu item that is a link to another page outside of the background interface that also requires login.

That page is protect like this:

i$libraryPath = 'xxxxxxx/lib/viewer_functions.php';
$dirsToCheck = ['','../','../../','../../../','../../../../'];
foreach ($dirsToCheck as $dir) {
if (@include_once("$dir$libraryPath")) { break; }
}
if (!function_exists('getRecords')) {
die("Couldn't load viewer library.");
}
if (!$CURRENT_USER) { websiteLogin_redirectToLogin(); }
if(!$CURRENT_USER['isCME_director'] && !$CURRENT_USER['isCME_staff'] && !$CURRENT_USER['isAdmin']) {
redirectBrowserToUrl("access_denied.php?msg=This feature is for administrators only.");
exit;
}

The problem I am having is that the logged in user who clicks the link taking him to this page is then presented with the login form once again and must log in a second time.

Has anyone encountered this behavior?

CMSB v. 3.56

websiteManagement v. 1.13

Also, the site depends upon a number of plugins to include createPDF, csvImport, formGenerator, newsletterBuilder, QRCode Generator, reportBuilder, showHideDependedentFieldsPlus, showHideFieldsForUsers, and websiteMembership. Can anyone share any problems they may have encountered with similar upgrades?

The hospital using this application depends upon it daily, and I will need to accomplish the change over a weekend and have a working version on the following Monday. I confess to being a bit nervous.

The above is just a snippet that helps set up a PHP file that will load when "llms.txt" is accessed. On its own it does not generate any of the content, but it's a good first step in being able to do so.

Thanks for reporting this bug!

I've created a fix that will be included in the next version of CMSB.

For you or anyone else who is currently having this issue, here's a patch that should fix it.

In the file: cmsb/lib/schema_functions.php around line 288

Find this code:

if (empty($schema[$name]["createThumbnails$suffix"])) {
      unset($schema[$name]["createThumbnails$suffix"]);
      unset($schema[$name]["maxThumbnailHeight$suffix"]);
      unset($schema[$name]["maxThumbnailWidth$suffix"]);
      unset($schema[$name]["cropThumbnails$suffix"]);
  }

And replace it with this:

 $thumbnailDisabled =
  empty($schema[$name]["createThumbnails$suffix"]);
  if ($thumbnailDisabled) {
      unset($schema[$name]["maxThumbnailHeight$suffix"]);
      unset($schema[$name]["maxThumbnailWidth$suffix"]);
      unset($schema[$name]["cropThumbnails$suffix"]);
      if ($suffix !== '') {
          unset($schema[$name]["createThumbnails$suffix"]);
      }
  }

Let me know if you have any futher issues.

Thanks!

<?php
  header('Content-type: text/html; charset=utf-8');
  include_once("../cmsb/lib/viewer_functions.php");

  // get the URI and trim leading and trailing slashes
  $uri = trim($_SERVER['REQUEST_URI'], '/');

  // lookup the URI in the permalinks table to find the corresponding section
  $section = mysql_get('cmsb__permalinks', null, [
    'permalink' => $uri,
    'old'       => '0'
  ]);

  // get the tablename for the section
  if ($section) {
    $tableName = $section['tableName'];
	
    // and then load the page
    list($page, $pageMetaData) = getRecords(array(
      'tableName'   => $tableName,
      'where'       => whereRecordNumberInUrl(0),
      'loadUploads' => true,
      'allowSearch' => false,
      'limit'       => '1',
    ));
    $page = @$page[0]; // get first record
    if (!$page) { 
      header("HTTP/1.1 301 Moved Permanently");
      header("Location: /"); 
      exit;
    }
  }

?>

• About pages > /pgs/about-pages.php
• Contact pages > /pgs/contact-pages.php
• Service pages > /pgs/service-pages.php

Note, I am using the Permalinks plugin.

But I was wondering if there is a way for me to use the same page template for all of the sections?

• About pages > /pgs/pages.php
• Contact pages > /pgs/pages.php
• Service pages > /pgs/pages.php

Unfortunately, there's no built-in functionality for that, or quick fixes.

Can you let me know what you want to use it for and how you'd want it to work? 

For example, what problem are you trying to solve?

Thanks!

We're currently working on a big update for the next release, but I can keep this in the queue for a future release.

We actually wanted to redo the date component already for better multi-lingual support.

The browser date fields are generally considered not to have the best user experience compared to some of the custom ones.   

The benefit of the multi-field is that it's quick to select, but it depends on your use case, though.  You'll see most of the big sites (airbnb, google flights, etc) use custom date controls.  We were looking into some of the more popular date field components a while back.

We've already got some requests for Date field modifications already.  Can you let me know how you'd like it to work differently so we can consider that as well?

Thanks!

This took us a bit to track down.  Can you try this fix: 

In /cmsb/lib/menus/default\wysiwygMedia.php

Replace this: 

uploadIframe.contentDocument.location.reload();

With this: 

uploadIframe?.contentDocument?.location.reload();

Let me know if that works for you.  If not, feel free to submit a 2nd level support request, and we'd be happy to help you track it down and resolve it.

Thanks!