I recently updated to 0.9.9.2 and noticed the messages are getting sent to kannel in some sort of encoding. While the messages are getting sent with the proper text they are being split into multiple messages apparently based on 160 encoded characters.

Can you shed some light on how I can resolve this?

Note that I have sqlbox in the mix if that helps at all.

I also recently updated kannel to 1.5.0 but I've tested sending content to it directly and the # of messages are correct based on message length.

Hello.

I was testing this and noticed that if you simulate a test message, the first word is missing.

Steps.

https://localhost/index.php?app=main&inc=gateway_dev&route=simulate&op=simulate

Enter Message

"This is a test message."

Step 2.

Go to Inbox https://localhost/index.php?app=main&inc=feature_report&route=user_inbox&op=user_inbox

"is a test message."

if the message is too long, only the first part is send out for Unicode. In standard no problem when splitting the text. Before it was working fine for Unicode. Tested in 0.9.8

In "Compose message" interface, if you put @ or # in the "Send to" box, you can see all the user in the system, not only yours. For example, in a subuser, if I put "@a", the dropdown list shows me all the users in the system whose name includes "a", so I can see user names from other accounts.

I think that this can be a dangerous privacity problem.

Greetings.

There is an error preventing to save user preferences. I noticed this bug had been resolved but I downloaded the master as of now, RC-3 and can't save any changes in user configuration.

When I updated from beta2 to beta3 this problem started and continues with master.

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 49152 bytes) in /var/www/playsms/web/init.php on line 112

Seems Send Message page is not working: refer to : http://playsms.org/trial/index.php?app=menu&inc=send_sms&op=send_sms After browsing above URL, web browser crash.

We try to find problem but nothing ...

feature request

fetchmail loads the mail and sends it to a script script generates a file with playsms webservice urls wget invokes the urls from the file and stores the response

below you have a working prototype. It needs polishing and error handling maybe but it works ok. You need som unix tools like bash, mktemp, wget, hexdump, sed, grep.

fetchmail config example: poll mail.playsms.org protocol IMAP user "anton" with password "playsms" mda "/bin/bash /path/to/script/playsms.sh"

playsms.sh

!/bin/bash

TMPDIR=mktemp -d TMPTXT="${TMPDIR}/fetchmail.txt" TMPURL="${TMPDIR}/playsms.url" TMPXML="${TMPDIR}/output.xml" while read line; do echo ${line} >> $TMPTXT echo ${line} | grep -i "^Subject:" > /dev/null 2>&1 if [ "$?" == "0" ] then echo -n 'http://x.com/playsms/index.php?app=webservices&u=anton&h471bb53b69a966e27ae818ee3d0c8c78=&ta=pv&format=xml&from=anton' >> $TMPURL echo ${line} | sed -e 's/^Subject:\s_//i' | hexdump -v -e '/1 "%02x"' | sed 's/(..)/%\1/g' | sed -e 's/^/&msg=/' >> $TMPURL fi echo ${line} | grep -i "^Phone:" > /dev/null 2>&1 if [ "$?" == "0" ] then echo -n ${line} | sed -e 's/^Phone:\s_/&to=/i' >> $TMPURL echo -n -e "\n" >> $TMPURL fi done wget -q -i $TMPURL -O $TMPXML

invoke fetchmail (from crontab if required on a periodic basis) fetchmail --ssl -f .fetchmailrc

in the tmp directory you will have a random subdirectory (generated by mktemp) and therein 3 files fetchmail.txt with the complete emails downloaded by fetchmail playsms.url where the URL's are stored which will be invoked output.xml the xml output of playsms for error handling

Dear all, I've an issue when i send message with accentued words (Clickatell gateway). ie. in french: Hôtel / Déjeuner / L'entreprise / Noël / évènement / ... é à è ç ù ö

If i send évènement, When received on phone, that became: AcvA"nement.

Any idea to fix-it ?

Regards

Hello,

There is a problem with sending SMS in Arabic / Hebrew. It comes as: ?????? version is 1.0-rc7. I tried to play a bit with encoding (fn.php)and could not solve the problem. I use a nexmo.

Thank you.

There is the function core_detect_unicode in the fn_core.php file that checks if a message is or isn't using characters not part of ASCII, but the SMS allow an special charset called the GSM character set (see it here http://www.clockworksms.com/blog/the-gsm-character-set/ or here http://unicode.org/Public/MAPPINGS/ETSI/GSM0338.TXT), that allows some extra characters such all of the accented vowels and others, Since playsms is using mb_string_detect, it detects them as UTF-8, hence encoding the messages in double byte, when there is no need for it.

I have been myself looking for solutions for this, so far but couldn't find much, this link has some more information http://stackoverflow.com/questions/27599/reliable-sms-unicode-gsm-encoding-in-php

Mutli-selects are the least user-friendly form control because normal selection of an option de-selects all other options.

The hidden input is solely to ensure an array exists in $_POST.

The DeliveryReport option of gammu-smsdrc(5) already controls this behaviour, and defaults to no. It should no be force-enabled by playSMS.

Closes #638

https://github.com/playsms/playsms/blob/3675b062cea65453a946b5d7c2fb0975fdd52f8c/storage/application/plugin/gateway/gammu/config.php#L13

Unresolved forum topic from 2 years ago: https://forum.playsms.org/t/gammu-config-appears-to-force-delivery-reports/2923

Why is Gammu still crippled by default?

Hello,

I changed the admin password for webapp access from the sqladmin interface, since then I can no longer connect. I have an error "SQLSTATE[HY000]: General error: 1 unrecognized token: "MY PASSWORD'')", my new password contains special characters. I connected in ssh on my box and I changed the password directly on the database :

UPDATE playsms_tblUser SET password = 'My password with MD5 encryption' WHERE username = 'admin';

But i still have the same problem.

PS: I also changed the password from the phpmyadmin interface I reboot the services after the change

Thank you for your help.

I couldn't find any instance of the ignore_user_abort PHP function when grepping the code. To me, that signifies a user must wait until every page loads and every request fully completes (which can be a long time for big sends with a small machine), and they can never get a network interruption nor a power failure, otherwise PlaySMS will simply crash and be left in an inconsistent state (e.g. a stuck queue). For read operations it doesn't matter but write operations should complete unless the user sends a "stop doing that" request to the app. I can see why one would want to be able to cancel a send, but surely that should be done explicitly rather than closing a browser tab and hoping for the best.

Sends could be cancelled by deleting the relevant outbox records and .txt files, then changing the queue's flag field. It's a simple thing to add but then creates challenges if you want to allow control of, or present status information on currently processing requests.

This isn't just theoretical, we've had large sends (as in tens of thousands of messages) fail because of this. I've had to manually clean up the database after.