get error in wordpress cherryframeworks, after moving to new hosting, wp get error

Just a little heads up for anybody moving a WordPress site that contains any kind of Cherry Framework related theme – You need to delete your .cache files for .less files. Here is where mine were located:

For Cherry Framework itself:

  • less/bootstrap.less.cache
  • less/style.less.cache

Then inside my child theme (this may be different for you, but find the .cache files and delete them if you’re getting errors):

  • theme root/style.less.cache
  • bootstrap/less/bootstrap.less.cache

Without deleting these files, your site will look for the .less related files and style sheets inside the old site file structure, which obviously will not work :)

Hopefully I saved you from the last painful 2 hours I endured trying to track these errors down!

Directadmin spam email – way to fix it

How can I find the script? If the mail was authenticated for, it will probably be a trojan on the users pc at home, let him scan with Malware Bytes.

If it was a script, install Maldet malware scanner on your server, a great howto is to be found here:
http://forum.directadmin.com/showthread.php?t=45851
Scan all users home directory’s with it, the command is included in the thread.

You can also check your users public_html files if you see something strange in a php filename and check.
You can also check you users public_html for base64 encrypted files:

Code:
find . -type f -exec grep -l ‘base64_decode’ {} \;

from within the users public_html directory. But take care, not all php with base64 in them are bad files.

Another possibillity is to add some log options to exim so when a spam mail returns as undeliverable, you could check the headers which script the mail is coming from.
In /etc/exim.conf go to log_selector, and change what you have there to this:

Code:
log_selector = \
  +address_rewrite \
  +all_parents \
  +connection_reject \
  +arguments \
  +delivery_size \
  +sender_on_delivery \
  +received_recipients \
  +received_sender \
  +smtp_confirmation \
  +subject \
  +smtp_incomplete_transaction \
  -dnslist_defer \
  -host_lookup_failed \
  -queue_run \
  -rejected_header \
  -retry_defer \
  -skip_delivery

find email spam and check it and fix it on directadmin

Finding an e-mail spammer on your server

For years now, spam has been a nuisance that has plagued many internet users. Most people however, think that spam e-mail is being sent out by an actual person behind an actual computer, while in reality, these spammers (ab)use hacked e-mail/server accounts, or security holes within websites. Most server operators don’t even know that spam is being sent from their own server, until they receive complaints that bonafide e-mail from users on their server is not reaching the recipients, or they find out that their server IP address is suddenly located on blacklists. At that point, the hunt for the spammer is on, but how do you actually locate the spammer?

I work at a web hosting company, and see similar questions on a daily basis. A lot of people renting a VPS or dedicated server have no (or very little) actual server management knowledge, and rely mostly on the web hosting control panels (such as DirectAdmin), and the support desk of their server provider. This article offers several ways to find a spammer on your server, and does assume some basic linux knowledge such as how to use the command line (cli/ssh).

Symptoms

  • The server may slow down, and use more resources,
  • E-mail is not reaching its intended recipients,
  • Messages appearing in the DirectAdmin message log about a user having sent X amount of e-mail,
  • The Server IP address is located on one or more blacklists,
  • A user complains he is receiving a lot of bounce e-mail for e-mail he did not send.

Spam methods

Spammers have a variety of spam delivery methods available:

  • SMTP spam,
  • Hacked/abused web hosting account,
  • Perl script/server

With SMTP spam, the spammer has obtained the credentials of the e-mail account he is abusing. This is done through either brute-forcing (usually not successful if the password is difficult enough), or by malware that is installed on the actual computer(s) of the owner of that e-mail address. This type of malware either comes in the form of a key logger that logs your keystrokes and sends it to a central location, or malware that scans the computer for password files. A lot of people find the options that some (ftp, e-mail) software offer to automatically store your login credentials very convenient, but this is a major security risk that this kind of malware capitalizes on. These files are found, decrypted, and again sent to a central location where spam bots can abuse it. Once they have the login details, they can send out spam.

The hacked/abused web hosting account is also very common. Bots automatically scan websites for known security holes. This is particularly easy with websites running standard software such as WordPress, Joomla, and their plugins. Webmasters tend to not update their software, even though security risks are being discovered and fixed, or they are unaware of the risks. When a hole is identified by a spam bot, it is quickly abused by uploading a file containing malicious code through that hole, and executing it. A similar thing is done when malware locates the ftp credentials on a computer, uploads a file using ftp, and executes it through a web browser. With that latter method, the file is usually removed immediately after execution, making the hunt a bit more difficult.

The perl script/server method will not be covered in this article at this point, but may be at a later date.

Identifying spam

Identifying/locating a spammer is often difficult. Especially if you have a lot of users/domains on your server. There is very little you can do using the DirectAdmin panel, but it is still useful. The first is to open the “Message System”, which is located at the top/right of the standard DirectAdmin template. If you find recent messages like:

Warning: 600 emails have just been sent by <username>

Then that might be a spammer, or someone who has sent out a newsletter.

The other thing you can do within DirectAdmin is to open the “Mail Queue Administration”. If the Mail Queue Administration will not open due to timing out, you can be fairly certain that your server is being abused to send out spam. This means there are so many messages waiting to be sent out, that this page cannot be opened anymore. If however it does open, and you see a large number of pages you can click on, this also means there are a lot of messages waiting in the queue. If you see a lot of the same sender- or recipient addresses in that list, it may be wise to investigate a few of those e-mails by clicking on the mail ID to the right.

The best way to do this however, is by searching the mailserver (exim) logs, which are located in /var/log/exim. The most recent log inside that directory is called “mainlog“. It is possible to search this log using DirectAdmin’s “Log Viewer” which is located on the admin main page, and then selecting “Exim Mainlog“, however these logs can be “very” large, and therefore very slow to dig through using a web interface such as DirectAdmin. It may be more convenient to open the command line interface (ssh), which is the method I will expand on below.

The first thing I do when I login through ssh, suspecting spam, is to see how many e-mail is actually located in the mailqueue waiting to be handled (sent/received). To see this, type:

[root@server]# exim -bpc
1069713

This outputs a summary of the total amount of e-mail that is sitting in the mailqueue, and is totalling over one million in this example. The server in this example is most definitely sending out spam.

Next, move to:

[root@server]# cd /var/log/exim

There, type:

[root@server]# cat mainlog |more

Just “more mainlog” is also possible. If the dates in front of the log lines are old (e.g. much more than a day), then try this:

[root@server]# tail -n 10000 mainlog |more

The 10000 number is the last number of lines to start displaying. You can tweak this around by modifying the numbers. I sometimes have to change it to 150000 or more before I see some sensible data, because when the spamrun has been active for a while, the bounces start to appear very fast, which clutter the log. You can press the space bar to scroll downward through the log. You may find something like:

2013-12-28 23:48:27 1Vx2g2-0001EU-Cq ** source@example.com F=<> R=lookuphost T=remote_smtp: SMTP error from remote mail server after  RCPT TO:<source@example.com>: host aspmx.l.google.com [172.28.15.27]: 550-5.1.1 The email account that you tried to reach does not exist. Please try\n550-5.1.1 double-checking the recipient's email address for typos or\n550-5.1.1 unnecessary spaces. Learn more  at\n550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 l2si45202725een.62 - gsmtp
2013-12-28 23:48:27 1Vx2g2-0001EU-Cq Frozen (delivery error message)

Which is a bounce e-mail. You will almost always find bounces in the log, also from bona fide users, but if you see a whole lot for the same destination address on your server (source@example.com in this example), then you can write down that address to scan on that specific address later.

Something else you may find in the log:

2013-12-29 00:00:47 1Vqqlt-0002LF-0d ** target@targetaddress.com F=<source@example.com> R=lookuphost T=remote_smtp: SMTP error from remote mail server after initial connection: host smtp.secureserver.net [172.21.10.17]: 554-m1pismtp01-029.prod.mesa1.secureserver.net \n554 Your access to this mail system has been rejected due to the sending MTA's poor reputation. If you believe that this failure  is in error, please contact the intended recipient via alternate means.

Lines like this show that you are being blacklisted, and may come in many different forms depending on the provider and type of blacklist. Bona fide mail may generate lines like this if your server IP address is on blacklists.

The following are the type of lines you may be looking for:

Example A

2013-12-27 11:34:51 1VwUkl-0006D4-Co <= dauser@example.com U=apache P=local S=3436 T="R0L3x AND v14rga" from <dauser@example.com> for target@spamtargetaddress.com 2013-12-27 11:34:52 1VwUkl-0006D4-Co => target@spamtargetaddress.com F=<dauser@example.com> R=lookuphost T=remote_smtp S=3576 H=172.11.80.170 [172.11.80.170] C="250 2.0.0 Ok: queued as E19AA22B0173"
2013-12-27 11:34:52 1VwUkl-0006D4-Co Completed

or:

Example B

2013-12-27 20:36:10 1VwdCb-0001ze-5c <= user@example.com H=([172.25.100.95]) [172.25.100.95] P=esmtpa A=login:user@example.com S=100156 id=XREO1FTV-KAX1-NLMI-0XTF-4BPJKR7EII6F@spamtarget.com T="FREE MONEY EVERYDAY - £1 MILLION IN UNDER 7 YEARS" from <user@example.com> for target@spamtargetaddress.com

Example A shows “U=apache“, which means that the e-mail was sent using the web server. If the website (or server) is running suphp or mod_ruid2, then the website is not executed as apache, but the username. In that case you may see “U=dauser“, which in this example is the DirectAdmin username for this specific user. “T=” is the e-mail subject, which is usually very obviously spam. However, there are cases where it may look legitimate such as “Scheduled Home Delivery Problem”, but if you find a large number of the same subject types sent by the same user, combined with a lot of bounces, it is likely spam.

Example B shows “P=esmtpa“, which means it was sent using SMTP, which is the exim mailserver. The sender IP is shown as “H=([172.25.100.95]) [172.25.100.95]” and the e-mail account that was used to send it is shown at “A=login:user@example.com“. This is again a very obvious spam subject which you can see in “T=“, and you may find a large number of those in the log, from the same user. However, the part in “from <user@example.com>” may in some cases actually show a completely unrelated and foreign address. The reason for that is that it is very easy to fake a source e-mail address, so the spammed users will not easily know that it came from your user’s  domain name, unless they look at the e-mail headers.

Once you have identified (or suspect) a possible spammer, you could re-scan the log using just the e-mail address, or username (I use tail here to scan the last part of the log, but you can substitute “tail -n 10000” with “cat” to start from the beginning):

[root@server]# tail -n 10000 mainlog |grep user@example.com |more

or

[root@server]# tail -n 10000 mainlog |grep user |more

or to get all the details regarding a specific mail ID:

[root@server]# cat mainlog |grep 1VwdCb-0001ze-5c

or all lines with a specific subject (grep’s -i flag for case-insensitive search):

[root@server]# tail -n 10000 mainlog |grep -i "FREE MONEY EVERYDAY" |more

To show a list of e-mails sitting in the queue you can also do:

[root@server]# exim -bp |more

The |more part pauses the list, which is a must if there are a large number of e-mails waiting. You will probably find many occurrences of the spamming e-mail address in that list. To show some more detailed information, you can query a single e-mail with:

[root@server]# exim -Mvh 1Vx7MK-0007RR-Re

Where the last part is the e-mail ID. This may output something like:

198P Received: from apache by your.servername.com with local (Exim 4.72)
(envelope-from <dauser@example.com>)
id 1Vx7MK-0007RR-Re
for target@targetaddress.com; Sun, 29 Dec 2013 04:48:12 +0100
038  Date: Sun, 29 Dec 2013 04:48:12 +0100
057I Message-Id: <e1vx7mk-0007rr-re@your.servername.com>
030T To: target@targetaddress.com
051  Subject: Exper tP harma cy
059  X-PHP-Script: www.example.com/components/com_module/x.php for 172.27.17.218
028F From: dauser@example.com

The “from apache” part shows it was sent using the webserver, and the “X-PHP-Script” part shows which script was used to send it. This is especially useful to find the location of the possible spamscript on your server.

If the e-mail was sent using SMTP, the solution is very easy. You can then simply reset the compromised e-mail address’ password and inform the user that his/her credentials were found, and that the user needs to scan his personal computer for malware. If the spam was sent using the webserver, then a temporary solution is to suspend the user’s web hosting account, which will prevent it from adding any new spam e-mails to the mailqueue. You can then try to find the script that is used to send out the spam.

Finding a spamscript

Locating the script that was used to send out the spam can be difficult, especially if the compromised web hosting account has a lot of files. The “X-PHP-Script” shown in the previous example is not always there, and in that case you will have to hunt for it manually. Also, there may be more than one (spam)script, especially if the user is running very outdated software, and has been doing so for quite a while. Such site may be hacked over and over again by many different bots.

One thing you can do is scan for base64 encoded code, which is still very popular. Such code is immediately executed using php’s eval() function. To search for that, go to the user’s public_html (or private_html) directory:

[root@server]# cd /home/username/domains/example.com/public_html

Where username is the username of the DirectAdmin user, and example.com is his/her domain name. Then type:

[root@server]# find . -name '*.php' | while read FILE; do if grep 'eval(base64_decode' "$FILE"; then echo "$FILE" >> maybeinfected; fi ; done

This code snippet searches through all .php files for the “eval(base64_decode” code, and if found, stores the location of that file inside a file with the name “maybeinfected”.  To not store it in a file, but output it to the console instead:

[root@server]# find . -name '*.php' | while read FILE; do if grep 'eval(base64_decode' "$FILE"; then echo "$FILE"; fi ; done

You can substitute “eval(base64_decode” for any other string, such as “eval(gzinflate(base64_decode“, which may also be used.

A more simplified way to search for the same string:

[root@server]# grep -r "eval(base64_decode" . |more

This will basically do the same thing, but also presents you with the whole line of code for every file it finds. The “-r” flag means it is a recursive search which traverses all directories and files in the path you specified. You can also add a “-i” flag for case-insensitive searches.

If you know when the spamming started, you can also check for files that had a status change within the last X days:

[root@server]# find . -type f -user apache -ctime -3 |more

Where “-user apache” reads as “users owned by apache”, which can be removed if you want to search for all owners, and the value after “-ctime” is the number of days ago to start from, which is in this case 3 days. This will produce a file listing that will almost certainly also show innocent files. However, you will probably see a few files that have strange filenames (x.php, 424.php, sys2674123.php, etc), which you may want to investigate further.

You can also substitute the dot (.) in the above examples with a full path name, including a wildcard (*) to search through more directories such as:

/home/*/domains/*/public_html

Where the first * is a wildcard for all users (you can add a username there to narrow the search), and the second wildcard is for all domains.

Note though that removing the infected scripts may only be a temporary solution, because if the user is running outdated software, chances are high to 100% that this will happen again.

Emptying the e-mail queue

You will probably want to empty the mailqueue, so that the thousands (or in some cases millions) of messages that are waiting to be sent or delivered, are no longer being handled. This can be done in several ways:

[root@server]# exim -bp | awk '{ print $3 }' | xargs exim -Mrm

This will empty the complete queue including any bona fide e-mails. Though this may not be what you want, it is the fastest way to empty the queue, especially if there are over a million e-mails inside it. Even though it is the fastest way, it may still take a very long time to complete.

To only delete the spam e-mails:

[root@server]# exiqgrep -i -f dauser@example.com |xargs exim -Mrm

You can also substitute dauser@example.com with just example.com. Another way to remove only the spam e-mails:

[root@server]# exim -bp | awk '/<dauser@example.com>/ {print $3}' | xargs exim -Mrm

There are more ways to do this than just the above examples. After the operation has completed, you can check how many e-mails are left in the queue:

[root@server]# exim -bpc

If you still see many messages, then chances are that those messages are “frozen”. To remove those:

[root@server]# exipick -zi | xargs exim -Mrm

Sometimes, even then you are left with a large number of e-mails sitting in the mailqueue. Trying to empty the queue may result in an error like:

[root@server]# exim -bp | awk '{ print $3 }' | xargs exim -Mrm
exim: malformed message id <dauser@example.com> after -Mrm option

This can be fixed with by first obtaining the e-mail ID the removal is stopping at:

[root@server]# exim -bp | exiqgrep -i
Line mismatch: 50h       1VwxAB-0005m5-7R <dauser@example.com>

And then removing that e-mail from the queue:

[root@server]# exim -Mrm 1VwxAB-0005m5-7R

You may have to do this several times if there are more malformed e-mails in the queue. After that, you can retry emptying the queue.

When all is done, you should not see many messages waiting in the queue anymore.

Conclusion

There are many ways to solve these spam issues, and this is also not a definite guide. One of the things you may also do in case the webserver is used to send spam, is to check the FTP logs to see if the scripts were stored that way, but information about how to do that is not (yet) part of this article.  If, after reading this article, you have any improvements, then let me know so this article can be updated.

fix database problem:

problem:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘0’ for key ‘PRIMARY’

solution:

– run below sql in phpmyadmin,

TRUNCATE dataflow_batch_export ;
TRUNCATE dataflow_batch_import ;
TRUNCATE log_customer ;
TRUNCATE log_quote ;
TRUNCATE log_summary ;
TRUNCATE log_summary_type ;
TRUNCATE log_url ;
TRUNCATE log_url_info ;
TRUNCATE log_visitor ;
TRUNCATE log_visitor_info ;
TRUNCATE log_visitor_online ;
TRUNCATE report_event ;

 

——–

 

then, use COMMAND to remove all session and cache in VAR

 

it should be working.

 

rsync delete large file

可以用来删除大文件

假如我们在/root/下有一个几十G甚至上百G的文件data,现在我们要删除它

一、创建一个空文件

    touch /root/empty

二、用rsync清空/root/data文件

    rsync –delete-before -d –progess –stats /root/empty /root/data
rsync –delete-before -d –progess –stats /tmp/empty   /file/file

stop exim service

/etc/init.d/exim stop
  1. [root@localhost ~]# cat /etc/virtual/limit #全局设置,所有虚拟主机用户,每天最大发送邮件数量
  2. 100
  3. # /etc/virtual/limit 的值不为0的情况下,等于0或者负数,主机用户可发送邮件量均为“无限制”(不推荐) 根据笔者的经验,100-200的数量已经可以满足普通用户的需求。
  4. [root@localhost ~]# cat /etc/virtual/limit_userabc #单独设置,用户”userabc”每天最大发送邮件数量
  5. 200
  6. [root@localhost ~]# cat /etc/virtual/limit_baiqiuyi #单独设置,用户”baiqiuyi”每天可发送的邮件数量为“无限制”
  7. 0
  8. #前提为/etc/exim.pl 里有这行 if (open (LIMIT, “/etc/virtual/limit_$name”))
  9. [root@localhost ~]# ls -lh /etc/virtual/usage
  10. total 24K
  11. -rw-rw—- 1 root mail    5 Apr 28 21:47 baiqiuyi
  12. -rw-rw—- 1 root mail 1.4K Apr 28 21:47 baiqiuyi.bytes #此文件记录了该用户当天发送邮件的详细信息,如果该文件过大,就有发送垃圾邮件的嫌疑。

宝尊上市一周股价上涨两成 电商代运营公司为何受青睐

宝尊上市一周股价上涨两成 电商代运营公司为何受青睐

2015-05-30 17:45:00 来源: 中国广播网(北京)

央广网北京5月30日消息 据经济之声《天下公司》报道,今天凌晨,在纳斯达克上市中概股宝尊电商收盘价定格在12.18美元,较发行价10美元累计上涨了21.8%。作为一家5月21日上市的新股,宝尊电商在中概股的表现相当抢眼。

宝尊电商成立于2007年,是一家电商代运营公司,主要业务是为商户提供网站搭建、更新及托管、网站建设及设计、IT技术服务、仓储物流和数字营销等整套的电商运营服务。

根据艾瑞咨询的数据,宝尊占据了国内电商代运营市场 20% 的份额。目前宝尊,与94家品牌企业有合作,知名合作伙伴包括微软、耐克、夏普、松下、Toyota、百事可乐等。

宝尊公司去年亏损2500万美元,营收为2.55亿美元。而由于较高的市场份额和每年近500%的增长率,再加上它的两大股东是大名鼎鼎的阿里巴巴和软银集团,这家公司获得资本市场的青睐也不奇怪。

事实上,在各大电商平台上,都活跃着这样的公司。只不过,他们主要的服务对象是企业用户,并不为一般消费者所知。随着宝尊的上市,这个行业也浮出了水面。

摩根士丹利在去年发布了一份关于全球电子商务报告预测,到2016年,全球电子商务营收规模将达到1万亿美元,而这正是宝尊、京拍档这类公司的机会

在国内市场上,电商代运营公司主要分为两类:一类是轻公司,他们只帮助传统企业做核心运营业务,包括软件、呼叫中心提供服务等;另一类是“一站式”服务的重公司,为客户提供全程服务,从财务管理到仓储物流都是自己构建。宝尊电商就是后者。

另外,宝尊副总裁马烈还说过,他们是业内唯一一个全品类、跨行业的代运营公司。另一家电商代运营公司瑞金麟创始人安士辉指出,大多代运营企业因为投入过高,没有核心技术和产品话语权,几乎不太可能成为行业巨头。同时,也没有任何一家代运营公司能提供所有行业的电商解决方案。

 

目前,代运营市场还有些混乱,团队质量参差不齐。一家在天猫从事服装销售的老板刘刚抱怨,合作不到半年,就看不到他们之前合作的团队影子了,所有的安排都变成了电话会议,他以后再也不会找代运营公司了。

而另一方面,很多代运营公司也在抱怨,很多客户在学会了电商的运营方法之后,也会把他们抛在一边。瑞金麟创始人安士辉说,想要不被客户抛弃,就要做那些客户做不了、同时又对他们有价值的事。

(原标题:宝尊上市一周股价上涨两成 电商代运营公司为何受青睐)

百家公司倒闭 电商代运营模式走向终结

百家公司倒闭 电商代运营模式走向终结

http://www.sina.com.cn  2012年10月25日 11:39  亿邦动力网
  【亿邦动力网讯】代运营模式的前景看起来可能没有以前那么乐观了。

在代理了几家化妆品大牌的天猫业务后,聚合美妆(杭州的某代运营公司)决定推出自有品牌。原因是做代运营利润率太低,必须及早转型,以免彻底成为杀鸡取卵的牺牲品。

和聚合美妆差不多境况的电商代运营公司,在杭州已经死了几百家。以前稳赚不赔高增长的好日子几乎走到尽头,留给代运营商回旋的余地并不多:他们大多开始寻求新的出路——或做品牌经销商,或升级为自有品牌,或变身解决方案提供商,或干脆倒闭关张。

虽然有数据显示,电商代运营市场份额已达百亿元,并以每年300%的增幅高速成长。但根据从业者的经验判断,增速远远没有达到预期。

综观整个代运营行业,无论是效益、服务质量,还是信誉度都在出现不同程度的下滑。诸多信号预示着,电商代运营正步入夕阳产业的行列,甚至很有可能在一两年内彻底走向覆灭。

 市场格局混乱 高不成低不就

“大多代运营企业因为投入过高,没有核心技术和产品的话语权,几乎不太可能成为行业巨头。”电商代运营公司瑞金麟创始人安士辉指出。

据了解,早先的代运营商都瞄准美国的电商代运营鼻祖GSI去做,但对方强大的前端网络销售和后端供应链管理能力,远非国内从业者可以效仿。

公开资料显示,目前天猫上共有18个品类共计377个公司规模以上的代运营商,其中具备前端、后端整体托管能力的代运营公司不到一半。

“这个行业里高端代运营基本缺失,云集在中低端的运营商无序竞争,根本成不了气候。”聚合美妆的品牌总监向亿邦动力网表示,电商代运营行业刚刚在国内兴起的时候,数量有限,虽然也存在不规范的因素,但整体上格局比较明朗,且利润丰厚。

“大家都看到代运营有肉吃,便开始另立门户自己创业。”由于准入门槛较低,很多中小代运营商三五人便组成的“草台班子”迅速侵入,彻底搅乱了代运营市场,也让利润变得稀薄。

除了利润低下,中小规模的代运营商服务质量参差不齐,不利于维系稳定的客户关系,业务难以形成常态。

据业内人士透露,为了赚钱,代运营商疯狂地寻求各类客户,超出了自己擅长的品类范畴之外也敢接单,造成极大的资源浪费和恶性竞争。

“判断一家代运营公司是否运转正常,通常是要看续签率,而不是仅仅是交易额。”青岛鼎商动力CEO刘攀介绍,虽然业界没有统一的标准,但续签率低的企业往往无法兑现承接业务时承诺的保底销量。

“因为没有相应约束,对于未履行承诺的代运营企业也无可奈何。”刘攀表示,甲乙双方非常容易为此产生裂隙甚至矛盾,致使传统品牌商对于代运营机制失去信赖。

服务增值能力薄弱 纷纷转型求生

据亿邦动力网了解,代运营企业主要收入来自月基础服务费+销售提成。

“基础服务费顶多几万块,甚至几千块,返点则根据品类不同,大致在5%到10%之间。”聚合美妆方面表示,极少有企业能够将服务费提升至百万以上级别,拿到超过15%左右的交易提成。

“销售佣金其实是多数代运营商的唯一收入,只有大品牌才会给予一些服务费支持。” 曾为欧莱雅、曼秀雷敦、New Balance等知名品牌做过天猫代运营的朱丽佳称。

据亿邦动力网了解,部分代运营商在意识到行业陷入困境后,被迫转型,如采用线下代理制,从事线上经销,以赚取更高的零批差额为生。

这种现款现货的经销商模式虽然有效改善了利润率,但并非每个代运营企业都能受用。买断品牌进货、拓展仓储物流,意味着对资金规模的需求将持续走高,公司基本上从以往的轻资产模式向重资产过渡,风险较大。

“经销模式我们已经做了几年,虽然利润高,但没有几个亿的资金,根本玩不转。” 主要代理3C数码为主的兴长信达董事长刘磊表示,公司将逆势从经销转代运营模式。

问题是,即便如此,仍无法满足客户想要的。传统品牌商试水电商并不仅仅是为了走销量,深层次上还是试图借助互联网手段,实现线下销售所不能承担的精准营销、品牌互动等功能。

分析人士指出,而目前国内的多数中小代运营商还处在做表面功夫的阶段,店铺托管也主要是围绕入驻平台的基本流程为主。品牌商初期投入可以看到一定的增量,但随着电商竞争的同质化日趋严重,数据挖掘等增值服务的短板暴露无遗。

迫于形势,处于中游的代运营商致力于向解决方案提供商升级,陆续开设整合营销和业务咨询等新的盈利模式。

“但均是仓促上马,收效甚微。” 聚合美妆的人士表示,由于缺少大客户资源,抬高的不是竞争门槛却,而是成本支出。

传统企业回归理性 市场洗牌时刻来临

代运营行业注定只是过渡时期的产物,随着传统品牌对电子商务的认识逐渐加深,迟早会摆脱对运营商的依赖,重新执掌线上业务。

即使是在过去高增长阶段,代运营商也从未放松警惕,“替别人养孩子”的尴尬心态令其进退维谷。

这样的窘境并非国内的特例。美国最大的代运营商GSI,同样摆脱被品牌商甩开的宿命。如同亚马逊被塔吉特(美国零售商)甩掉一样,GSI每年都会面临被自己带上电子商务之路的品牌“单飞”的情况。

与此同时,鉴于代运营市场良莠不齐的混乱局面,传统品牌商在选择合作伙伴时也越发谨慎。通常情况下,不保底销量的一律不予以考虑。这让部分中小代运营商在开拓新客户方面几乎到了四处碰壁的境地。

“传统品牌对电商已经不再向以前一样热情高涨,而是逐渐回归理性,以业绩为导向的行业新标意味着代运营市场洗牌时刻的来临。” 据刘攀判断,代运营市场留给企业的时间不会超过两年。

“站在品牌商的角度审视整个代运营行业,会有不同的思考。”国内某品牌男鞋电商负责人表示,代运营商对于品牌商而言,实际就是外包服务提供商,但品牌商只允许外包与线上交易相关的物流、支付、客服等服务,至于核心品牌的的营销渠道和推广方式则不会全部授权给代运营商。

“也就是说,代运营商干的都是粗活累活,其服务本身并不具备核心价值。”上述人士还指出,随着天猫、京东、苏宁易购开放平台生态体系的逐步完善,配套设施更加健全,一来品牌商将主动放弃建站意愿,二来对代运营商的依赖程度大大削弱。

想象一下,假设一个传统企业做电商时,发货用京东的快递,入苏宁易购的仓,还有统一的400客服专线,代运营商的末日还会远吗?

Magento : Get Base Url , Skin Url , Media Url , Js Url , Store Url and Current Url

Get Url in phtml files

1. Get Base Url :

Mage::getBaseUrl();

2. Get Skin Url :

Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_SKIN);

(a) Unsecure Skin Url :

$this->getSkinUrl('images/imagename.jpg');

(b) Secure Skin Url :

$this->getSkinUrl('images/imagename.gif', array('_secure'=>true));

3. Get Media Url :

Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_MEDIA);

4. Get Js Url :

Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_JS);

5. Get Store Url :

Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_WEB);

6. Get Current Url

Mage::helper('core/url')->getCurrentUrl();

Get Url in cms pages or static blocks

1. Get Base Url :

{{store url=""}}

2. Get Skin Url :

{{skin url='images/imagename.jpg'}}

3. Get Media Url :

{{media url='/imagename.jpg'}}

4. Get Store Url :

{{store url='mypage.html'}}

 

solution for magento user /client can not login

find the file

/app/design/frontend/default/template-name/template/persistent/customer/form/login.phtml

and inside the “login form” form, after the

<ul class="form-list">

you should insert

<input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey(); ?>" />

then, insert this file to the local theme folder.

so be it – donny liu ( donny12345@gmail.com )

Magento fix the connect manager error problem – solution

After I login to Magento connect from my admin I get this back. This is a vanilla install of Magento.

Mac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefoxMac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefoxMac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefoxMac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefoxMac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefoxMac OS X  2��ATTRo���-�-com.apple.quarantineq/0000;4e794ae7;Firefox;|org.mozilla.firefox Fatal error: Cannot redeclare class Mage_Connect_Command_Install in /home/webolutionary/public/dandm.webolutionaries.com/repo/downloader/lib/Mage/Connect/Command/Install.php on line 542

I ran the Magento Clean up script, checked my permissions cleared my cache and still a no go. I spent 2 hours trying to search for someone in my case with no luck. This is Magento CE1.6.1

same here magento community 1.6.1.0 anyone any tips

Any of the Magento experts have to say anything about this issue. Google does not seem to be my best friend on this issue, since the only topic I can find about this issue is this one.

The problem really is a showstopper for me, if I cannot figure out what is going wrong here, I think I do not stand a chance in setting up my very own production store.

So here my desperate call for help : HELLUP

I was able to find the solution to this problem.

Assuming you’re able to SSH into your server, do the following:

1. cd [Magento install folder]/downloader/lib/Mage/Connect/Command which in your case would be cd /home/webolutionary/public/dandm.webolutionaries.com/repo/downloader/lib/Mage/Connect/Command

2. As a stop-gap, check to make sure the problem files do exist by running this command: ls ._* You should see a list of files like this: ._Channels_Header.php ._Channels.php ._Config_Header.php ._Config.php ._Install_Header.php ._Install.php ._Package_Header.php ._Package.php ._Registry_Header.php ._Registry.php ._Remote_Header.php

These files are duplicates which have the strange characters in them. If you run “grep ‘com.apple.quarantine’ ._*” (which searches the file contents for the quoted string), you will probably see these files listed.

3. Delete these bad files: rm ._*

4. Logout as you’re done. You should be able to login to Magento Connect.