Malfunction while creating a blog post in Persian #924
Labels
No labels
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Plume/Plume#924
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Today, again I faced with an issue for making a blog post. I noticed I could make the post by different names but not any of the following:
If I would make a post with these titles, the post would be made but If I wanted to edit it, the edit page would load half. So body text was not complete and also no other form element would appear after that textbox. So I had to remove the post and make a new one.
Though I could make a post with this title:
I faced with the same issue long time ago. So I think this issue is not related to any of the recent changes in code base.
@ahangarha Could you paste the article's body here?
This is the wholde article:
https://paste.ubuntu.com/p/bhx5wnrKPg/
تغییر نام انبوه پروندهها با افزودن شماره به اول نام
روز گذشته، ویدئوهای یک فهرست پخش را از یوتیوب بارگیری کردم. ۱۱۸ ویدئو در آن فهرست موجود بود که متاسفانه فاقد شماره سریال بودند. در نتیجه امکان تغییر نام و جابهجا کردن شماره سریال از انتها به ابتدای نام پروندهها نبود. بنابراین نیاز بود راهی پیدا کنم باری اینکه پروندهها مرتب و شماره سریالی به اول نامشان اضافه کنم. و پیش از ادامه، تاکید کنم که این کار، روی گنولینوکس #اوبونتو انجام شده است.
به لطف مرتب بودن ویدئو در فهرست پخش و اینکه برنامه youtube-dl آنها را به همان ترتیب نمایش در فهرست، دریافت میکند، اطمینان داشتم که زمان ایجاد ویدئوها داخل پوشه، مرتب است. بنا بر این، با دستوری مثل
ls -tr
میشد پروندهها را به ترتیب زمانی مشاهده کرد.از اینجا به بعد کافی بود که بتوانم حلقهای ایجاد کنم و بر اساس محتوای دستور
ls
نام پروندهها را گفته و شمارهای به اولشان اضافه کنم. ابتدا به سراغ دستورfor
رفتم. متاسفانه این دستور اگر به صورتfor f in $(ls -tr)
استفاده شود، متن را بر حسب فاصله هم از هم تفکیک ميکند. در نتیجه در عمل، امکان دریافت نام کامل (در صورتی که در نام پرونده، فاصله وجود داشته باشد) به این روش میسر نبود. لااقل من چیزی روی اینترنت پیدا نکردم.روش دیگر این بود که ابتدا فهرست مرتب شده را با
ls
ایجاد کنم و سپس خروجیاش را به دستور دیگری مثلwhile read f
بدهم. خوشبختانه این دستور به دلیل خواندن خط به خط، مشکل بالا را حل میکرد و به این ترتیب، نام هر پرونده را میتوانستم در متغیر$f
داشته باشم.الان تنها کاری که لازم بود انجام شود، ایجاد یک متغیر برای شمارش و درج آن در اول نام پرونده و افزایش آن در هر بار پردازش داخل حلقه بود. برای اطمینان از این که تعداد رقمها در شماره با هم برابر است و اولین ویدئو به صورت 001 نامگذاری میشود نه 1، از دستور قالبدهی به متن به این شکل استفاده کردم:
تغییر نام هم که با دستوری مثل rename به راحتی قابل انجام است. (البته من از rename روی اوبونتو استفاده میکنم که با rename روی برخی توزیعهای گنولینوکسی دیگر مانند CentOS متفاوت است.) قبل از تغییر نام پروندهها و تا رسیدن به نتیجه مطلوب، از گزینه
n
در این دستور استفاده میکنم که بدون تغییر نام، فقط بگوید که تغییر نام پروندهها به چه شکل خواهد بود. نتیجه، چیزی شبیه به این میشود:خروجیاش هم چیزی شبیه به این باید باشد:
و چون نتیجه، همان چیزی است که من میخواستم دستور را بدون گزینه
n
اجرا کردم. در نتیجه، به راحتی ۱۱۸ پرونده بدون شماره، دارای شماره شدند تا بتوان به راحتی ترتیبشان را دید. دستورات نهایی به این شرحاند:این را نوشتم که بعدا برای خودم قابل ارجاع و استفاده مجدد باشد. موارد زیادی پیش میآید که نیاز به چنین کاری پیدا ميکنم. امیدوارم به درد دیگران هم بخورد. من، دانش محدودی در نوشتن کدهای شل دارم. لذا چیزی که نوشتم الزاما بهترین راهحل نیست. اگر راه بهتر و آسانتری برای این کار میشناسید، لطفا همرسانی کنید.
Thanks!
I had the same issue today again. This is the article:
title:
چند سؤال پیرامون نمودار مرگ در ایران در سالهای ۲۰۱۸ تا ۲۰۲۰
body:
hmmm... the issue might be in Rocket.
Someone truncates response body to 8270 bytes... Rocket...hyper...or else.
rocket_csrf seems doing something because this problem's away if I remove it.
I'm upgrading it for Rocket 0.5. So, after that upgrading, I will work with this issue again.
This is actually a bug of rocket_csrf: plume/rocket_csrf#10
I found the cause and fixed it at last! It will be included in the next release.