wpconvert

Any update on this? Thanks

No problem. You might also wish to look into this…
When someone makes a booking, it seems to be successful but this appears in the php error log:

[29-Mar-2021 19:09:29 UTC] PHP Warning: array_map(): Expected parameter 2 to be an array, null given in /home/mydomain/public_html/wp-content/plugins/salon-booking-system/src/SLN/Action/Ajax/CalcBookingTotal.php on line 79
[29-Mar-2021 19:09:29 UTC] PHP Warning: Invalid argument supplied for foreach() in /home/mydomain/public_html/wp-content/plugins/salon-booking-system/src/SLN/Action/Ajax/CalcBookingTotal.php on line 81
[29-Mar-2021 19:17:05 UTC] SLN booking date/time: 2021-04-14 16:00
[29-Mar-2021 19:17:05 UTC] SLN booking services: Array
(
[1263] => 1286
)

[29-Mar-2021 19:17:05 UTC] SLN booking settings: Array
(
[attendant_enabled] => 1
)

[29-Mar-2021 19:17:05 UTC] SLN booking service id: 1263
[29-Mar-2021 19:17:05 UTC] SLN booking service attendant enabled: 1
[29-Mar-2021 19:17:05 UTC] SLN booking service attendant id: 1286
[29-Mar-2021 19:17:08 UTC] SLN booking date/time: 2021-04-14 16:00
[29-Mar-2021 19:17:08 UTC] SLN booking services: Array
(
[1263] => 1288
)

[29-Mar-2021 19:17:08 UTC] SLN booking settings: Array
(
[attendant_enabled] => 1
)

[29-Mar-2021 19:17:08 UTC] SLN booking service id: 1263
[29-Mar-2021 19:17:08 UTC] SLN booking service attendant enabled: 1
[29-Mar-2021 19:17:08 UTC] SLN booking service attendant id: 1288
[29-Mar-2021 19:22:54 UTC] PHP Warning: The use statement with non-compound name ‘SLN_Plugin’ has no effect in /home/mydomain/public_html/wp-content/plugins/salon-booking-system/src/SLN/Admin/Customers/List.php on line 7
[29-Mar-2021 19:52:36 UTC] PHP Warning: The use statement with non-compound name ‘SLN_Plugin’ has no effect in /home/mydomain/public_html/wp-content/plugins/salon-booking-system/src/SLN/Admin/Customers/List.php on line 7
[30-Mar-2021 12:20:53 UTC] SLN booking date/time: 2021-04-14 13:00
[30-Mar-2021 12:20:53 UTC] SLN booking services: Array
(
[1267] => 1284
)

[30-Mar-2021 12:20:53 UTC] SLN booking settings: Array
(
[attendant_enabled] => 1
)

[30-Mar-2021 12:20:53 UTC] SLN booking service id: 1267
[30-Mar-2021 12:20:53 UTC] SLN booking service attendant enabled: 1
[30-Mar-2021 12:20:53 UTC] SLN booking service attendant id: 1284
[30-Mar-2021 12:22:19 UTC] SLN booking date/time: 2021-04-16 12:30
[30-Mar-2021 12:22:19 UTC] SLN booking services: Array
(
[1267] => 1284
)

[30-Mar-2021 12:22:19 UTC] SLN booking settings: Array
(
[attendant_enabled] => 1
)

[30-Mar-2021 12:22:19 UTC] SLN booking service id: 1267
[30-Mar-2021 12:22:19 UTC] SLN booking service attendant enabled: 1
[30-Mar-2021 12:22:19 UTC] SLN booking service attendant id: 1284
[31-Mar-2021 11:09:26 UTC] SLN booking date/time: 2021-04-12 10:00
[31-Mar-2021 11:09:26 UTC] SLN booking services: Array
(
[1248] => 1276
)

[31-Mar-2021 11:09:26 UTC] SLN booking settings: Array
(
[attendant_enabled] => 1
)

[31-Mar-2021 11:09:26 UTC] SLN booking service id: 1248
[31-Mar-2021 11:09:26 UTC] SLN booking service attendant enabled: 1
[31-Mar-2021 11:09:26 UTC] SLN booking service attendant id: 1276
[31-Mar-2021 11:41:41 UTC] PHP Warning: The use statement with non-compound name ‘SLN_Plugin’ has no effect in /home/mydomain/public_html/wp-content/plugins/salon-booking-system/src/SLN/Admin/Customers/List.php on line 7`

————————————————–

Hope it means something to you
Thanks again

Hi kwnstel

I feel that I might be able to offer you a little help or insight here as I experienced the same thing.

To get around this problem, I installed the excellent “Branda” plugin. This will also provide you with a number of other options that you might even have not known you wanted.

The main solution to your particular problem, however, can be solved by using the login redirect feature – redirect users to the Booking My Account page upon login (and maybe your homepage when they log out).
In addition, you can customize what user roles have access to which dashboard features in this plugin – I turned them all off.

Also be aware that salon booking plugin creates it’s own user role – and you should set the default to “saloncustomer” in settings/general on your WordPress dashboard (it’s normally set to Subscriber). I take it that these are the only users that you allow to log in – they are in my case.

Do be aware of the security/password issues that this plugin doesn’t address at the moment though (you can see my recent post on this lower down).

Hope that this might help you or at least offer an option for you with regards your original question.

I also notice that if you create a booking/new user in the back end – on the calendar for example – the user gets 2 emails. One confirms the booking made and one asks the user to set a password

it appears there is no need to set a password. if the user clicks on the email to manage the booking, they can do this without having set a password.

It would great to see these issue addressed in the next update very soon!

Thanks for your swift response – and thanks again for your work on this plugin. If these important security/password issues are resolved then it will be a great platform.

And there it is – acknowledgement of the issue, considering a method for a future update…and ‘easy fix’ advice for the current installation.

Thanks again – obviously marking as resolved.

Hello again.

Seemed to have solved this issue by de-activating GF+Stripe & GF+(more) Stripe and then re-activating them after the update.

Contact for seems to be working as expected now with no error message being reported.

Apologies for the confusion.

All working well now – thanks for your patience.

My network config is not whacky – root folder install – subdirectory – nothing special (I don’t think). Your test set-up sounds bizarre (and worse case scenario!)

You were correct – adding the extra define(‘WP_ALLOW_MULTISITE’, true); enabled the network setup option. Here is my htaccess code presented in network setup:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

I was missing everything after RewriteRule ^index\.php$ – [L] for some reason after updating from 51.4 to 51.6? I think it must have been a copy/paste issue in custom code when adding the non-www to www entry to the loop.

Anyway, it’s all sorted now – and I have created a new entry in custom code (I’ve added the below entry to the loop after RewriteBase /)
RewriteCond %{HTTP_HOST} ^mydomain\.co.uk$ [NC]
RewriteRule ^(.*)$ https://www.mydomain.co.uk/$1 [R=301,L]
and created a new secure htaccess file. It all looks correct now.

Perhaps maintenance mode might work now?…but I’m too scared to try it!
If there is no other input then please mark this thread as resolved.

Thanks again for your efforts.

Hi

Thanks for looking into this. Clearly, my mistake – should have read about the extra feature (UI Theme skin….). Sorry.

As for your suggestion to look in Network Admin panel >>> Settings >>> Network Setup – I don’t have this option? I thought that this was only during initial network setup? I have Network>>>settings which displays operational settings – but not the rules for htaccess file?

I have to admit that as each new version of BPS comes out with more features..I’m starting to get a little concerned. Extra features can mean extra problems…and a larger plugin footprint.

I find that maintenance mode doesn’t work for me already (kills my site and I have to restore previous index files – so I don’t use it).

Just another issue (which may be of my own making?).

Noticed the subsite of my multi-site network (there are only 2 sites) – images were not displaying either on the front-end or back-end (in posts or media gallery).

Upon going through htaccess file (seems to be the main place to look for these types of issues) – and comparing files from 51.4 and 51.6, I noticed that these two lines were missing from the new 51.6 root htaccess file:

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

I’m not sure if this is by design – or if they should have been in Custom Code? (they weren’t) but after adding these back in, it seemed to fix the image problem.

I’ve now added these two lines to Custom Code WP Rewrite Loop Start in case they are lost again. (hoping this would be the correct place to put them?)

Does this make sense? Thanks

As usual – top support!

I’ll test the admin-ajax rule with this version of GF – at the moment, and after much troubleshooting, I have ajax form submission turned OFF which solves my particular issue.

Glad to hear that the BPS button issue is identified as a small coding ‘oversight’ and not a problem with my site – I’ve had more than a few ‘anomalies’ to deal with recently! I know what you mean about the simple stuff!

Thanks again and keep up the good work!

Thanks for that atao – but I solved my issue.

I have to think back now (it was quite some time ago) but I’m pretty sure that the problem was being caused by my caching plugin (Quickcache) at the time.

Amending the cache configuration and disabling and re-enabling the caching plugin afterwards did the trick as I recall – and Better WP Security then worked as expected to secure the single page.

I now use Quickcache Pro (which is great by the way), PHP 5.4 and the latest Better WP Security under WP 3.8.1 and everything is working as it should.

Thanks for your time in sharing your own solution.

Thanks again for the detailed response – I have mentioned this to the host (who are actually very good). Maybe it’s something that they haven’t implemented yet? They do specialise in WordPress hosting though…

A new version of Quick Cache should be released in the near term, apparently – I’ll give that a go before considering Supercache or similar (I’ve read some pretty alarming things recently regarding Supercache).

Thanks again.

Just a quick update.

In fact – the problem was with PHP 5.4.17 – not the gzip code (this line had made it into the gzip code earlier and I hadn’t noticed).

Rolling back to 5.2.7 got everything working.

Out of interest, although using the gzip code in .htaccess does reduce initial page size – Pingdom reports the website loading consistently faster without it (average of 1.4 seconds for 1.7MB page) as opposed to average 1.6 – 1.8 seconds for 1.5MB page with it – so that was a revelation…

Clearly, Quick cache on my host with PHP 5.4.17 does not play well (all of a sudden). Perhaps it’s time for a change after all – although caching seems to be introducing more problems than it solves!

Thanks again.

Hi AITpro

As always – I have to commend your support for this plugin. Prompt responses and going that extra mile to test various scenarios to deliver a qualified solution.

You were quite right, the Timbthumb / Quick Cache issue seems to have been a result of something in the custom .htaccess code.

After removing all custom code – everything seemed to operate as expected. I added bits of the custom code back – and the problem appears to have been with the gzip code:

# BEGIN Gzip enable
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>
#END Gzip enable

.htaccess file without this code works as expected.

The bizarre thing is that this started happening out of the blue – nothing has been changed and this has been working for months and months without a problem?

Anyway – problem now solved and was NOT an issue with Bulletproof security – still one of the plugins that I rely on the most.

Thanks again for your time in testing and supporting the plugin.